BRPI0608591A2 - transaÇÕes comerciais em rede - Google Patents
transaÇÕes comerciais em rede Download PDFInfo
- Publication number
- BRPI0608591A2 BRPI0608591A2 BRPI0608591-1A BRPI0608591A BRPI0608591A2 BR PI0608591 A2 BRPI0608591 A2 BR PI0608591A2 BR PI0608591 A BRPI0608591 A BR PI0608591A BR PI0608591 A2 BRPI0608591 A2 BR PI0608591A2
- Authority
- BR
- Brazil
- Prior art keywords
- payment
- merchant
- mobile
- services
- user
- Prior art date
Links
- 238000004891 communication Methods 0.000 claims abstract description 47
- 238000012795 verification Methods 0.000 claims abstract description 38
- 238000013475 authorization Methods 0.000 claims abstract description 30
- 238000000034 method Methods 0.000 claims description 230
- 230000004044 response Effects 0.000 claims description 57
- 238000010200 validation analysis Methods 0.000 claims description 27
- 230000009471 action Effects 0.000 claims description 23
- 238000012546 transfer Methods 0.000 claims description 23
- 230000008569 process Effects 0.000 claims description 14
- 230000003993 interaction Effects 0.000 claims description 9
- 238000012550 audit Methods 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 5
- 230000004888 barrier function Effects 0.000 claims description 4
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000002093 peripheral effect Effects 0.000 claims description 3
- 230000004913 activation Effects 0.000 claims 7
- 230000009849 deactivation Effects 0.000 claims 2
- 230000005641 tunneling Effects 0.000 claims 2
- 241000207961 Sesamum Species 0.000 claims 1
- 235000003434 Sesamum indicum Nutrition 0.000 claims 1
- 230000001681 protective effect Effects 0.000 claims 1
- 230000002441 reversible effect Effects 0.000 claims 1
- 238000012552 review Methods 0.000 claims 1
- 230000007246 mechanism Effects 0.000 abstract description 14
- 238000012545 processing Methods 0.000 description 10
- 238000009434 installation Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000007639 printing Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000002708 enhancing effect Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 208000033748 Device issues Diseases 0.000 description 1
- 208000001613 Gambling Diseases 0.000 description 1
- 230000004308 accommodation Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000003292 diminished effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 239000007788 liquid Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000011378 penetrating method Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 230000002459 sustained effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3223—Realising banking transactions through M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/407—Cancellation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2135—Metering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2137—Time limited access, e.g. to a computer or data
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Software Systems (AREA)
- Signal Processing (AREA)
- Finance (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Computing Systems (AREA)
- Mobile Radio Communication Systems (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
TRANSAÇÕES COMERCIAIS EM REDE. Modalidades atuais provêem autorização e pagamento de uma transação comercial em-linha entre um comprador e um comerciante incluindo verificação de uma identidade do comprador e verificação de uma habilidade do comprador para pagar pela transação onde o provedor de identidade e o provedor de pagamento são freqUentemente entidades de rede dif erentes. Outras modalidades também provêem protocolos, sistemas de computação, e outros mecanismos que permitem autenticação de identidade e de pagamento usando um módulo móvel que estabelece segurança simples ou de multi-nível em uma rede não-confiada (por exemplo, a Internet) . Ainda outras modalidades também provêem uma comunicação segura de três modos entre comerciante, consumidor, e provedor de pagamento de modo que informação de conta sensível seja opaca ao comerciante, ainda o comerciante é suficientemente confiante da habilidade do consumidor para pagar pelas compras requeridas. Em ainda outra modalidade, informação de faturamento eletrônico é usada para autorização, auditoria, federação de pagamento, e outros propósitos.
Description
"TRANSAÇÕES COMERCIAIS EM REDE"CAMPO DA INVENÇÃO
A presente invenção diz respeito aos sistemas detransação em rede e métodos para conduzir transações em-linha. ANTECEDENTES
A proliferação de sistemas de computador em redeabriu novas possibilidades com respeito como as corporaçõese indivíduos conduzem negócios. Por exemplo, os usuários fi-nais conectados a uma rede, (por exemplo, a Internet), pormeio de um dispositivo em rede como um computador, PDA, te-lefone celular, etc., podem conduzir transações comerciaisna rede para comprar serviços e/ou mercadoria, conduzirtransações financeiras ou do contrário conduzir negócio ouexecutar transações pessoais na rede. Um problema inerenteligado com transações em-linha é segurança, particularmentequando a transferência de dinheiros, fundos e/ou informaçãoconfidencial financeira, pessoal ou outra está envolvida natransação..
Muitas transações em-linha convencionais são con-duzidas de acordo com um de dois modelos diferentes, mas re-lacionados . Ambos os modelos empregam um navegador como ainterface para manipular transferência de informação entreas partes envolvidas na transação. No primeiro modelo, umcomerciante oferece mercadoria ou serviços em-linha por meiode um navegador. 0 termo "comerciante" refere-se aqui em ge-ral a qualquer entidade que oferece mercadoria e/ou serviçospara compra. 0 termo comerciante não se usa para descreverestado comercial particular ou descrever um vendedor licen-ciado, a menos que especificamente declarado. De preferência,o termo descreve genericamente qualquer vendedor ou entidadeque oferece mercadoria e/ou serviços para compra ou venda. 0 termo provedor de serviços é aqui usado alternadamente com otermo comerciante e, a menos que do contrário declarado, têmo mesmo significado.
Em uma transação em-linha convencional, um comer-ciante pode ter um sitio de rede que descreve, exibe ou do contrário oferece mercadoria e/ou serviços para venda. Umusuário final indica um desejo para comprar um ou mais demercadoria ou serviços, tipicamente selecionando o item pormeio da interface de navegador. O navegador depois exibe umapágina de transação que permite o usuário final selecionar um ou mais tipos de pagamento e introduzir informação neces-sária para concluir a transação. Por exemplo, a página tran-sacional exibida pelo navegador pode permitir ao usuário fi-nal selecionar um tipo de pagamento, como cartão de crédito(por exemplo, VISA, MasterCard, American Express, etc.) e introduzir informação transacional tal como número do cartãode crédito, data de expiração do cartão, etc. A página tran-sacional pode também consultar o usuário final para informa-ção pessoal como nome, endereço de faturamento, endereço detransporte, etc. O usuário final depois submete a informação e o comerciante processa a informação submetida.
Neste primeiro modelo, o comerciante tipicamente"possui" o sitio de rede. Ou seja, o comerciante mantém ositio de rede, é responsável pelo conteúdo e recebe e pro-cessa a informação transacional fornecida pelo usuário final.0 comerciante pode estabelecer uma conta com o usuário finalantes de conduzir a primeira transação e o usuário final po-de depois acessar aquela conta por meio de um registro deacesso e senha estabelecidos pelo usuário cada vez que o u-suário final conduz uma transação com o comerciante. Ou seja, o usuário final tipicamente seleciona um nome de registro deacesso e uma senha a serem usados em sessões ou transaçõessubseqüentes. Após o usuário final ter submetido a informa-ção consultada pela (s) transacional(is), o comerciante pro-cessa a informação para ter certeza que a informação é sufi-ciente para concluir a transação. Por exemplo, o comerciantepode assegurar que o número do cartão de crédito é válido etem fundos suficientes para cobrir o custo da mercadoriae/ou serviços.
0 segundo modelo tipicamente inclui um provedor detransação de terceiro que manipula a porção de pagamento datransação. 0 terceiro forma uma relação tanto com o usuáriofinal como com o comerciante. Em particular, o usuário finalpode estabelecer uma conta com o terceiro que pode ser aces-sada por meio de um registro de acesso e senha como debatidoacima - Para estabelecer a conta, o usuário final pode forne-cer informação pessoal e de pagamento ao terceiro (isto é, ousuário final pode fornecer informação pessoal que identifi-ca o usuário e informação de pagamento como um ou mais núme-ros de cartão de crédito, datas de expiração, etc.) 0 usuá-rio final pode também estabelecer uma conta de fundos ele-trônicos fornecendo dinheiro ao provedor da transação deterceiro, o saldo desta pode ser usado para comprar mercado-ria e/ou serviços em-linha. 0 terceiro arquiva a informaçãode conta fornecida pelo usuário final e/ou mantém o saldo dousuário final. terceiro também estabelece uma relação com o co-
merciante, em que o terceiro manipula o processamento de pa-gamento da transação. Em particular, o terceiro concorda emfazer pagamentos ao comerciante quando um usuário final comuma conta requerer uma transferência de fundos para fazer uma compra- O comerciante pode fornecer a opção de usar oterceiro através de sinalização da disponibilidade desta op-ção em seu sitio de rede onde a mercadoria e serviços estãosendo vendidos. Por exemplo, quando um usuário visita o si-tio de rede de um comerciante e decide fazer uma compra, o usuário pode depois ser apresentado com uma opção para pagarpela compra usando o provedor de transação de terceiro.
Quando o usuário final seleciona a opção para pa-gar pela compra usando o provedor de transação de terceiro,o navegador do usuário final é redirecionado para um sitio de rede que pertence ao provedor de transação de terceiro. Ousuário final depois acessa registrando em sua conta pormeio da combinação de registro de acesso/senha e selecionaum tipo de pagamento (por exemplo, cartão de crédito) parausar na transação, ou solicita uma transferência de fundos da conta de fundos do usuário para a conta do comerciante.Uma vez o comerciante determina que pagamento foi transferi-do apropriadamente pelo provedor de transação, o comerciantepode prosseguir para transportar o produto comprado ou for-necer o serviço comprado ao usuário final. No segundo modelo,o terceiro é responsável em manter a informação pessoal efinanceira do usuário final e em processar a transação.BREVE DESCRIÇÃO DOS DESENHOS
Nos desenhos, cada componente idêntico ou quaseidêntico que é ilustrado em várias figuras é representadopor um numerai igual, Para propósitos de clareza, nem todocomponente pode ser marcado em todo desenho. Nos desenhos:
FIG. 1 ilustra um diagrama de blocos de um sistemade computador em rede para executar transações em-linha, deacordo com uma modalidade da invenção;
FIG. 2 ilustra um diagrama de um sistema e métodopara iniciar e executar verificação de identidade em umatransação em-linha, de acordo com uma modalidade da invenção;
FIG. 3 ilustra um diagrama de um 'sistema e métodopara executar negociação de pagamento, verificação e/ou cer-tificação em uma transação em-linha, de acordo com uma moda-lidade da invenção;
FIG - 4 ilustra um sistema de computador em redepara conduzir transações em-linha, em que transações são ma-nipuladas, pelo menos em parte, por software de transaçãoinstalado em computadores conectados à rede, de acordo comuma modalidade da presente invenção;
FIG. 5 ilustra um sistema de computador em redepara conduzir transações em-linha, em que transações são ma-nipuladas, pelo menos em parte, por software de transaçãoinstalado em computadores conectados à rede, de acordo cooutra modalidade da presente invenção;FIG. 6 ilustra um sistema de computador em redepara conduzir licenciamento para aplicações instaladas em umcomputador de usuário final, em que a licença é obtida pormeio de uma transação em-linha, de acordo com uma modalidade da presente invenção;
FIG. 7A ilustra um sistema usado para autenticarum módulo móvel para uma rede para estabelecer uma comunica-ção segura entre eles de acordo com modalidades exemplares;
FIG. 7B ilustra um sistema usado para autenticarum usuário para uma rede usando um módulo móvel ao estabele-cer um canal de comunicação seguro de acordo com modalidadesexemplares;
FIG. 7C ilustra um sistema configurado para veri-ficação simples ou de multi-nivel de vários serviços dife- rentes usando um módulo móvel de acordo com modalidades e-xemplares;
FIG. 8 ilustra uma permuta segura de três-modos deinformação de pagamento e federação de pagamento de acordocom modalidades exemplares;FIG 9 ilustra vários usos de um subsistema de
transação comercial e apresentação de conta de acordo commodalidades exemplares;
FIG 10 ilustra o uso de opções de pagamento e re-gras para determinar que tipo de provedor de pagamento deve- ria ser usado para uma transação comercial de acordo com mo-dalidades exemplares; e
FIG 11 ilustra um dispositivo de módulo de identi-dade de assinante (SIM) configurado com uma barreira de pro-teção para conformar aos protocolos de comunicação de redede rádio estabelecidos quando usados para transações comer-ciais de acordo com modalidades exemplares.
SUMÁRIO DA INVENÇÃO
Transações em-linha convencionais, por exemplo, acompra de mercadoria e/ou serviços em uma rede, estão vulne-rável a quebras de segurança que resultam em perda de infor-mação pessoal, financeira e/ou outra confidencial- Além dis-so, em uma rede não-confiada (por exemplo, a Internet), co-merciantes e compradores estão em risco de entrar em umatransação com um ator ruim de modo que um lado da barganhanão é sustentado. Modelos de transação em-linha convencio-nais podem também requerer de um comerciante arquivar a in-formação confidencial do comprador e a requerer para manipu-lar aspectos de pagamento da transação. Além disso, modelosde transação em-linha convencionais são desajeitados para ocomprador e produzem uma experiência de transação em geralnão-intuitiva. Por exemplo, transações em-linha convencio-nais são conduzidas por meio de um navegador usando um para-digma de registro de acesso/senha que é confuso e dificil degerenciar.
0 requerente tem identificado e apreciado que de-legando pelo menos algumas das responsabilidades transacio-nais manipuladas pelo comprador e navegador em modelos con-vencionais a sistemas de nivel inferior (e longe do navega-dor e usuário final), pode facilitar uma estrutura de tran-sações comerciais em-linha mais simples e mais seguras. Porexemplo, uma ou mais tarefas transacionais podem ser manipu-ladas pelo sistema operacional para um ou ambos do usuáriofinal e comerciante onde a informação pode ser salvaguardadacom mais segurança. Embutindo uma ou mais tarefas no sistemaoperacional, os usuários podem ser aliviados de algum dofardo de transferir informação transacional, tornando a ex-periência mais intuitiva e reforçando a segurança. Além dis-so, o comerciante pode ser aliviado de manter informação docomprador, manipular a informação de pagamento e/ou proces-sar a transação.
sociados à validação da identidade de um comprador podem sermitigados explorando tecnologias mais seguras e convenientesque o modelo de registro de acesso/senha. Em uma modalidade,informação de identidade acerca de um comprador é fornecidapor um cartão de módulo de identidade de assinante (SIM) quearmazena informação de identidade acerca do usuário finalque pode ser emitido programaticamente, criando uma experi-ência de compra menos confusa e mais direta. Além disso, mo-dalidades aqui provêem protocolos, métodos, sistemas de com-putação e outros mecanismos configurados para autenticaçãosimples ou de multi-nivel usando um dispositivo de SIM emuma rede do contrário não-confiada ou insegura (por exemplo,a Internet).
vários elementos transacionais de transações comerciais em-linha usando terceiros em geral desinteressados mitiga ris-cos envolvidos para o comprador e o comerciante. Em um as-pecto da invenção, um sistema de transação comercial é for-
Requerente
tem também apreciado que problemas as-
requerente tem também
apreciado que fornecendonecido em que uma primeira entidade de rede fornece verifi-cação da identidade de um comprador e uma entidade de redediferente fornece verificação da habilidade de um usuário depagar pela compra, de modo que o comerciante e um compradorque são estranhos um para o outro possam conduzir uma tran-sação em segurança relativa.
Ainda outras modalidades permitem uma transaçãocomercial segura de três modos entre comerciante, consumidore pagamento provida em um tal modo que a informação de conta de faturamento sensível é opaca ao comerciante ou terceiros.Em uma tal modalidade, sinais de pagamento são passados pormeio do consumidor entre o comerciante e provedor de paga-mento . Tais sinais de pagamento são criptografados ou assi-nados em um tal modo que o comerciante e outros não contro- Iam ou obtêm qualquer informação de conta sensivel para oconsumidor. Não obstante, o comerciante ainda pode validarconfiantemente o sinal de pagamento indicando a habilidadedo consumidor para pagar pelos serviços e/ou mercadoria for-necidos . Em outra modalidade, informação de faturamento e-
letrônica é usada para autorização de pagamento, auditoria eoutros propósitos. Nesta modalidade, várias entidades de re-de (por exemplo, o consumidor, comerciante, provedor de pa-gamento, etc.) são fornecidas com uma conta eletrônica legi-vel por máquina, que é usada para automaticamente requerer evalidar pagamento, criar uma história de transação, apresen-tar uma descrição mais precisa dos serviços/mercadoria li-quidados e para outros propósitos em uma transação comercialem-linha. Esta informação de faturamento pode também ser u-sada para federação de pagamento de um pagamento simples deum consumidor para vários sócios empresariais para o comer-ciante. Por exemplo, o comerciante pode ter uma relação con-tratual com vários sócios empresariais que fornecem serviçose/ou mercadoria na transação comercial. A informação de fa-turamento eletrônica pode incluir aquelas porções de paga-mentos que serão distribuídas entre os vários sócios de modoque a federação de pagamento possa ocorrer automaticamentesem qualquer necessidade de interação do usuário ou mecanis-mos de auditoria e de pagamento separados.
Fornecidos aqui são também mecanismos para deci-sões automatizadas de uma transação comercial usando regrasou restrições definidas por qualquer número de entidades derede incluindo o consumidor, comerciante, provedor de paga-mento, etc. Por exemplo, as opções de pagamento aceitas pelocomerciante podem ser comparadas com as opções de pagamentodisponíveis ao consumidor. Com base em tal comparação, oconsumidor pode ser apresentado apenas àquelas opções queequiparam. Alternativamente, a opção de pagamento pode serselecionada automaticamente com base em tal comparação e/oucom base em regras ou restrições adicionais. Por exemplo, oconsumidor pode limitar o tipo de pagamentos com base em umaconfiança estabelecida com o comerciante. Claro que, podehaver muitos outros tipos de regras e/ou restrições que de-terminam várias ações que podem ocorrer na transação comer-cial .
DESCRIÇÃO DETALHADAModelos convencionais para transações comerciaisem rede focalizam no navegador como a interface para reque-rer e submeter informação pessoal e financeira entre o com-prador de usuário final e comerciante ou provedor de servi-ços, se for diretamente através do comerciante ou por meiode um provedor de transação de terceiros. Em primeiro lugar,o comerciante é encarregado em criar e manter uma infra-estrutura capaz de consulta, obter, manipular e processarinformação pessoal e financeira, tipicamente com algum nivelminimo de segurança. Além disso, o comerciante pode ser res-ponsável em manter contas e informação de conta para cada umde seus clientes (que tipicamente inclui tanto informaçãopessoal como financeira confidencial).
Um comprador tem que ceder informação pessoal (porexemplo, nome, endereço, número de telefone, etc.) e infor-mação financeira (por exemplo, números de cartões de débitoe de crédito e datas de expiração, números de conta bancária,etc.) para concluir uma transação. Em algum nivel, o compra-dor tem que confiar que o comerciante é um agente honesto eoperará de boa fé, usando a informação apenas conforme auto-rizado. Igualmente, um comerciante tem que confiar que umcomprador é quem ele/ela representa e que a informação depagamento fornecida é verdadeiramente associada ao usuáriofinal que faz a compra. Não pode haver nenhum modo seguropara um comerciante validar a identidade do comprador e/ou avalidez da informação de pagamento. Em um ambiente em rededistribuída, compradores podem ter que confiar na reputaçãdo comerciante, que pode limitar as fontes das quais o com-prador está disposto conduzir transações. 0 comerciante podeter operando com até mesmo menos convicção que o comprador éum comprador de boa fé, bona fide. Em uma rede não-confiada,este modelo pode apresentar riscos impróprios em uma ou am-bas as partes.
Até mesmo quando uma confiança estabelecida e me-recida desenvolveu-se entre o comprador e um comerciante,bases de dados que armazenam informação de cliente mantidaspelo comerciante podem ser suscetiveis a golpe, roubo de in-formação e até mesmo os atores ruins dentro um negócio docontrário honesto e confiável. Provedores de transação deterceiros são também suscetiveis a roubo eletrônico, quebrade segurança, etc. Programas "espiões" mais sofisticadospermitem aos violadores registrarem batidas de tecla e obtercapturas de tela de computadores que foram comprometidos,tornando as transações com base em navegador particularmentevulneráveis a roubo eletrônico. Conseqüentemente, comprado-res que conduzem transações comerciais em-linha de acordocom os métodos e modelos convencionais podem ser vulneráveisà disseminação e uso sem autorização de sua informação pes-soal e financeira confidencial.
Modelos de transação comercial convencional tipi-camente requerem um comprador para estabelecer uma conta comcada comerciante com o qual o comprador quer conduzir umatransação comercial. Em geral, a conta é protegida e acessa-da por meio de um nome de registro de acesso e senha, reque-rendo de um comprador gerenciar os múltiplos registro de a-cesso e senhas e manter aquela combinação de registro de a-cesso/senha que corresponde àquela conta. Alguns clientespodem recorrer em localmente armazenar suas combinações deregistro de acesso/senha em seu computador, ou usar a mesmacombinação de registro de acesso/senha para todas as contas.Ambas as tentativas de gerenciar contas múltiplas são vulne-ráveis a roubo, violação e/ou outras quebras de segurança.
Por exemplo, um cliente está em risco de ter todassuas contas violadas deve a combinação de registro de aces-so/senha simples ser obtida através de roubo eletrônico. A-lém dos riscos de segurança inerentes associados aos para-digmas de registro de acesso/senha convencionais, os compra-dores podem achar o procedimento de registro de acesso deconta uma experiência de transação desajeitada. Em particu-lar, tendo acessado registrando em uma conta quando uma com-pra for desejada torna a transação menos conveniente, comoum comprador deve, em de um jeito ou de outro, produzir estainformação antes de uma transação puder ser concluída. Alémdisso, com provedores de transação de terceiros, o compradoré redirecionado do sitio de rede de um comerciante para ositio de rede do provedor de transação de terceiros. Estaetapa não é intuitiva e, na melhor hipótese, é incômoda econfusa para o comprador.0 requerente tem identificado e apreciado que de-legando pelo menos algumas das responsabilidades transacio-nais manipuladas pelo comprador e navegador em modelos con-vencionais para sistemas de nivel inferior (e longe do nave-gador e usuário final), pode facilitar uma estrutura detransações comerciais em-linha mais simples e mais segura.Em uma modalidade, uma ou mais tarefas transacionais são ma-nipuladas pelo sistema operacional (ou algum outro subsiste-ma confiado) para um ou ambos do usuário final e comercianteonde a informação pode ser salvaguardada com mais segurança.Embutindo uma ou mais tarefas no sistema operacional, os u-suários podem ser aliviados de algum do fardo de transferirinformação transacional, tornando a experiência mais intui-tiva e reforçando a segurança. Além disso, o comerciante po-de ser aliviado de manter a informação do comprador, manipu-lar a informação de pagamento e/ou processar a transação.
Requerente tem também apreciado que problemas devalidação associados à identidade do usuário podem ser miti-gados explorando tecnologias mais seguras e convenientes queo modelo de registro de acesso/senha. Em uma modalidade, ainformação de identidade acerca de um comprador é fornecidapor um cartão de módulo de identidade de assinante (SIM) quearmazena informação de identidade acerca do usuário finalque pode ser emitida programaticamente. Em outra modalidade,informação de identificação é fornecida por um cartão inte-ligente embutido ou do contrário acoplado a um dispositivode rede do qual um comprador conduz uma transação comercialem-linha. Uso de quaisquer de vários dispositivos de identi-dade com base em chip ou cartão permite um comprador conec-tar sua identidade com um dispositivo particular, como umtelefone celular ou um computador em rede.
0 termo "programaticamente" e/ou "automaticamente"refere-se às ações executadas substancialmente sem envolvi-mento manual ou do operador. Em particular, programatico ouautomático refere-se às ações iniciadas e/ou executadas porum ou mais programas de computação. Por exemplo, fornecendoinformação de identificação requerendo de um usuário (porexemplo, comprador) fornecer informação de registro de aces-so e/ou senha não seria considerado programatico uma vez quea substância da ação é executada pelo usuário. Porém, umaação em que um programa emite informação de identificação(por exemplo, um número de SIM, hardware de endereço de redeID, etc.) sem requerer do usuário que introduza a informaçãoseria considerado programatico. Observe que tais operaçõesautomáticas podem ser implementadas por componentes de soft-ware ou de hardware.Requerente tem também apreciado que distribuindovários elementos transacionais de transações comerciais em-linha em dispositivos de rede diferentes, facilita transa-ções comerciais mais seguras em uma rede não-confiada. Emuma modalidade, provedor de identidade e um provedor de pa-gamento, entidades de rede tanto separadas como distintas dousuário final, comerciante e um ao outro, provêem suporte deverificação durante uma transação comercial. 0 termo "enti-dade de rede" refere-se aqui a uma presença de rede e podeser um ou uma combinação de usuário final/comprador, prove-dor de identidade, provedor de pagamento, comerciante, etc.Uma entidade de rede pode ter uma presença em uma rede pormeio de um ou múltiplos nós de rede. Por exemplo, dispositi-vos em rede múltiplos podem operar sob os patrocínios de umaentidade de rede simples, como um provedor de identidade queutiliza servidores múltiplos para conduzir negócio em-linha,ou um usuário final conectado a uma rede por meio de um te-lefone celular e um computador pessoal. Uma entidade de redepode ser um negócio como um banco ou varej ista, ou um indi-víduo como um usuário final.Em uma modalidade, vários elementos de uma transa-
ção em-linha são distribuídos em entidades de rede separadase independentes. Por exemplo, o provedor de identidade podefornecer validação de identidade na forma de um sinal de i-dentidade que o comerciante pode usar para verificar aidentidade do comprador. 0 sinal de identidade pode incluiruma ou mais credenciais de identidade do usuário final. 0sinal de identidade pode ser emitido com base na informaçãode identidade fornecida pelo usuário final/comprador, porexemplo, o número de assinatura do cartão SIM, um endereço de rede (por exemplo, uma identificação da Placa deInterface de Rede (NIC), Nome Mundial (WWN) , etc),informação de registro de acesso, etc. Similarmente, oprovedor de pagamento pode fornecer verificação dahabilidade do usuário final para pagar na forma de um sinal de pagamento. Além disso, o provedor de pagamento podemanipular transações de pagamento em nome do comprador emsatisfação da compra de mercadoria e/ou serviços docomerciante. A estrutura acima descrita possibilita, interalia, o comprador e o comerciante que são estranhos conduzirem uma transação comercial em-linha em um ambientede rede não-confiada em confiança relativa, como debatido emmais detalhes nas várias modalidades exemplares fornecidasabaixo. Por exemplo, uma modalidade prove uma comunicaçãosegura de três modos entre o comerciante, consumidor e pro-vedor de pagamento durante uma transação comercial para com-prar serviços e/ou mercadoria em ou um ambiente em-linha oude varejo. Como será debatido em maior detalhe abaixo, ossinais de pagamento são passados do provedor de pagamentopara o comerciante por meio do consumidor. Tais sinais depagamento oferecem prova da habilidade do consumidor parapagar pelo serviço e/ou mercadoria permitindo o comerciantevalidar a autenticidade do sinal diretamente com o provedorde pagamento. Embora tais sinais de pagamento identificam aautorização de pagamento exclusivamente para os serviçose/ou mercadoria, informação sensível acerca da conta de fa-turamento para o consumidor ou não estão inclusas dentro dosinal ou do contrário criptografadas para ser invisível aocomerciante. Conseqüentemente, a informação sensível do con-sumidor é opaca ao comerciante, assim permitindo o consumi-dor comprar confiantemente itens do comerciante até mesmoquando nenhuma relação confiada existe entre eles. Também,porque o comerciante pode validar o sinal de pagamento dire-tamente com o provedor de pagamento, o comerciante pode li-berar os itens com confiança da habilidade do consumidor pa-ra pagar por tais serviços e/ou mercadoria sem manter infor-mação financeira acerca do consumidor (por exemplo, númerosde cartão de crédito, informação de conta, etc.). Além disso,porque o provedor de pagamento pode validar a autenticidadedo sinal de pagamento como vindo do consumidor, o provedorde pagamento pode confiantemente transferir fundos para ocomerciante; desse modo completando a transação comercialsegura de três modos.
Como previamente mencionado, outras modalidadespara a estrutura fornecida aqui movem porções da transaçãopara subsistemas mais seguros de um dispositivo de computa-ção (por exemplo, o sistema operacional). Isto vantajosamen-te permite numerosas capacidades incluindo: um modelo deabstração para permitir aplicações de legado para fornecerexperiência de transação comercial em-linha dentro da banda;tipos adicionais de proteção de fraude; captura de conta eapresentação para auditoria, federação de pagamento, e ou-tros propósitos de pagamento ou de autenticação; .execução decódigo de provedor de serviços para segurança adicional efuncionalidade especifica mercantil; autenticação de multi-nivel; e outras características. Por exemplo, tal modelo deabstração permite legado e outras aplicações proverem a umusuário uma compra em-linha e capacidades de pagamento comose tal transação ocorresse diretamente dentro da aplicação,embora porções da transação comercial sejam executadas fora-da-banda. Exemplos incluem compra de catálogo (por exemplo,Amazon, Sears, etc), compra direta de conteúdo de multimí-dia de dentro da aplicação de multimídia, transferência desoftware/games em modo de ensaio e automaticamente os des-travar através de modelo de pagamento de dentro-da-banda,permissão de pagamento para serviços com base em assinaturacomo serviço de mensagem simples através de e-mail, etc.
Também, em outra modalidade, a estrutura captura eapresenta contas eletrônicas nas transações comerciais segu-ras de três modos acima (e outras) como um mecanismo paraautenticação adicional, auditoria, federação de pagamento eoutros propósitos serão descritos em maior detalhe abaixo.Além disso, movendo a transação comercial para porções maisseguras do subsistema, outras modalidades permitem um comer-ciante operar o código especifico em uma máquina (por exem-plo, autenticação de usuário adicional, regras/mecanismos depagamento, experiência de usuário, etc.) com confiança quetal código não será violado ou do contrário comprometido.Claro que, como descrito em maior detalhe abaixo, o Reque-rente tem outras características vantajosas percebidas tam-bém através do uso do modelo de abstração fornecido aqui.Em outra modalidade, Requerente também prove umsistema geral e protocolo que usam um módulo móvel para co-municação segura e autenticação de identidade e capacidadesde pagamento para uma variedade de serviços diferentes. Porexemplo, um módulo de identidade de assinante (SIM) (ou ou-tro módulo móvel similar) pode ser usado para autenticar umusuário e/ou dispositivo para um serviço ou servidor em umambiente de validação de multi-nivel. Em tal modalidade, omódulo móvel (e possivelmente até mesmo o usuário) é auten-ticado em uma rede independente da rede infra-estrutura mó-vel para o módulo móvel. Desse modo, o sistema valida a pos-se de um módulo móvel através de autenticação de uma contade faturamento ativa com a infra-estrutura móvel. Isto esta-belece uma comunicação segura com um dispositivo de computa-ção conectado ao módulo móvel e um serviço (por exemplo, unsServiços de Rede (WS)) usando protocolos seguros existentes(por exemplo, autenticação de WS, segurança de WS e outrosprotocolos similares). Tal comunicação segura pode tambémser usada para autenticar o usuário através de outros proto-colos e permutas de dados entre o módulo móvel e a infra-estrutura móvel — como descrito em maior detalhe abaixo. A-demais, outras modalidades provêem um protocolo e máquina deestado que abstrai o dispositivo de computação (usado na co-municação na rede independente) da infra-estrutura móvel.Conseqüentemente, o próprio módulo móvel se torna um termi-nal móvel e o dispositivo de computação se torna um disposi-tivo periférico, desse modo obedecendo aos padrões sem fiosatuais como 3GPP (Projeto de Parceria de 3a Geração)-
FIG. 1 ilustra um diagrama de blocos de um sistemade transação comercial 100, compreendendo uma pluralidade denós de rede incluindo um computador de usuário final (com-prador) 110, um computador de comerciante 140, computador deprovedor de identidade 120 e computador de provedor de paga-mento 130. Cada um dos nós acima pode incluir um ou maisdispositivos de computação interconectados por meio de rede
105. Deveria ser apreciado que o computador de usuário final,comerciante 140, provedor de identidade 120 e provedor depagamento 130 podem estar associados a uma entidade de rede,como um indivíduo, companhia ou negócio. Por exemplo, compu-tador de usuário final 110 tipicamente é associado a um in-divíduo que emprega o computador para acessar recursos narede e computador de comerciante 140 pode ser associado auma corporação ou empresa oferecendo mercadoria e/ou servi-ços à venda. O um ou mais dispositivos de computação queformam cada componente mencionado no sistema de transaçãocomercial 100 podem operar como o ponto de entrada, plata-forma de computação e/ou veiculo pelo qual as entidades derede associadas se comunicam na rede.
Note que embora modalidades fornecidas aqui possamser descritas em um ambiente de compra em-linha, as modali-dades podem também ser usadas em uma transação de varejo di-reta. Por exemplo, a descrição acima e a seguir de uma tran-sação comercial pode aplicar a um consumidor que compra pro-dutos em um armazenamento de varejo, em que pagamento, iden-tidade, autorização e outras modalidades são usados. Conse-qüentemente , o uso de uma experiência em-linha para descre-ver modalidades aqui é para propósitos ilustrativos apenas enão é significado limitar ou do contrário estreitar o escopoda modalidade a menos que do contrário explicitamentereivindicado.Também note que a rede 105 pode ser qualquer tipode rede em qualquer tipo de configuração que interconecta epermite nós conectados à rede se comunicarem. Nós ou dispo-sitivos podem ser conectados à rede por meio de cabo de co-bre (por exemplo, Categoria 5), conexões ópticas, sem fiosou qualquer combinação destes. Informação pode ser transfe-rida usando qualquer protocolo de nivel baixo como Ethernete/ou qualquer protocolo de informação como TCP/IP. A rede105 pode ter qualquer número de dispositivos conectados aela e pode ser uma confiada (por exemplo, intranet) ou umarede não-confiada (por exemplo, LAN/WAN, Internet, etc), ouuma combinação de ambas. Os computadores conectados à redepodem ser qualquer tipo de dispositivo incluindo, mas nãolimitados a, um ou qualquer combinação de um telefone móvel,um computador de mesa, um computador pessoal de tablete, umservidor, estação de trabalho, etc.
FIG. 2 ilustra um diagrama de um sistema e métodopara iniciar e executar verificação de identidade em umatransação em-linha, de acordo com uma modalidade da invenção,e FIG. 3 ilustra um diagrama de um sistema e método para e-xecutar negociação de pagamento, verificação e/ou certifica-ção em uma transação em-linha, de acordo com uma modalidadeda invenção. Os métodos podem ser usados separadamente ou emcombinação para executar uma transação em-linha entre um u-suário final/comprador e comerciante. Na descrição a seguir,a menos que especificamente apontado, nenhuma distinção éfeita entre a entidade de rede e seus dispositivos em redeassociados. Por exemplo, "provedor de identidade" é usadogenericamente para descrever o provedor de identidade comouma entidade (por exemplo, um banco, organização governamen-tal, agência, etc.) e como os dispositivos de computação quea entidade utiliza para executar várias funções de rede, co-mo prover verificação de identidade para um usuário final,ou operar do contrário no lado da entidade.Um computador de usuário final 110 pode fazer umpedido 242 com um comerciante 140. A ordem 242 pode serqualquer indicação que o usuário final gostaria de comprarum ou mais mercadoria e/ou serviços do comerciante 14 0. Porexemplo, a ordem 242 pode resultar de usuário final que se-leciona um bem ou serviço por meio de um navegador de redeque exibe as páginas residentes no sitio de rede de um co-merciante, ou pode ser o resultado de selecionar uma opçãode uma aplicação operando localmente, como descrito em outrodetalhe abaixo. Como um exemplo da primeira circunstância, ocomerciante 14 0 pode fornecer um sitio de rede para exibirou do contrário oferecer mercadoria e/ou serviços à vendaque ele fornece, ou pode fornecer um catálogo de mercadoriaem-linha. A ordem 242 pode ser qualquer tipo de indicaçãoque o usuário final gostaria de comprar um ou mais mercado-ria e/ou serviços do comerciante 140.Como um exemplo da segunda circunstância e comouma alternativa para selecionar um ou mais mercadoria e ser-viços do sitio de rede de um comerciante, a ordem 242 podeoriginar de uma aplicação ou outro programa local para ocomputador de usuário final 110. Por exemplo, um usuário fi-nal pode criar, produzir ou editar um documento por meio deuma aplicação de processamento de textos, elaborar uma apre-sentação de slides usando uma aplicação de apresentação e/oumanipular imagens ou gráficos para um cartaz ou panfleto u-sando uma aplicação de imageamento. A aplicação pode incluiruma opção sob o menu de impressão que permite imprimir o do-cumento por um terceiro, por exemplo, para tirar proveitodas características de impressão que podem não estar local-mente disponíveis, ou explorar serviços de impressão profis-sionais do contrário. Quando a opção for selecionada, a a-plicação pode enviar, por meio da rede, ordem 242 para o co-merciante 140. Deveria ser apreciado que a ordem 242 podeser qualquer indicação para comprar qualquer bem e/ou servi-ço, visto que os aspectos da invenção não são limitados nes-te respeito.
Em resposta à ordem 242, o comerciante 140 poderequerer que o usuário final 110 forneça uma indicação daidentidade do usuário final e/ou verificação quem o usuáriofinal de fato pretende ser (etapa 205) - Por exemplo, o co-merciante 140 pode não saber nada sobre a fonte de ordem 242e pode desejar informação acerca da identidade do usuáriofinal e/ou garantia que o usuário final não esteja se pas-sando por sua identidade. Alternativamente, o comerciante14 0 pode enviar uma notificação ou indicação que o pagamentoé requerido para o serviço e demandar que um sinal de paga-mento seja fornecido. Para obter um sinal de pagamento, podeser necessário estabelecer uma identidade primeiro por meiode um sinal de identidade, como descrito em mais detalhes abaixo. Em qualquer caso, o usuário final 110 pode responderà solicitação pelo comerciante 140 recrutando os serviços deprovedor de identidade 120 (etapa 215).
Para obter um sinal de identidade, o usuário final14 0 fornece informação de identidade ao provedor de identi-dade 120. Informação de identidade pode incluir qualquer in-formação que permite o provedor de identidade 120 distinguirentre usuário final utilizando o computador do usuário final110 e os vários outros usuários finais aos quais o provedorde identidade pode fornecer serviços. Por exemplo, a infor- mação de identidade pode incluir um único identificador as-sociado ao hardware de computador de usuário final 110. Emuma modalidade, a informação de identidade é fornecida porum cartão SIM que emite um identificador único para o assi-nante. Informação de identidade pode incluir fornecer um ú-nico número de hardware da placa de interface de rede (NIC)do computador de usuário final 110, um nome mundial (WWN) ououtro endereço de rede de computador de usuário final 110 ouquaisquer outros meios pelos quais o computador de usuáriofinal 110 pode ser identificado, incluindo (em algumas moda-lidades) uma combinação de nome de registro de acesso/senhaestabelecidos.
Provedor de identidade 120 usa a informação de i-dentidade para localizar credenciais de identidade associa-das ao usuário final. Por exemplo, o provedor de identidade120 pode incluir uma base de dados que armazena informaçãoda identidade e credenciais em uma pluralidade de usuáriosfinais. A informação de identidade pode ser usada para inde-xar na base de dados para obter as credenciais de identidadecorretas. O provedor de identidade 120 pode ser qualquer ti-po de entidade- Por exemplo, o provedor de identidade 120pode ser uma companhia telefônica móvel que usa o número deassinante fornecido pelo cartão SIM do usuário final paralocalizar a informação de identificação apropriada. Em umamodalidade o número de assinante é usado para localizar eobter informação fornecida pelo usuário final na hora da'as-sinatura para o telefone celular ou outro dispositivo queexplora tecnologia SIM. O provedor de identidade 120 podeser um banco, uma agência do governo (como o registro de au-tomóveis (RMV)), ou qualquer outra facilidade que mantém in-formação de identificação ou credenciais associadas aos usu-ários finais.Em resposta à informação de identidade fornecidapelo usuário final, provedor de identidade 120 fornece umsinal de identidade ao computador de usuário final 110 quefornece autenticação de identidade e/ou credenciais acercado usuário final (etapa 225). O sinal de identidade pode serqualquer tipo de mensagem eletrônica que outro dispositivode rede pode usar para autenticar, verificar e/ou determinara identidade de um usuário final. Por exemplo, o sinal deidentidade pode incluir credenciais de identidade do usuáriofinal. Credenciais de identidade podem incluir, mas não sãolimitadas a, qualquer um de ou combinação de nome, data deaniversário, endereço, número de telefone, endereço de e-mail, etc.O sinal de identidade pode incluir uma assinaturaeletrônica do provedor de identidade 120 que certifica queas credenciais de identidade estão corretas. Desse modo, co-merciante e/ou provedor de pagamento podem confiar em umterceiro desinteressado (isto é, provedor de identidade), aoinvés das representações de um usuário final arbitrário. Osinal de identidade pode ser criptografado antes de sertransmitido na rede e pode ser descriptografado quando rece-bido pelo dispositivo de rede desejado (por exemplo, comer-ciante, provedor de pagamento, etc, como debatido em maisdetalhes abaixo), para proteger contra intrometidos na rede.Em outras modalidades, o sinal de pagamento é meramente umacertificação da identidade do usuário final sem informaçãode identidade em anexo.
O provedor de identidade 120 pode transmitir o si-nal de identidade para o computador de usuário final 110 pa-ra remeter para o comerciante 140 (etapa 235), e/ou provedorde identidade 120 pode transmitir o sinal de identidade di-retamente para o comerciante 140. Comerciante 140 pode de-pois processar o sinal de identidade para identificar o usu-ário final e/ou verificar que o usuário final é quem elepretende ser. O sinal de identidade pode ser usado para au-tenticar certa informação acerca do usuário final que podeafetar a transação. Por exemplo, o comerciante 140 pode for-necer um serviço que requer que o usuário final seja de umacerta idade. Credenciais de identidade transmitidas podemser usadas com o sinal de identidade para assegurar que ousuário final é da idade apropriada e satisfaz este requeri-mento . Comerciante 14 0 pode ter descontos para usuários fi-nais particulares que são os compradores freqüentes, ou quereceberam um cupom, oferta de promoção, etc. O comerciante140 pode indexar uma base de dados de usuários final paradeterminar se o usuário final qualifica ou deveria ser docontrário especialmente manipulado com base nas credenciaisde identidade fornecidas.
Opcionalmente, o comerciante 140 pode requerer va-lidação do sinal de identidade enviando uma solicitação aoprovedor de identidade 120 (etapa 245) . A solicitação paravalidação do sinal de identidade pode incluir envio do sinalde identidade de comerciante 140 para o provedor de identi-dade 120. Ao receber a solicitação para validação do sinalde identidade, o provedor de identidade 120 pode validar osinal de identidade, e assim determinar se o sinal de iden-tidade é autêntico. 0 provedor de identidade 120 pode depoisremeter uma indicação da validez do sinal de identidade parao comerciante 140 (etapa 255) . Alternativamente, o comerci-ante 140 pode validar o próprio sinal de identidade simples-mente (etapa 265) (por exemplo, assumindo que o sinal de i-dentidade é válido ou processando o sinal do contrário). Op-cionalmente, uma resposta pode ser devolvida do comerciante140 para o computador de usuário final 110, onde a respostapode incluir uma mensagem se o sinal de identidade é válido,de qualquer desconto aplicável ou ofertas de promoção, e/ouqualquer outro tipo de mensagem, uma vez que a invenção nãoé limitada neste respeito (etapa 265) .Após o comerciante 14 0 ter processado o sinal deidentidade e/ou recebido uma validação para o sinal de iden-tidade do provedor de identidade 120, o comerciante 140 poderequerer que o usuário final forneça verificação ou valida-ção de uma habilidade para pagar e/ou fornecer uma indicaçãode como o usuário final gostaria de pagar pela mercadoria ouserviços. O comerciante 140 pode fazer a solicitação pormeio de uma solicitação de pagamento de sinal (etapa 305 naFIG• 3). Em resposta à solicitação de pagamento de sinal, ocomputador de usuário final 110 pode recrutar os serviços deum provedor de pagamento 130. Provedor de pagamento 130 podeser associado a um terceiro que mantém informação financeirae de pagamento acerca de vários usuários finais, como umainstituição financeira, ou um corretor de terceiros que ma-nipula transações financeiras e procedimentos de pagamento.
O computador de usuário final 110 pode solicitarum sinal de pagamento de um provedor de pagamento 130 (etapa315) transmitindo o sinal de identidade ao provedor de paga-mento 130. Alternativamente, o usuário final pode requererum sinal de pagamento registrando o provedor de pagamento130 de uma maneira similar àquela debatida com relação aoprovedor de identidade 120 (isto é, fornecendo um identifi-cador como um número de assinante SIM, endereço de NIC e/ouusando uma combinação de registro de acesso/senha). Deveriaser apreciado que o usuário final pode requerer um sinal depagamento de outros modos, como a invenção não está limitadaneste respeito. Além disso, o usuário final pode enviar in-formação acerca da compra, como o preço e natureza da comprade forma que o provedor de pagamento pode verificar que ousuário final é capaz de pagar. Porém, fornecer informaçãode compra não é requerido, como pode não ser necessário oupode ser manipulado em etapas subseqüentes da transação.Provedor de pagamento 130 processa o sinal de i-dentidade (ou outro identificador fornecido) para localizarinformação acerca do usuário final. Por exemplo, o provedorde pagamento 130 pode acessar uma base de dados de informa-ção de pagamento com base nas credenciais de identidadetransmitidas com o sinal de identidade. Provedor de pagamen-to 130 pode determinar quais capacidades e opções de paga-mento que o usuário final identificado tem disponível. 0provedor de pagamento 130 pode depois verificar que o usuá-rio final tem a habilidade para pagar, e em resposta gerar etransmitir um sinal de pagamento ao computador de usuáriofinal 110 (etapa 325) . O sinal de pagamento pode indicar ahabilidade do usuário final para pagar e/ou uma certificaçãoque o provedor de pagamento 130 está disposto para manipulara transação no lado do usuário final. O computador de usuá-rio final 110 pode depois remeter o sinal de pagamento parao comerciante 140 (etapa 335) .O comerciante 14 0 processa o sinal de pagamento demodo que o comerciante 140 esteja satisfeitos que o usuáriofinal seja capaz de pagar pela mercadoria ou serviços (etapa365) . Por exemplo, o comerciante 140 pode perguntar ao pro-vedor de pagamento 130 paa validar o sinal de pagamento (e-tapas 345, 355) ou validá-lo simplesmente (etapa 365) (porexemplo, assumindo o sinal de pagamento é válido ou proces-sando o sinal do contrário)- O comerciante 140 pode depoiscomeçar o processo de fornecer a mercadoria e/ou serviçospara o usuário final. Porque o provedor de pagamento 130 po-de ser um terceiro desinteressado, o comerciante 140 podetratar o sinal de pagamento essencialmente como pagamento epode não ter que aguardar até que a transação seja processa-da completamente.
Quando um comerciante trata diretamente com o usu-ário final em modelos transacionais convencionais, o comer-ciante pode ter que assegurar que a informação de pagamentofornecida pelo usuário final estej a correto e suficiente.Por exemplo, um comerciante pode ter que passar um número decartão de crédito fornecido através do sistema de cartão decrédito para consultar se o número é válido, o cartão é vá-lido, há fundos suficientes e/ou o cartão é corretamente as-sociado à identidade fornecida pelo usuário final. Se algonão confirmar, a transação pode ter que ser cancelada, ter-minada ou abandonada. Além disso, a terminação da transaçãopode acontecer após o usuário final perceber que a transaçãoestar concluída e já não estiver acessando a rede e/ou jánão estiver acessando o sitio de rede do comerciante, etc.0 comerciante pode depois ter que notificar o usu-ário final que havia um problema com a transação e o usuáriofinal terá que passar novamente por meio da transação paracorrigir o problema (por exemplo, introduzindo informação depagamento corretamente, especificando um cartão diferentecom fundos suficientes, etc.). Em algumas circunstâncias, ousuário final pode não ser notificado e a transação comerci-al pode nunca ser concluída.
Em várias modalidades debatidas aqui, porque umsinal de pagamento não é emitido que a menos que a informa-ção de pagamento de usuário final esteja correta, fundos su-ficientes estejam disponíveis e/ou o provedor de pagamentodo contrário certifica que pagará no lado do usuário final,o comerciante pode prosseguir imediatamente com a transação.Qualquer deficiência na transação pode ser identificada emtempo real e tratada de forma que todas as partes possam es-tar relativamente certas que estão sendo satisfeitas para asexpectativas com respeito à conclusão da transação.
Além disso, porque o provedor de pagamento podemanipular a transação financeira (por exemplo, manipulando ocartão de crédito, transferindo fundos, etc), o comerciantepode ser aliviado de estabelecer e manter a infra-estruturanecessária para, por exemplo, processar números de cartão decrédito ou do contrário manipular procedimentos de pagamentoe transferência de fundos. 0 sinal de pagamento, em algunscasos, opera como uma garantia que o provedor de pagamentotransmitirá os fundos designados, por exemplo, mandando odinheiro ou ordenando uma transferência eletrônica de fundospara o comerciante. 0 sinal de pagamento pode também ser umagarantia que o pagamento será feito através de meios não-eletrônicos como uma promessa para emitir ao comerciante umcheque ou outro instrumento negociável.
Da perspectiva do comerciante, a transação comer-cial é substancialmente isenta de risco uma vez que a iden-tidade do usuário final e a verificação de pagamento são ma-nipulados por terceiros e são portanto menos suscetíveis afraudes, imitação e até mesmo enganos inocentes fornecendoinformação pessoal e financeira. Portanto, comerciantes po-dem estar mais dispostos para conduzir transações comerciaisem-linha com usuários finais desconhecidos em uma rede não-confiada. Da perspectiva do usuário final, informação pesso-al e financeira reside com entidades ou que já mantêm a in-formação e/ou que o usuário final tem uma relação estabele-cida. Informação de usuário final pessoal e financeira con-fidencial não necessita ser fornecida ao comerciante, miti-gando as vulnerabilidades de ter informação confidencial a-busadas ou mal empregadas. Como resultado, os usuários fi-nais podem estar mais dispostos para conduzir transações co-merciais com comerciantes desconhecidos sem ter que preocu-par sobre se o comerciante é confiável ou não.Em alguns modelos de transação comercial conven-cionais, informação de identidade e informação de pagamentosão entradas pelo usuário e processadas por um terceiro oupelo comerciante. Como debatido acima, estes modelos são de-sajeitados , ineficientes e demorados para o usuário. Alémdisso, modelos convencionais apresentam numerosos problemascom relação à segurança da informação confidencial de um u-suário final como também tornando um comerciante vulnerávelà fraude e/ou suscetível à falha para pagar por um usuáriofinal. 0 requerente tem apreciado que software de transaçãocomercial instalado em cada um dos computadores empregadosem várias transações comerciais podem mitigar ou eliminarpreocupações em segurança e fraude. Além disso, muitas dasações manipuladas pelo usuário final e comerciante em mode-los convencionais podem ser executadas pelo software detransações comerciais, tornando a transação mais simples emais intuitiva para o usuário final.FIG. 8 ilustra um exemplo de usar algumas das ca-racterísticas descritas acima para uma comunicação segura detrês modos e vários limites de confiança que podem ser esta-belecidos durante uma transação comercial. Como será descri-to em maior detalhe abaixo, este modelo possibilita pagamen-tos simples ou de assinatura, como também federação de paga-mento de modo qual um serviço ou o comerciante pode agregarpagamento para companhias menores; desse modo permitindo ocliente pagar uma conta simples. Como mostrado, um sistemadistribuído 800 é configurado para facilitar uma transaçãocomercial entre um consumidor 810, comerciante 830 e umprovedor de pagamento 805. Um limite de confiança depagamento 815 divide o comerciante 830 do consumidor815 divide o comerciante 830 do consumidor 810/provedor depagamento 805 de modo que uma relação confiada existe entreo provedor de pagamento 805 e o consumidor 810 ou dispositi-vo de computação de cliente (isto é, o consumidor tem apro-priadamente identificado ou autenticado no provedor de paga-mento usando quaisquer dos mecanismos disponíveis como des-critos aqui). Conseqüentemente, o consumidor 810 pode utili-zar esta relação confiada para autorizar pagamento para ocomerciante 830 por vários tipos de pagamentos e vários ti-pos de serviços,Por exemplo, assuma que o comerciante 830 requerpagamento de reserva para um produto (por exemplo, um itemde costume que requer adiantamento como um carro, computadoretc.), que o consumidor 810 deseja comprar. Antes de reque-rer autorização de pagamento, porém, o usuário do dispositi-vo de computação de consumidor 810 pode requerer autentica-ção apropriada como descrita aqui. Uma vez o usuário auten-tica, o dispositivo de computação do consumidor 810 pode a-propriadamente solicitar o pagamento do provedor de pagamen-to 805 através de qualquer um de vários mecanismos como tam-bém descritos aqui. Por exemplo, o consumidor 810 pode for-necer ao provedor de pagamento fatura ou outra informação desolicitação que é assinada ou do contrário criptografada pe-lo sistema de computação 810 do consumidor. Este autentica asolicitação para validação da habilidade do retentor da con-ta (isto é, do consumidor) apropriadamente pagar (isto é, ousuário tem uma conta paga antecipadamente, conta de créditoou outra conta de faturamento como uma assinatura móvel comodescrita abaixo). Se com sucesso, um sinal de pagamento éemitido e os fundos são depois reservados para garantir opagamento. Tal sinal de pagamento é tipicamente depois docontrário assinado e/ou criptografado pelo provedor de paga-mento (por exemplo, um servidor de rede móvel como descritoaqui) e passado para o cliente de consumidor 810. O consumi-dor 810 passa o sinal de pagamento de volta para o comerci-ante 830 que verifica o sinal junto ao provedor de pagamentoe se com sucesso conclui a ordem.Uma vez o item está pronto para liberação (por e-xemplo, o item de costume foi construído), o comerciante 830podem usar o sinal de pagamento de reserva para requerer pa-gamento do provedor de pagamento 805. Note que a quantidadeda solicitação para pagamento pode ser diferente que a quan-tidade reservada. Não obstante, o provedor de pagamento 805verifica e retorna uma resposta de pagamento para o comerci-ante 830 e/ou consumidor 810. Se aprovado o comerciante 830pode despachar (ou do contrário fornecer) a ordem para ocliente 810 e ser fornecido com pagamento deste. Por outrolado, se o pagamento é rejeitado ou interação de usuáriotambém é requerida, o comerciante 830, provedor de pagamento805 e/ou consumidor 810 pode selecionar que curso de açãotomar. Por exemplo, se a quantidade requerida pelo comerci-ante 830 não equiparar os fundos reservados, o provedor depagamento 805 e/ou comerciante 830 pode(m) requerer autori-zação do consumidor 810 para a quantidade nova. Alternativa-mente, o provedor de pagamento 8 05 pode requerer entrada deusuário autorizando a transferência de fundos independentede qualquer alteração nas quantidades de pagamento reserva-das e requeridas. Claro que, outras ações e procedimento pa-ra concluir a transação comercial são também contempladasaqui.
Note que embora o mecanismo de pagamento seguro de
três modos tenha sido usado para comprar um item de reserva,o pagamento simples pode também aplicar-se a outros serviçose/ou mercadoria. Por exemplo, o mecanismo de pagamento sim-ples pode aplicar a um programa de software que está prontopara transferência imediata. Alternativamente, ou em conjun-ção, o pagamento simples pode destrancar vários níveis de umprograma que foi transferido (por exemplo, versão de estu-dante, versão profissional, ou outra funcionalidade separa-da) . De fato, como será apreciado o pagamento simples acimapode ser usado para uma variedade de tipos diferentes decompras, alguma em uma forma de pagamento ligeiramente modi-ficada .
Por exemplo, suponha que o consumidor 810 desejaestabelecer uma assinatura com um comerciante 830 para ser- viço ininterrupto (por exemplo, uma assinatura de jornal ourevista, assinatura de filme, aplicação de jogo, ou outramercadoria e/ou serviços pagáveis de acordo com o consumo).Conseqüentemente, o comerciante 830 desafiará o consumidor810 para um sinal de pagamento, e desse modo o cliente do consumidor 810 pode interagir com o usuário que requer auto-rização para prosseguir como descrito aqui- Similar ao acima,o consumidor 810 sinaliza ou do contrário criptografa a so-licitação para pagamento (por exemplo, usando informação defaturamento eletrônico como descrita aqui abaixo) e enviatal solicitação ao provedor de pagamento 805 (por exemplo,operador móvel, companhia de cartão de crédito, tipo pré-pago ou outro serviço de terceiro, etc.). Este autentica asolicitação e verifica o retentor de conta (isto é, o consu-midor ou cliente) tem fundos iniciais suficientes. Se comsucesso, um sinal de pagamento é emitido, assinado e/ou docontrário criptografado, e retornado para o cliente do con-sumidor 810 que passa o sinal de pagamento de volta para ocomerciante de assinatura 830. O comerciante 830 depois ve-rifica a autenticação do sinal e conclui a organização deassinatura.Note que tipicamente o sinal de pagamento é arma-zenado no comerciante 830 e periodicamente usado ao requererpagamento de assinatura do provedor de pagamento 805. Conse-qüentemente ao processar pagamento de assinatura, o comerci-ante 830 recupera o sinal de pagamento e o envia ao provedorde pagamento 805 para determinação de pagamento. O provedorde pagamento 805 verifica e devolve uma resposta de pagamen-to para o comerciante 830 e/ou consumidor 810. Se uma res-posta aprovada for devolvida, o comerciante de assinatura830 receberá pagamento durante a próxima operação do prove-dor de pagamento 805 de pagamento de conta. Se a solicitaçãode pagamento for rej eitada, porém, o provedor de pagamento805 e/ou comerciante 830 pode responder apropriadamente. Porexemplo, o comerciante 830 (ou provedor de pagamento 805)pode contatar (por exemplo, por meio de e-mail) o usuário ouconsumidor 810 que os informa do pagamento excelente. O con-sumidor 810 pode depois executar um pagamento simples comodescrito acima ou estabelecer outro pagamento de assinaturaatravés ou do mesmo provedor de pagamento 805 ou diferente.Claro que, o comerciante 830, provedor de pagamento 805 e/ouconsumidor 810 também têm outras regras ou requerimentos pa-ra processar estas e outras autorizações de pagamento, comoserá descrito em maior detalhe abaixo.Como previamente mencionado, outras modalidadespermitem federação de um pagamento de consumidor simples 810para uma pluralidade de sócios empresariais ou subsidiáriascom um arranjo contratual. Freqüentemente relações empresa-riais são complexas e requerem distribuição de pagamentospara vários serviços e/ou mercadoria fornecidos dentro de ummodelo empresarial particular. Por exemplo, ao comprar umaviagem de um agente de viagens 830, um consumidor 810 podeser provido de uma transação de pacote incluindo arranj os devôo, alojamentos de hotel, serviços de transporte, etc. 0comerciante 830, quem tipicamente contrata muitos de taisserviços e/ou mercadoria, deve depois manter contabilidadedetalhada de tal transação comercial para fazer pagamentosapropriados a seus sócios empresariais. Para aliviar a com-plexidade de tal contabilidade e outras tarefas, as modali-dades aqui provêem uma federação de pagamento automática pa-ra os sócios empresariais dentro de um tipo particular derelação em uma base por transação.
Por exemplo, um serviço de aluguel de carros (porexemplo, associado empresarial "A" 820) pode requerer paga-mento do comerciante 830 como parte de uma venda de pacotede feriado. Uma companhia de seguros (por exemplo, associadoempresarial "B" 825) pode tributar o comerciante 830 em umabase por taxa transacional. Com base no limite de confiança835 do associado empresarial, pagamentos são federados auto-maticamente para cada associado empresarial (por exemplo,"A" 820 e WB" 825) quando um pagamento simples for feito pa-ra o comerciante 830. Em outras palavras, o consumidor 810ou provedor de pagamento 805 faz um pagamento simples para ocomerciante 830; porém, todas as subsidiárias com uma rela-ção empresarial de acordo com o limite de confiança para omodelo empresarial 835 podem ser apropriadamente liquidadas.Note que tal pagamento tipicamente será amarrado à declara-ção de faturamento eletrônica como descrita em maior detalheabaixo. Mais especificamente, várias porções de uma contaeletrônica para captura, apresentação e outros propósitospodem corresponder a que a porção de pagamento deveria serfederada a cada sócio empresarial. Também, cada uma destasporções pode ser assinada e/ou criptografada de modo que ainformação particular acerca do pagamento seja opaca ao con-sumidor 810, provedor de pagamento 805, ou entre os váriossócios empresariais 820, 825 como definido pelos vários li-mites de confiança 815, 825.Note que embora o modelo de federação de pagamentoacima tenha sido descrito com relação a uma experiência deagente de viagens, outras relações empresariais também exis-tem que podem usar esta modalidade. Por exemplo, companhiasque constróem itens com componentes múltiplos comprados a-través de vários vendedores, provedores de produto que com-pram materiais para aquele produto e fazem pagamentos combase em uma base por item, pagamentos para produtos de mul-timídia que pagam direitos autorais com base em cada venda,ou qualquer outro tipo de modelo de negócio que embala ou docontrário calcula e faz pagamentos aos sócios empresariaisem uma base por item podem também usar as modalidades des-critas aqui. Como tal, o uso do agente de viagens acima paradescrever várias modalidades aqui é para propósitos ilustra-tivos apenas e não é significado limitar ou do contráriorestringir as modalidades descritas aqui.
FIG. 4 ilustra um sistema de computador em redepara manipular transações comerciais, de acordo com uma mo-dalidade da presente invenção- Sistema de computador 400 emrede pode ser similar ao sistema de computador 100 ilustradona FIG. 1. Porém, na FIG. 4, cada um dos computadores nosistema 4 00 inclui instalações locais de software de transa-ções comerciais 485. Em particular, o computador de usuáriofinal ou consumidor 410, provedor de identidade 420, prove-dor de pagamento 430 e comerciante 440 incluem software detransações comerciais 4 85a-485d, respectivamente. O softwarede transações comerciais instalado localmente em cada um doscomputadores no sistema pode ser o mesmo, ou pode ser perso-nalizado para o computador particular em função do(s) pa-pel (éis ) que o computador representa na transação (isto é,se o computador opera como um nó de usuário final, um nó co-merciante, nó de provedor de identidade, nó de provedor depagamento, etc, ou um pouco da combinação do acima). Em to-do caso, cada instalação é configurada para comunicar cominstalações em outros computadores em rede para executartransações em-linha. Por exemplo, cada instalação pode serconfigurada para comunicar com instalações em computadoresem rede para executar os métodos ilustrados na FIG. 2 e/ouFIG. 3.Em uma modalidade, a instalação local do softwarede transação comercial 485a em provedor de identidade 420pode criar um sinal de identidade que identifica o usuáriofinal utilizando computador de usuário final 410. Além disso,o software de transação comercial 485a no provedor de iden-tidade 420 pode remeter o sinal de identidade para o compu-tador de usuário final 410, o provedor de pagamento 4 30, ocomerciante 4 40, e/ou qualquer outro computador, uma vez quea invenção não é limitada neste respeito. A instalação localdo software de transação comercial 485b no computador de u-suário final 410 pode emitir informação de identidade (paraidentificar o usuário final) em resposta a uma indicação pa-ra conduzir uma transação em-linha entre o usuário final eum comerciante. A instalação local do software de transaçãocomercial 485c instalado no provedor de pagamento 430 podereceber o sinal de identidade e pode gerar um sinal de paga-mento que verifica uma habilidade do usuário final para pa-gar (por exemplo, o sinal de pagamento) para a transação em-linha. A instalação local do software de transação comercial485d instalada no comerciante 440 pode receber a verificaçãoda habilidade do usuário final para pagar antes de prosse-guir com a transação em-linha.
Em uma modalidade, cada um dos computadores nosistema 4 00 opera usando uma instalação local de um sistemaoperacional mesmo ou similar 4 95. Por exemplo, cada um doscomputadores no sistema 400 pode operar usando a sistema o-peracionai Microsoft Windows®. Software de transações comer-ciais 485 pode ser um subsistema do sistema operacional.Desse modo, os vários computadores empregados em uma transa-ção comercial comunicam-se em uma maneira consistente e co-nhecida . Uma vez que o software de transações comerciais es-tá comunicando diretamente na rede e manipulando a validação,verificação e segurança, o usuário final e o comerciante nãonecessitam saber nada um sobre o outro, e mais importante-mente, não necessitam estabelecer qualquer relação de confi-ança . Além disso, porque certas porções das transações sãomanipuladas pelo sistema operacional, grande parte da tran-sação pode ser executada substancialmente invisível ao usuá-rio, sem requerer envolvimento confuso e às vezes desajeita-do pelo usuário final.Várias técnicas de criptografia podem ser usadasdurante a transmissão de informação de um computador paraoutro tendo o software de transações comerciais em cada com-putador. Além disso, características de segurança podem serincluídas também como sinais de identidade e/ou sinais depagamento que são válidos durante um periodo de tempo limi-tado. Por exemplo, um sinal de identidade pode incluir umcomponente de tempo que especifica um tempo após o qualqualquer componente recebendo e processando o sinal deveriajulgar inválido, e não honra o sinal como verificação de i-dentidade e/ou pagamento. Os componentes de software detransações comerciais podem programaticamente processarquaisquer limites de tempo associados a um sinal. Isto podeimpedir os sinais obtidos "pescando" de ser inapropriadamen-te usados em uma data posterior, Deveria ser apreciado que o software de transação
comercial não necessita fazer parte do sistema operacional,mas pode ser qualquer programa ou grupo de programas locaispara computadores envolvidos em uma transação comercial quepode comunicar entre si na rede. Por exemplo, o software de transação comercial pode ser uma aplicação desenvolvida porum terceiro que pode ser instalado nos computadores para o-perar no ou independente do sistema operacional instalado nocomputador. A aplicação pode ser configurada para operar comqualquer um ou combinação de sistemas operacionais para es-
tar disponível para computadores ou dispositivos de uma gamaextensiva de capacidades e configurações, e não limitados aqualquer sistema operacional particular, processador, con-junto de instruções, etc.
FIG. 5 ilustra uma transação comercial iniciadapor um usuário final que seleciona um ou mais de mercadoriae/ou serviços desejados, em que os componentes transacionaisda compra são manipulados, pelo menos em parte, por um sub-sistema de software de transação distribuído como parte dosistema operacional dos vários computadores envolvidos em uma ou mais transações. Um usuário final conectado à rede505 através de computador de usuário final 510 pode estarexecutando uma aplicação 555. Aplicação 555 pode ser um na-vegador que exibe o sitio de rede de um negócio que oferecemercadoria ou serviços à venda. Aplicação 555 pode ser umaaplicação que fornece uma opção para contratar uma transaçãoem-linha, como um programa de edição de imagem que permiteos usuários manipular as imagens. 0 usuário final pode selecionar um ou mais merca-doria ou serviços para comprar por meio da aplicação 555.Por exemplo, o usuário final pode querer ter uma imagem pro-fissionalmente editada impressa em papel de qualidade de fo-tografia. Aplicação 555 pode incluir uma tal opção sob o me- nu de impressão. A opção de impressão, quando selecionada,pode gerar uma janela ou caixa de diálogo que lista todas asopções de impressão disponíveis, incluindo serviços disponí-veis na rede. Por exemplo, a opção de impressão pode listarprovedores de serviços 540a, 54 0b e 540c como opções para fornecer o serviço de impressão. Quando o usuário selecionaum dos provedores de serviços, uma transação comercial em-linha como descrita acima pode ser iniciada. Em particular,o provedor de serviços pode requerer que o usuário finalforneça um sinal de identidade. Em resposta, a aplicação 555 (ou uma aplicação embutida em software de transações comer-ciais 585), pode gerar uma caixa de diálogo ou interface quelista os provedores de identidade disponíveis. Por exemplo,como descrito em maior detalhe abaixo, a caixa de diálogopode listar o provedores de identidade 520a, 520b e 520c co- mo possíveis provedores de identidade que o usuário pode se-lecionar para manipular verificação de identificação.
FIG. 9 ilustra o uso de um subsistema comercialconfiado e outras características em um sistema e de acordocom modalidades exemplares. Como mostrado, um dispositivo decomputação local 920 dentro do sistema distribuído 900 éconfigurado para fornecer uma transação de varejo em-linhaou local de acordo com as modalidades descritas aqui. Noteque embora o subsistema de transação comercial confiado 965seja mostrado apenas como parte do dispositivo de computaçãolocal 920, os subsistemas similares também residem em outrasentidades de rede. Note também que embora possam ser descri-tos vários componentes ou módulos aqui como residindo emqualquer entidade de rede particular, tais componentes oumódulos podem ser distribuídos ao longo do sistema de compu-tação e resididos em qualquer número de entidades de rede(isto é, porções podem existir em uma ou mais entidades derede). Conseqüentemente, o leiaute estético especifico e usode um módulo particular para um dispositivo de rede ou enti-dade é aqui usado para propósitos ilustrativos apenas e nãoé significado limitar ou do contrário estreitar o escopo dasmodalidades aqui.Independente da distribuição e leiaute estético dosistema de computação 900, como previamente descrito lá e-xiste um limite de confiança 906 que separa a relação deconfiança entre os vários componentes. Embora a relação pos-sa ser dividida diferentemente, no exemplo presente a rela-ção confiada existe entre o provedor de pagamento 990 e osubsistema de transação comercial confiado 965. Isto vanta-josamente permite muitas características que os sistemas co-merciais atuais não podem fornecer. Por exemplo, o limite deconfiança 906 abstrai aplicações 92 5 da transação comercialcom o comerciante. Conseqüentemente, legado e outras aplica-ções 925 podem fornecer uma experiência de dentro-da-bandaao usuário final 940, embora muito da funcionalidade apareçafora-da-banda. Por exemplo, no exemplo acima de permitir umaimagem profissional imprimindo em papel de qualidade de fo-tografia, a seleção dentro do menu instantâneo, a validaçãode identidade, opções de pagamento e outros componentes paraaj udar o usuário em tal compra de serviço aparece como parteda aplicação 925. Conseqüentemente, a aplicação 925 quandoreceber entrada para comprar serviços e/ou mercadoria podefazer uma chamada de compra 930 no subsistema de transaçãocomercial confiado 965 que é depois usado para gerar caixasde diálogo, receber a entrada 935 do usuário 94 0, e do con-trário automaticamente comunicar com o comerciante 905 e/ouprovedor de pagamento 990 como descrito aqui.Em outras palavras, o usuário 94 0 não necessitanecessariamente confiar na aplicação 925 ou no comerciante905 na transação comercial. Em lugar, a confiança é limitadaao subsistema 965 da estrutura presente que reduz o grau ouniveis de confiança necessários confidentemente e com segu-rança para executar uma transação comercial. Ou seja, osdetalhes da conta 950 para o usuário 940 que incluiinformação sensível 955 que o usuário 950 está poucodisposto ou incômodo em compartilhar publicamente (porexemplo, informação de cartão de crédito, informação pessoal,nomes/senhas de usuário, etc.), são acessadas ou por meio dequalquer entrada de usuário direta 935 ao subsistema 965 oude armazenamento de informação de conta 960 segura 945. Comotal, aplicações 925, comerciante 905 e outros componentescações 92 5, comerciante 905 e outros componentes são abstra-ídos longe de detalhes de conta financeira e outros de fatu-ramento 955 controlados pelo subsistema 965 como descritoaqui. Isto é muito diferente dos modelos de transação comer-cial atuais descritos acima onde as aplicações 925 ou comer-ciantes 905 mantêm e controlam informação de conta. Conse-qüentemente, estas e outras modalidades descritas aqui van-tajosamente provêem camadas adicionais de segurança durantetais transações comerciais. Esta é uma relação de confiançamuito mais direcionada para minimizar o número de componen-tes ou organizações que têm acesso ou tocam os dados finan-ceiros muito sensíveis.Também mostrado na FIG. 9, e similar à transaçãocomercial segura de três modos descrita acima, o limite deconfiança 906 também indica uma comunicação segura entre oprovedor de pagamento e o subsistema de transação comercialconfiado 965. Conseqüentemente, o subsistema 965 autenticapara os provedor(es) de pagamento 990 em qualquer um de nu-merosos modos descritos aqui, permitindo comunicação seguraentre eles. Similar ao acima, o dispositivo de computaçãolocal (que pode ser um dispositivo portátil de mão como des-crito abaixo em uma transação de varejo local, um computadorpessoal em uma transação em-linha, ou outro dispositivo si-milar como descrito aqui) deseja vários serviços e/ou merca-doria oferecidos pelo(s) comerciante(s) 905. Neste exemplo,'informação de faturamento 910 é apresentada ao dispositivode computação local 920 para autenticação, auditoria e ou-tros propósitos como usados em modalidades exemplares des-critas aqui. Tal informação de faturamento pode incluir, masnão é limitada a, custo da mercadoria e/ou serviços, descri-ção detalhada da transação comercial, informação especificado comerciante 905, informação de pagamento de federação,tipo de transação (por exemplo, pagamento simples, assinatu-ra, etc), ou outros tipos de informação de faturamento. Ainformação de conta 910 pode também incluir outra informaçãocomo restrições mercantis e opções de pagamento como descri-tas em maior detalhe abaixo.Em uma modalidade, a informação de conta 910 é umaconta eletrônica configurada para ser legível por máquinaque prove muitas habilidades vantaj osas do sistema de tran-sação comercial atual. Por exemplo, uma modalidade forneceque a informação de faturamento 910 pode fazer parte da so-licitação de sinal de pagamento 980 (ou do contrário libera-da em outra comunicação ao provedor de pagamento 990) comopreviamente descrito. Como tal, a informação de conta podeser usada pelo provedor de pagamento 990 para validação desinal de pagamento 940. Mais especificamente, a informaçãode conta 910 fornecida do consumidor ou dispositivo de com-putação local 920 pode ser comparada com a informação de si-nal de pagamento 985 fornecida do comerciante 905 na valida-ção de sinal de pagamento 904. Conseqüentemente, se a infor-mação de conta 910 para a validação de pagamento de sinal904 equiparar à informação de conta 910 da solicitação desinal 980, o provedor de pagamento 990 pode ser também asse-gurado da autenticidade do sinal de pagamento 985 e a vali-de z do comerciante.Note que como a informação de conta 910 do comer-ciante é retransmitida para o provedor de pagamento 990 (co-mo também outros componentes aqui) pode variar. Por exemplo,a informação de conta 910 enviada do comerciante 905 para o5 provedor de pagamento 990 pode ser uma cópia da informaçãode conta 910 enviada ao subsistema de transação comercialconfiado 965 ou cliente 920. Alternativamente, ou em conjun-ção, a informação de conta 910 pode ser uma versão assinadae/ou criptografada do provedor de pagamento 990, roteada por meio do dispositivo de consumidor ou de computação local 920.Em qualquer caso, o provedor de pagamento pode previamentefazer a comparação descrita para autenticação do sinal depagamento 985.
Note também que tal informação de faturamento 910 como usada pelo provedor de pagamento 990 pode também serusada para dar uma descrição mais detalhada dos encargos as-sociados a uma conta que subseqüentemente serão apresentadosao usuário 94 0 por encargos na conta do usuário. Porque estapode também ser uma conta legível por máquina 910, o dispo- sitivo de computação local 920 pode comparar a informação deconta 910 com à previamente recebida pelo comerciante 905para autorização também de pagamento ao comerciante 905. Emoutras palavras, se a informação de conta 910 dentro da con-ta do provedor de pagamento 990 não equiparar com qualqueruma recebida do comerciante 905, então os encargos podem serconsideradas fraudulentos.
Em outra modalidade, o comerciante 905 pode usar ainformação de conta 910 para auditoria, autenticação do usu-ário e outros propósitos, federação de pagamento, etc. Porexemplo, o comerciante pode assinar ou do contrário cripto-grafar as porções da informação de conta 910. Isto permitecaracterísticas vantajosas múltiplas em modalidades descri-5 tas aqui. Por exemplo, a informação de conta 910 pode serparte do sinal de pagamento 98 5 recebido pelo provedor depagamento por meio do dispositivo de computação local 920. Ocomerciante 905 pode verificar a validez da informação defaturamento 910 para autenticar que o sinal de pagamento 985 veio do cliente 920 ou subsistema de transação comercialconfiado 965. Similarmente, durante a validação de sinal depagamento 904, o comerciante 905 pode usar informação de fa-turamento 910 recebida do provedor de pagamento 990 para va-lidar ou autenticar o provedor de pagamento 990 e/ou dispo- sitivo de computação local 920. Em outras palavras, porque ainformação de conta 910 é roteada para o provedor de paga-mento por meio do subsistema 965 ou consumidor 920, a infor-mação de faturamento recebida do provedor de pagamento queequipara à enviada ao cliente 920 pode autenticar o cliente 920 e sinal de pagamento 985 do provedor de pagamento 990.
Note que em outra modalidade, como brevemente des-crito acima, a informação de conta 910 pode também ser usadapelo comerciante para federação de pagamento. Nesta modali-dade, várias porções da informação de conta 910 podem serlegiveis por máquina para determinar quais porções de fundosdo provedor de pagamento 990 (em autenticação de pagamentocom sucesso) deveriam ser distribuídas aos sócios empresari-ais como previamente descrito. Note que nesta modalidade,tipicamente as porções da informação de conta 910 serãocriptografada ou do contrário opacas ao usuário 940 (ou cli-ente consumidor 920), provedor de pagamento 990, ou outroscomponentes não parte de uma relação empresarial com o co-merciante 905. Estas também exclusivamente identificam o as-sociado empresarial na federação de faturamento, e podem serusadas assim para propósitos de autenticação. Mais especifi-camente, as várias porções da informação de conta 910 espe-cificas para um sócio empresarial podem ser criptografadasusando uma chave especifica para tal associado empresarial,desse modo a informação de faturamento pode apenas ser vistapelo comerciante 905 e sócio empresarial específicos. Em ou-tras modalidades, porém, as porções da conta para distribui-ção de pagamento ou federação são apenas assinadas pelo co-merciante 905 para torná-las opacas a outros componentes nosistema 900.Claro que, como será reconhecido, outros usos dainformação de faturamento 910 podem ser usados para váriospropósitos. Por exemplo, a informação de faturamento 910 po-de também ser usada para propósitos de auditoria, reconcili-ação de distribuição de produto, ou qualquer outro negóciobem conhecido e outros propósitos. Conseqüentemente, o usoda informação de conta 910 acima para autorização, identifi-cação, federação de pagamento, ou qualquer outro propósito éusado para propósitos ilustrativos apenas e não é significa-do limitar ou do contrário restringir o escopo das modalida-des a menos que do contrário explicitamente reivindicado.
Note que o limite de confiança 906 e o subsistema965 também têm outras características vantajosas em outrasmodalidades descritas aqui. Por exemplo, como mostrado naFIG. 9, código de provedor de pagamento 970 dentro do sub-sistema 965 permite com segurança passar o código específicopara um ou mais provedores de pagamento 990. Tal código podeser usado para autorização adicional específica para o pro-vedor de pagamento, por exemplo, biométrico, identificaçãode freqüência de rádio (RFID), nome/senha de usuário, ouqualquer numerosas técnicas de autenticação adicionais. Emoutras palavras, devido à relação confiada que o provedor depagamento 990 tem com o subsistema 965, o provedor de paga-mento pode passar o código confiado para seu propósito em-presarial específico.O uso de tal código 970 também permite uma experi-ência de usuário de dentro-da-banda mais integrada que podeser controlada pelo provedor de pagamento 990 ou qualqueroutro componente tendo uma relação confiada com o subsistema970. Por exemplo, embora não mostrado, uma relação confiadapode existir entre alguns comerciantes 905 e o subsistema965 para permitir código confiado destes serem passados pelosubsistema 965. Como tal, o comerciante 905, provedor de pa-gamento 990, ou qualquer outro componente envolvido na tran-sação comercial, pode fornecer uma experiência de usuáriointegrada que aparece se passou de dentro da aplicação 925(legado ou do contrário); porém, muitos dos eventos ocorremfora-da-banda. Por exemplo, no acima exemplo de uma impres-são de qualidade de fotografia de uma imagem por um serviçoprofissional, as caixas de diálogo, opções de pagamento, ouqualquer outro número de características apresentadas ao u-suário ou funcionalidade de aplicação (por exemplo, em res-posta à entrada de usuário) especificamente podem ser con-troladas pelo código 970 fornecido pelas várias entidades derede confiadas (por exemplo, o provedor de pagamento 990, ocomerciante 905, etc.). Conseqüentemente, como será descritoem maior detalhe abaixo, este código pode também ser usadoao avaliar opções de pagamento e outras restrições do comer-ciante 905 e/ou provedor de pagamento 990.
Como mencionado acima, em uma modalidade, o prove-dor de serviços ou o comerciante selecionado transmite qual-quer requerimento ao provedor de identidade com a solicita-ção para verificação de identidade. Por exemplo, o provedorde serviços pode estar vendendo mercadoria ou serviços querequerem uma idade minima ou são restringidos a uma certalocalização geográfica. Conseqüentemente, a listagem de pro-vedores de identidade pode ser limitada àqueles que podemfornecer credenciais de identidade que satisfazem os reque-rimentos do provedor de serviços. Por exemplo, a lista deprovedores de identidade pode ser restringida àqueles quepodem fornecer verificação de idade ou informação de endere-ço de corrente, como RMV.
Igualmente, uma caixa de diálogo pode ser geradalistando opções para provedores de pagamento. Por exemplo, acaixa de diálogo pode listar provedores de pagamento 530a,530b e 530c, que podem incluir uma companhia de cartão decrédito, um banco oferecendo serviços de débito eletrônico,ou um terceiro privado oferecendo serviços financeiros, res-pectivamente. Como com a solicitação de identidade, o prove-dor de serviços selecionado pode incluir qualquer requeri-mento de pagamento associado à compra. Por exemplo, o prove-dor de serviços pode apenas aceitar um certo tipo de cartãode crédito. Os requerimentos de pagamento podem depois serrefletidos nos provedores de pagamento disponíveis listadosou permitidos na caixa de diálogo de seleção do provedor depagamento. Após um provedor de pagamento ser selecionado, acertificação de pagamento pode prosseguir e a transação podeser concluída.Note que outras modalidades também provêem compa-ração de restrições mercantis (por exemplo, opções de paga-mento disponíveis, restrições de idade, etc.) com regras deconsumidor para determinar várias ações que podem ser entra-das . FIG. 10 ilustra uma tal modalidade, em que um sistemadistribuído 1000 é configurado para gramaticalmente determi-nar as ações profissionais com base em tais coisas como res-trições mercantis 1010 e/ou regras de consumidor 1035. Porexemplo, comerciante 1020 pode definir dentro das restriçõesmercantis 1010 provedores de pagamento 1005 ou tipos de pa-gamento aceitável para comprar serviços e/ou mercadoria des-tes. Módulo de decisão pode depois apresentar tais restri-ções ao usuário, por exemplo, em uma interface do usuárioque requer a entrada do usuário 1040 para selecionar uma oumais das opções de pagamento disponíveis. Com base na entra-da do usuário 1040, o provedor de pagamento apropriado 1005pode ser contatado para consolidação de divida flutuante a-propriada dos serviços e/ou mercadoria.Em outra modalidade, as regras de consumidor 1035podem também ser usadas além, ou no lugar, das restriçõesmercantis 1010. Por exemplo, as regras de consumidor 1035podem indicar que apenas certos tipos de pagamentos podemser feitos para certos tipos de comerciantes 1020. Mais es-pecificamente, as regras de consumidor 1035 podem indicarque se um comerciante 1020 não for registrado ou do contrá-rio confiado, que apenas pagamentos que podem ser invertidospossam ser usados para feito comprado do comerciante 1020.Claro que, como descrito acima, outras regras decomerciante 1010 e restrições de consumidor 1035 podem serusadas através do módulo de decisão 1030 ao determinar açõesa tomar em uma transação comercial. De fato, as restriçõesmercantis 1010 e as regras de consumidor 1035 podem ser com-paradas para compatibilidade e outros propósitos. Por exem-plo, as opções de pagamento disponíveis do comerciante 1020podem ser comparadas para provedores de pagamento 1005 dis-poníveis ou permissiveis pelo consumidor ao apresentar o u-suário com uma seleção de provedores de pagamento 1005. Cla-ro que, a seleção de pagamento pode também ocorrer automati-camente com base em tais coisas como um ajuste predefinido,avaliações de provedor ou preferências, ou qualquer outronúmero de ajustes de opção. Se fato, qualquer número de a-ções pode ocorrer com base na implementação das várias re-gras de comerciante 1010 e/ou de consumidor 1035. Por exem-plo, se as regras (comerciante 1010 ou consumidor 1035) fa-lharem ou do contrário forem violadas, entrada adicional docomerciante 1020 ou usuário 1040 (qualquer um automaticamen-te com base nas regras ou ajustes adicionais) pode ser ne-cessária para solucionar conflitos ou outras discrepâncias.Conseqüentemente, qualquer ação particular tomada quando im-plementar as restrições e/ou regras definidas é aqui usadapara propósitos ilustrativos apenas e não é significado li-mitar ou do contrário restringir as modalidades fornecidasaqui.
Note também que, como descrito acima, as restri-ções mercantis 1010 podem ser incluídas dentro da informação de faturamento ou podem ser fornecidas separadamente ao con-sumidor . Também note que a comparação de várias regras e a-ções tomadas assim podem todas ocorrer às escondidas, isto é,sem o conhecimento do usuário e/ou outros componentes dosistema. Além disso, note que o sistema presente não é limi- tado só às restrições ou regras definidas pelo consumidor oupelo comerciante. Por exemplo, o provedor de pagamento podetambém definir várias restrições que podem também ser consi-deradas em conj unção ou no lugar das regras de consumidore/ou de comerciante. Conseqüentemente, o uso acima das res- trições de comerciante e de consumidor para determinar vá-rias ações (como opções de provedor de pagamento) é aqui u-sado para propósitos ilustrativos apenas e não é significadolimitar ou do contrário restringir as modalidades aqui des-critas a menos que do contrário explicitamente reivindicado.Em transações em-linha convencionais, pode ser di-
fícil tanto para o usuário final e/ou o provedor de serviçossaberem certo quando uma transação está concluída e se amercadoria ou serviços foram de forma bem sucedida liberados.Por exemplo, um usuário final pode selecionar um pacote desoftware para transferência na rede, ou um usuário final po-de comprar canções, filmes ou outros meios eletrônicos. Àsvezes uma conexão de rede pode ser rompida antes de a trans-ferência poder ser concluída. Sob tais circunstâncias, o u-suário final pode ser tentado selecionar a mercadoria nova-mente, mas pode ser hesitante porque o usuário final não sa-be se ele ou ela será duplamente tributado (a) pela compra.Igualmente, o provedor de serviços pode não saber se umatransferência foi concluída de forma bem sucedida e pode do-brar o encargo quando um usuário tentar remediar o rompimen-to selecionando a mercadoria novamente.
0 requerente tem apreciado que fornecendo capaci-dades de acesso por registro ou auditoria no software detransações comerciais pode eliminar algumas das incertezascom respeito às transferências eletrônicas. Por exemplo, e-xecução final da opção de pagamento pode depender de um si-nal da característica de auditoria que a transferência estácompleta. Desse modo, se uma transferência for interrompida,o usuário final pode ter certeza que a opção de pagamentoselecionada não foi até o fim. Por exemplo, software detransações comerciais 585 da FIG. 5 (ou outros subsistemasou componentes de entidade de rede como descritos aqui) po-dem incluir uma característica de acesso por registro quegrava todas as várias etapas das transações comerciais con-duzidas pela máquina. A informação de registro pode ser usa-da como prova de compra ou do contrário para memorizar astransições. Além disso, software de transações comerciais585 pode incluir monitorar as capacidades para transferên-cias eletrônicas que enviam uma verificação de uma transfe-rência com sucesso, apenas após o qual o pagamento final se-rá feito. Fazendo pagamento dependente de um sinal que atransferência de mercadoria ou serviços foi concluida deforma bem sucedida, problemas de faturamento duplo podem serfocalizados e substancialmente eliminados.
Software foi desenvolvido através de companhiaspara manipular uma ampla variedade de tarefas incluindo pro-cessamento de palavras e de documentos familiares, planilhaseletrônicas, edição de imagem, para tarefas mais especiali-zadas como edição de video, software de computação gráfica,aplicações de desenvolvimento de conteúdo de rede, softwarede administração de carteira de valores, etc. Porém, para umpróprio software que manipula cada tarefa que um usuário fi-nal pode querer executar pode ser proibitivamente caro. Pa-cotes de software podem custar em qualquer lugar de centenasa milhares a dezenas e até mesmo centenas de milhares de dó-lares para obter uma licença simples. Além disso, um usuáriofinal pode precisar dos serviços de uma aplicação particularapenas ocasional ou esporadicamente, de modo que o custo decomprar a aplicação pode não ser justificado.
Requerente tem apreciado os benefícios de permitirum usuário final utilizar software em um ambiente de pagarde acordo com o consumo. Em particular, um usuário final po-de "ser tributado apenas para a quantidade de tempo gastausando a aplicação, ao invés de pagar o preço de varejo pelosoftware (onde muitas das características e/ou a aplicaçãoiriam grandemente desusados) . FIG. 6 ilustra um sistema decomputador em rede que tem uma estrutura de transação comer-cial que permite um usuário final pagar pela quantidade detempo gasto usando a aplicação. Sistema de computador 600 emrede inclui uma rede 605 interconectando nó de usuário final610 a uma pluralidade de provedores de identidade 620, umapluralidade de provedores de pagamento 630 e pluralidade deprovedores de serviços 640.Nó de usuário final 610 pode ser um computador o-perando em um sistema operacional 695. Instalado no computa-dor de usuário final pode estar uma pluralidade de aplica-ções de software 655. As aplicações de software podem tervir juntas com o computador na compra, podem ter sido trans-feridas livremente em uma rede, ou do contrário distribuídas(freqüentemente de graça ou por um encargo nominal, ou pararegistrar com o vendedor) pelo vendedor da aplicação. Apli-cação 655 pode ser qualquer tipo de aplicação e qualquer nú-mero de aplicações pode ser instalado no computador. Prove-dores de serviços 640 podem ser associados a uma ou mais a-plicações instaladas no computador de usuário final 610. Porexemplo, o provedor de serviços 64 0a pode ser um ou maiscomputadores possuídos pelo fomentador e vendedor de aplica-ção 655a. Similarmente, os provedores de serviços 640b e640c podem ser aplicações associadas a 655b e 655c, respec-tivamente .
No modelo de pagamento de acordo com o consumo, oserviço fornecido pelos provedores de serviços é uma licençapara usar as aplicações associadas instaladas no computador.Por exemplo, quando software (por exemplo, aplicações 655) édistribuído livremente, pode ser incapacitado inicialmentede forma que os usuários não podem executar a aplicação semobter uma licença primeiro do vendedor da aplicação. A li-cença pode ser obtida iniciando uma transação comercial comum ou mais dos provedores de serviços 640. Por exemplo, a-plicação 655a pode ser uma aplicação de editoração eletrôni-ca que um usuário final gostaria de usar para duas horas pa-ra projetar um cartão ou panfleto. Quando o usuário finalabrir a aplicação 655a, o usuário final é notificado que ousuário final necessita comprar uma licença para usar a a-plicação. Por exemplo, uma caixa de diálogo pode se parecerlistando as características e preços das várias capacidadesde licenciamento para uso.Uma licença pode ser para uma quantidade especifi-cada de tempo, por exemplo, uma hora ou um dia. A licençapode expirar uma vez a aplicação foi fechada, ou a licençapoderia permanecer ativa até que o termo expirasse. A licen-ça poderia ser com base em operações ou tarefas que permitemum usuário final completar um ou mais trabalhos ou empregaruma ou mais características desejadas. Características adi-cionais a serem usadas podem aumentar o custo da licença.Deveria ser apreciado que uma licença que tem quaisquer ter-mos desejados pode ser negociada, como os aspectos da inven-ção não são limitados neste respeito.
Uma vez o usuário final selecionou uma opção delicença, o usuário final pode ser ensinado selecionar umprovedor de identidade e/ou provedor de pagamento, ou um ouo outro pode ser selecionado em predefinição para iniciaruma transação em-linha. A transação pode ser manipuladasubstancialmente através de software de transação comercial685 como descrito em qualquer uma das modalidades anteceden-tes ou a seguir. Quando o provedor de serviços recebe um si-nal de pagamento de um dos provedores de pagamento 620, oprovedor de serviços pode transmitir uma licença de acordocom os termos concordados na iniciação da transação.A licença recebida pode ser processada através deserviço de licença genérico 690 de forma que a acessibilida-de apropriada para a aplicação pode ser invocada. O serviçode licença genérico pode depois enviar uma chave de permis-são para a aplicação 655 de forma que o usuário pode operaro software e utilizar sua funcionalidade de acordo com a li-cença. A chave de permissão pode incluir qualquer informaçãoque a aplicação pode necessitar prover os serviços necessá-rios para o termo indicado na licença. A chave de permissãopode incluir uma senha fornecida pelo provedor de serviçosde modo que a aplicação sabe que a licença é válida e/ou quepode simplesmente confiar na representação de serviço de li-cença genérica 690 que uma licença válida foi obtida. Umavez a aplicação está operando, motor de medição 694 pode sernotificado para manter a trilha de tempo e indicar à aplica-ção quando a licença expirou. Alternativamente, a aplicaçãopode ser programada para consultar o motor de medição perio-dicamente e depois incapacitar quando a licença expirou. A-lém disso, consultando o motor de medição, a aplicação podedar advertências ou atualizações periódicas ao usuário acer-ca da quantidade de tempo que permanece na licença comprada,se a licença deveria incluir um termo.
Quando o usuário final estiver acabado ele podeselecionar ter o produto concluído profissionalmente impres-so e pode selecionar uma opção de impressão que inicia outratransação em-linha como a transação descrita com relação àFIG. 5. A licença de pagamento de acordo com o consumo podeprover aos usuários muito mais flexibilidade e lhes dá aces-so ao software que eles não teriam tido acesso anterior de-vido ao custo de comprar o pacote de software com licençavitalícia. Além disso, os vendedores de software podem capi-talizar em renda de usuário que estava pouco disposto em pa-gar o preço de varejo total, mas pagarão uso limitado e/oufuncionalidade limitada.
Pirataria de software causa impacto nos lucros . aolongo da indústria de software inteira. Usuários de softwaresem licença custam às empresas quantidades relativamentesubstanciais a cada ano. Uma vez um produto de software foicomprado, o vendedor tem pouco controle de onde e em quantoscomputadores o software é instalado. Ilegalmente fornecersoftware para transferência na Internet fornece um métodoaté mesmo mais penetrante para distribuir e obter softwarepelo qual o usuário final não pagou. 0 requerente tem apre-ciado que provendo uma estrutura de transações comerciaisrelativamente segura e simples com um pagamento quando vocêentra no esquema de licença, por exemplo, a estrutura des-crita na modalidade ilustrada na FIG. 6, pode mitigar ou e-liminar os problemas de pirataria. Considerando que o soft-ware é distribuído livremente pelo vendedor, os usuários fi-nais podem distribuir o software de qualquer maneira elesvêem adequada. Uma vez que o software é permitido apenas a-través de pagamento por um termo de licença ou licença detarefa, os usuários finais estão substancialmente limitadosem sua habilidade de fazer mal uso do software.Como previamente descrito, modalidades aqui permi-tem autenticação para propósitos de identidade e/ou de paga-mento usando um módulo móvel (por exemplo, um módulo de i-dentidade de assinante (SIM)) amarrado em uma conta de fatu-ramento particular de uma infra-estrutura móvel ou sistemaoperacional. Padrões típicos distintos para comunicações mó-veis (por exemplo, Sistemas Globais para Comunicações Móveis(GSM), Projeto de Parceria de 3a Geração, e outros protoco-los similares) que ocorrem por meio de uma autenticação derede de rádio confiada de acordo com as modalidades aqui a-contecem em uma rede de dados não-confiada independente (porexemplo, a Internet). Como resultado, as modalidades aquitratam de muitas das preocupações de segurança adicionaisimpostas pelo uso de tais módulos móveis (SIMs) em um Servi-ço de Rede e outros ambientes de protocolo de rede indepen-dentes. Tais preocupações de segurança incluem entre outrascoisas: determinar um ponto terminal de rede confiado para aautenticação de um servidor; autenticação de um cliente paraum módulo móvel ou dispositivo de SIM; autenticação de umusuário para o dispositivo de SIM; autenticação do SIM eservidor de autenticação; estabelecimento de uma conexão derede segura entre o módulo móvel e o servidor de autentica-ção de rede; e autenticação do usuário para o servidor deautenticação de rede.
Além disso, para estar de acordo com o GSM, 3GPP eoutros padrões, requerimentos adicionais são colocados no equipamento terminal que interagirá com o módulo móvel oudispositivo de SIM. Mais especificamente, o GSM, 3GPP e ou-tros padrões similares requerem o acesso restrito de SIM acertos tipos de informação, incluindo chaves de criptografia,para o terminal móvel. Para satisfazer estes requerimentos, as modalidades aqui fornecem um perfil de segurança de abs-tração que delega processamento e decodificação de certasmensagens e segurança para o próprio dispositivo de SIM. Porexemplo, como mostrado na FIG. 11, uma barreira de proteção1090 define uma máquina de estado e mensagens de protocolopara abstrair um SIM 1085 de um dispositivo hospedeiro 107 5ao comunicar em uma rede independente 1060. Mais especifica-mente, a barreira de proteção 1090 usa uma máquina de estadoformal que limita ou restringe o número e/ou seqüência decomandos enviados de uma unidade de leitura dentro do hospe-deiro 1075 para o próprio SEM 1085. Conseqüentemente, o dis-positivo de SIM 1080 (por exemplo, um telefone celular, in-terface de SIM, etc. - observe que o "módulo móvel" repre-senta um termo genérico para um "SIM", mas é aqui usado al-ternadamente a menos que do contrário especificamente rei-
25 vindicado) se torna o terminal móvel e o dispositivo hospe-deiro 1075 se torna um periférico que obedece ao protocolode comunicação 1055 para a rede móvel 1050, O seguinte des-creve em maior detalhe algumas das máquinas de estado e pro-tocolos enviados para alguns dos requerimentos de segurançaadicionais e preocupações destacadas acima.
Modalidades aqui definem um perfil de segurançapara autenticação na rede independente não-confiada (isto é,uma rede independente de uma rede de rádio que corresponde àinfra-estrutura do módulo móvel ou sistema de operador) emtermos de vários niveis de segurança que um sinal de segu-rança dado pode representar. Estes incluem, mas não são li-mitados a, nivel de segurança de dispositivo, nivel de segu-rança de rede, nivel de segurança de usuário e nivel de se-gurança de serviço. Em cada nivel diferentes requerimentos eprocedimentos são para obter um sinal de segurança. Conse-qüentemente, como descrito em maior detalhe abaixo, cada ni-vel de segurança representa um nivel divergente de autenti-cação no modelo de segurança e cada um tem certos requeri-mentos e/ou garantias. Também, deveria ser observado que ca-da nivel de segurança pode ou não ser independente dos ou-tros. Por exemplo, pode não ser necessário estabelecer umnivel de segurança de dispositivo antes de uma rede ou nivelde segurança de usuário poder ser alcançado; porém, para ga-rantias apropriadas tal procedimento hierárquico pode serdesej ável.
Um nivel de segurança de dispositivo indica possefisica de um módulo móvel, por exemplo, um dispositivo deSIM como um telefone celular. Um sinal de dispositivo (istoé, um sinal de segurança de SIM com um nivel de segurança dedispositivo) é tipicamente emitido localmente pelo módulomóvel ou dispositivo de SIM sob autenticação apropriada porum usuário. Tais requerimentos para autenticar um usuáriopara o módulo móvel normalmente são fixos pela infra-estrutura móvel ou operador móvel. Também, autenticação dedispositivo é usualmente cumprida pelo dispositivo de SIM,porém, outras modalidades podem prover o uso de outros com-ponentes nos processos de autenticação. Por exemplo, o SIMou outro dispositivo pode requerer uma senha antes do módulomóvel ou outro dispositivo emitir um sinal de dispositivo.Claro que, outras formas de credenciais para autenticação nonivel de dispositivo são também contempladas aqui.
Em uma modalidade, um dispositivo de SIM requerque o computador cliente ou hospedeiro autentique ou identi-fique-se no módulo móvel antes de um sinal de segurança dedispositivo ser emitido. Também, a vida de um sinal de dis-positivo é tipicamente controlada pelo módulo móvel ou dis-positivo de SIM usando conjunto de política pela infra-estrutura móvel. Em uma modalidade, os requerimentos vitalí-cios ou outros aj ustados pelo operador móvel podem ser con-figurados dinamicamente através da rede independente e/ou derádio. Se o sinal do dispositivo não tiver vida ou outrasrestrições, tipicamente o SIM não requer do usuário re-autenticar-se mais de uma vez no módulo móvel.
0 nivel de segurança de rede indica uma conexãoautenticada entre o módulo móvel ou SIM e a infra-estruturamóvel ou rede na rede independente não-confiada. 0 nivel desegurança de rede pode ser estabelecido sem presença de usu-ário ou interação de usuário assumindo um dispositivo de SIMdestravado ser acessível pelo computador cliente ou hospe-deiro. Tipicamente, o nivel de segurança de rede é uma au-tenticação de fator simples que afirma prova de posse dodispositivo de SIM à infra-estrutura ou operador móvel. Ti-picamente, a infra-estrutura móvel emitirá um sinal de segu-rança de rede por meio de um servidor de autenticação e a-través de um mecanismo de tipo de resposta de desafio antesde emitir um sinal de segurança de rede a um dispositivo decomputação cliente ou hospedeiro. Este sinal de nivel de se-gurança de rede pode depois ser usado em fases de autentica-ção subseqüentes e fornecer segurança de nivel de transportepara criptografar e/ou sinalizar mais interações entre umcliente e um servidor de autenticação e/ou infra-estruturamóvel.
FIG. 7A ilustra uma rede independente 7 00 configu-rada para emitir um sinal de segurança de nivel de rede paraestabelecer uma comunicação segura de nivel de transporteentre o cliente e um servidor de autenticação. Tipicamente,o dispositivo de computação cliente ou hospedeiro 710 (quepode ser um computador pessoal, telefone móvel, ou outrodispositivo de computação portátil ou não-móvel) inicia asolicitação de autenticação enviando uma solicitação de si-nal de segurança de rede 725 para a infra-estrutura móvel720 por meio do servidor de autenticação/confiado 715 (ob-serve, porém, que a solicitação pode também ser iniciada poroutro dispositivo como o próprio SIM 705). Usualmente, a so-licitação 725 será não assinada quando recebida pelo servi-dor de autenticação 715 que pode depois sinalizar e/ou crip-tograf ar a solicitação antes de enviar à infra-estrutura mó-vel 7 20 para validar que a solicitação vem do servidor deautenticação 715. O servidor confiado 715 pode depois con-sultar a infra-estrutura móvel 720 ou o operador móvel paraum desafio 730 que vai depois ser enviado ao módulo móvel705. O módulo móvel 705 usa um segredo compartilhado 740 en-tre ele e a infra-estrutura móvel 720 para gerar uma respos-ta de desafio 735 que é depois enviada ao cliente 710 — ob-serve que tipicamente o segredo será SIM 705 especifico eajustado pelo operador móvel 720.
O cliente 710 usará a resposta de desafio 735 paragerar uma resposta de sinal de segurança de solicitação quepode também incluir a identidade de SIM e o desafio 7 30 parapropósitos de autenticação. Tipicamente, o cliente requereráque o módulo móvel 7 05 sinalize e/ou criptografe a respostade sinal de segurança de solicitação com o segredocompartilhado 740 do dispositivo 705 ou outra chave como osinal de dispositivo do SIM — embora esta pode ou não sernecessária. A resposta de sinal de segurança de solicitaçãoe a resposta de desafio 735 podem ser validadas nelas usando,por exemplo, o segredo compartilhado 740. Observe, comopreviamente mencionado, que a resposta de sinal de segurançade solicitação pode ou não ser assinada e/òu criptografadapela mesma chave usada para gerar a resposta de desafio 735.Em todo caso, se a infra-estrutura móvel 720 valida aresposta de desafio 735 (isto é, a resposta de desafio éválida e o módulo móvel tem uma conta de faturamento ativa) ,a infra-estrutura móvel 720 e/ou servidor de autenticação715 pode(m) responder gerando uma mensagem que contém umsinal de segurança de rede 74 5 com chave (s) de sessãocom chave(s) de sessão criptografada(s), que são assinadase/ou criptografadas usando o segredo compartilhado 740. Amensagem pode também ser assinada usando ou o próprio sinalde segurança de 715 do servidor de autenticação (por exemplo,X.509 cert, Kerberos cert, etc.) ou usando o sinal de segu-rança de 720 da infra-estrutura. O cliente 710 pode depoisverificar a mensagem assinada e passar a(s) chave(s) de ses-são de rede criptografada(s) para o SIM 705 para descripto-grafia. Usando o segredo compartilhado 740, o módulo móvel705 pode depois retornar a(s) chave(s) de sessão não-criptografada (s) 7 50 para o cliente 710.Note que na emissão acima do sinal de segurança derede 74 5, o módulo móvel 7 05 tipicamente necessita de umaconta de faturamento ativa bem estável na infra-estruturamóvel 720. Conseqüentemente, na verificação da resposta dedesafio 7 35 e tal informação de conta de faturamento ativa,uma confiança pode ser estabelecida entre o SIM 705 e a in-fra-estrutura móvel 720 que criam um canal seguro virtual.A(s) chave(s) de sessão 750 é/são depois delegada(s) ou pas-sada (s) do módulo móvel 705 para a plataforma de software oupilha do dispositivo de computação hospedeiro 710 e do ope-rador móvel 720 para o servidor de autenticação 715 (se ne-cessário) . Note a proximidade fisica do módulo móvel 705 como dispositivo de computação hospedeiro 710 (que pode ser co-nectado a este por meio de porta USB, Bluetooth, ou outraconexão sem fios ou com fios) e a relação confiada entre ainfra-estrutura móvel 720 e o servidor de autenticação 715.Esta(s) chave(s) de sessão 750 é/são depois usada(s) pelocliente 710 e confiada(s) no servidor 715 para estabeleceruma comunicação segura 755.
Note que pode haver um segundo modo de operaçãopara autenticar o módulo móvel 7 05 que pode ser usado pelainfra-estrutura móvel 720. Neste caso, o hospedeiro cliente710 pode requerer que o SIM 705 gere e assine seu própriodesafio (tipicamente na forma de um Nonce). O cliente 710pode depois anexar a informação como parte do sinal de dis-positivo quando requer sinal de segurança de rede 725 doservidor confiado 715 ou infra-estrutura móvel 720. Se o o-perador móvel 720 puder verificar que o sinal de dispositivocontém uma resposta de desafio válida 735, ele pode emitirdiretamente um sinal de rede 745 de volta para o cliente 710para descriptografia da(s) chave(s)c de sessão como descritoacima.
Como será descrito em maior detalhe abaixo, tipi-camente este sinal de segurança de nivel de rede 745 é re-querido para permitir um acesso de cliente a um sinal deserviço autenticado que pode ser usado para requerer servi-ços e/ou mercadoria de serviços de terceiros. Note tambémque para obter o sinal de rede, o acima presume que o dispo-sitivo de computação cliente ou hospedeiro 710 tem de formabem sucedida determinado o ponto terminal de rede para oservidor de autenticação 715 e/ou infra-estrutura móvel 720.Adicionalmente, presume-se que o cliente 710 e o usuário(não mostrado) já foram autenticados no dispositivo de SIM7 05. Como descrito acima, o nivel de sinal de segurança derede 74 5 é usado em fases de autenticação subseqüentes efornece segurança de nível de transporte para criptografar eassinar interações também entre o cliente 710 e o servidorconfiado 715. A vida dos sinais de rede 745 (e outros sinais)é controlada pelo servidor de autenticação 715 ou operadormóvel 720. Porque o sinal de rede 74 5 serve como um contextode sessão entre o dispositivo de SIM 7 05 e a infra-estruturamóvel 720, a vida pode ser limitada a horas ou dias, númerode bytes passados, e/ou pode apenas ser válido se o módulomóvel 705 for conectado corretamente ao cliente 710.
Como previamente mencionado, um nível de segurançade usuário indica um usuário autenticou-se na rede (o servi-dor confiado 715, infra-estrutura móvel 72 0, ou outro servi-ço) usualmente fornecendo informação armazenada fora do SIM7 05 ou dispositivo de computação hospedeiro 710. Conseqüen-temente, o nível de segurança de usuário j unto com o nívelde segurança de rede estabelece uma autenticação multifato-rial com base na prova de posse do SIM 7 05 e algum conheci-mento externo (por exemplo, um nome/senha de usuário). Tipi-camente, o servidor confiado 715 ou a infra-estrutura móvel720 são os únicos componentes a emitir uma segurança de ní-vel de usuário, porém, em algumas circunstâncias um serviçode terceiro pode também emitir tais sinais de usuário.Conseqüentemente, a infra-estrutura móvel 720 (ou outroserviço que pode ser o caso) verificará um usuário atravésde um mecanismo de resposta de desafio antes de emitir umsinal de nível de segurança de usuário de volto para ocliente 710. Note que o sinal de segurança de usuário éusado para a cliente assinar e/ou criptografar solicitaçõespor sinais de serviço como descrito abaixo. Pode não serserviço como descrito abaixo. Pode não ser recomendado que ocliente envie um sinal de segurança de usuário a qualquerserviço diferente do servidor confiado (uma vez que tipica-mente nenhum outro serviço será capaz de verificar/usar omesmo). Como com o sinal de rede 7 45 acima, o sinal de usuá-rio pode ter uma vida limitada controlada pelo operador mó-vel 720, e pode ser limitado por duração de tempo, o númerode bytes passados, e/ou pela existência da conexão entre omódulo móvel 705 e o cliente 710.FIG. 7B ilustram uma rede 7 00 independente confi-gurada para emitir um sinal de segurança de nivel de usuáriopara estabelecer uma comunicação segura de muiti-nivel entreo cliente 710 e um servidor de autenticação 715. A fase deautenticação de rede de usuário permite o operador móvel 720(ou outro servidor) verificar que uma pessoa conhecida estáem posse de um dispositivo conhecido 705. Eficazmente a fasede usuário para rede é uma fase de autenticação de dois fa-tores e impede a rede de negação distribuída de ataques deserviço. Além disso, protege o usuário impedindo um disposi-tivo roubado de SIM 705 de ser inapropriadamente usado.
O dispositivo de computação hospedeiro 710 podeemitir uma solicitação para sinal de usuário 765 que é envi-ado à infra-estrutura móvel 720 por meio do servidor confia-do 715. Usualmente, a solicitação 765 será não assinadaquando recebida pelo servidor de autenticação/confiado 715que pode depois sinalizar e/ou criptografar a solicitaçãoantes de enviar à infra-estrutura móvel 720 para validar quea solicitação vem do servidor de autenticação 715. O servi-dor confiado 715 pode depois consultar a infra-estrutura mó-vel 720 ou o operador móvel para um desafio 770 que vai de-pois ser enviado ao módulo móvel 705. Note que o desafio 770pode ser gerado usando um algoritmo diferente que o desafio7 30 usado para autenticar o dispositivo 705 para a rede. Ocliente 710 extrairá o desafio 770 da mensagem de sinal e opassa ao módulo móvel 705, indicando que esta é uma autenti-cação de usuário. Conseqüentemente, o SIM 7 05 requererá cre-dencial (is) de usuário 775 do cliente 710. O computador hos-pedeiro 710 depois consultará o usuário 7 60 para entrada dousuário 780, e o retorna ao módulo móvel 705. O SIM 705 oucliente 710 pode opcionalmente decidir que a entrada do usu-ário 780 ou credencial(is) deveria(m) ser criptografada(s)com a chave de segurança de rede (isto é, a (s) chave (s) desessão) 750 previamente obtida.
Usando a entrada do usuário 780, o módulo móvel705 gerará uma resposta de desafio 785 e a retornará ao cli-ente 710 que gerará e enviará para uma resposta de sinal desegurança de solicitação que inclui, por exemplo, um identi-ficador de SIM, o desafio 770 e a resposta de desafio 785.Tipicamente, o cliente 710 requererá que o módulo móvel 705sinalize e/ou criptografe a resposta de sinal de segurançade solicitação com o sinal de segurança de rede 745, a chavesecreta compartilhada 740 ou uma chave especifica de SIM 705.Similar ao acima, a resposta de sinal de segurança de soli-citação e a resposta de desafio 78 5 podem ser validadas u-sando, por exemplo, o segredo compartilhado 740, ou outrachave especifica do módulo móvel 7 05. Observe, como previa-mente mencionado, que a resposta de sinal de segurança desolicitação pode ou não ser assinada e/ou criptografada pelamesma chave usada para gerar a resposta de desafio 785. Emtodo caso, se a infra-estrutura móvel 720 valida a respostade desafio 785 (isto é, as credenciais de usuário fornecidassão apropriadas), a infra-estrutura móvel 720 e/ou servidorde autenticação 715 pode(m) responder gerando uma mensagemcontendo um sinal de segurança de usuário 7 95 com chave(s)de usuário criptografada(s) que é/são assinada(s) e/ou crip-tografada (s) usando o segredo compartilhado 740 ou outrachave especifica de dispositivo 7 05. A mensagem pode tambémser assinada usando ou o próprio sinal de segurança de 715do servidor de autenticação (por exemplo, X. 509 cert, Kerbe-ros cert, etc.) ou usando o sinal de segurança de 720 da in-fra-estrutura móvel. O cliente 710 pode depois verificar amensagem assinada e passar a(s) chave(s) de sessão de usuá-rio criptografada(s) para o SIM 7 05 para descriptografia.Usando o segredo compartilhado 740 (ou outra chave como podeser o caso), o módulo móvel 705 pode depois retornar a(s)chave(s) de usuário não-criptografada(s) 790 para o cliente710; desse modo autenticando o usuário para a rede 792.
A fase de autenticação de usuário para serviçoprove um mecanismo para o operador de rede móvel 720 parafornecer autenticação em nome dos serviços de terceiros. Si-milar ao nivel de usuário para segurança de rede, a fase deusuário para serviço é uma fase de autenticação multifatori-al e impede a rede de emitir sinais de serviço sem um usuá-rio 7 60 tendo estado presente durante pelo menos uma fase deautenticação. Há tipicamente dois modos de operação do ser-vidor de autenticação 715 considerando como sinais de servi-ço são emitidos. Primeiro, se o usuário 7 60 adquiriu um si-nal de usuário previamente, o servidor confiado 715 podeconsiderar o usuário 7 60 a ser autenticado e automaticamenteemitir um sinal de serviço (contanto que a solicitação parasinal de serviço seja apropriadamente assinada com o sinalde usuário 790, 795. Por outro lado, se a infra-estruturamóvel 720 não emitiu sinal de usuário 7 90, 7 95, o usuário760 será requerido autenticar de uma maneira similar àquelaesboçada acima para requerer sinal de usuário 7 95, 7 90.
FIG. 7C ilustra como as várias entidades de redecomunicam-se na rede independente 7 00 ao estabelecer comuni-cação segura entre um cliente 710 e servidor de terceiro 728.Como mencionado acima, o dispositivo móvel 705 e usuário 760podem previamente autenticar para o sistema móvel de opera-dor 720 como descrito. Conseqüentemente, uma comunicação se-gura existe entre o servidor de autenticação 715 e o cliente710 na validação apropriada de uma conta de faturamento parao dispositivo móvel 705 e autenticação de posse deste pelousuário 760. O servidor confiado 715 (ou infra-estrutura mó-vel 720 como pode ser o caso) pode depois emitir sinais deserviço 724 para vários serviços quando, por exemplo, o cli-ente 710 desej ar comprar serviços e/ou mercadoria de um ser-viço de terceiro 728. Conseqüentemente, o cliente 710 podeemitir um sinal de serviço 726 para o servidor de terceiroque depois valida o sinal 722 através do servidor de auten-ticação 715. Note que o servidor de terceiro 728 pode ou nãorequerer autenticação adicional e pode usar vários mecanis-mos como previamente descritos para executar tal validação.Também observe que o uso do sinal de serviço 726 não só es-tabelece uma comunicação segura entre o cliente 710 e o ser-vidor de terceiro 728, mas pode também indicar a habilidadede 7 60 do usuário para pagar por um ou mais serviços e/oumercadoria de uma maneira similar à previamente descrita.
Note que tipicamente até o sinal de serviço seremitido para o cliente 710, os sinais de segurança emitidossão de nenhum valor para qualquer outro serviço diferente doservidor de autenticação 715. A razão é que a hierarquia desegurança pode impedir qualquer parte externa de corretamen-te decodificar um sinal de dispositivo, um sinal de rede, ouaté mesmo um sinal de usuário, uma vez que todos eles deri-vam da raiz ou chave compartilhada 740 conhecida apenas parao dispositivo de SIM 705 e a infra-estrutura móvel 720. Étipicamente após o servidor de autenticação 715 emitir umsinal de serviço 724 que um serviço de rede de terceiro ar-bitrário 728 pode fazer uso de um sinal de segurança 724.Também observe que os sinais de segurança e mensagens acima(por exemplo, desafios, respostas de desafio, etc.) podemassumir vários formatos ou esquemas. Por exemplo, os sinaise/ou mensagens podem ser XML, formato de codificação similarbinario, ou outro que pode ser emitido pelo operador móvel720 que pode ou não querer expor certos elementos da rede acomunicações de SIM para partes intermediárias.
O uso acima de um dispositivo portátil de hardware7 05 para autenticação, identidade e/ou validação de pagamen-to pode ser usado para comprar serviço e/ou mercadoria devarejo em-linha ou locais (por exemplo, jornai, música, a-plicação de software em-linha, ou outra mercadoria e serviço)ou para um acesso possibilitando uma aplicação operar no PClocal ou cliente 710 (por exemplo, Word®, Adobe Photoshop,programa de Impressão, software de pagamento de acordo com ouso, etc.). Conseqüentemente, as modalidades acima são espe-cialmente vantaj osas para destravar software ou conteúdoprotegido livremente distribuído (por exemplo, música, ví-deos, jogos, etc.) em uma pluralidade de dispositivos hospe-deiros 710. Em outras palavras, uma licença agora é amarradaao dispositivo móvel portátil 705 que pode ser autenticadocomo descrito permitindo uma identidade digital portátil a-cima não amarrada a um conjunto limitado de dispositivos decomputação. Como tal um usuário 7 60 vai para a casa de umamigo e não tem que trazer todos seus programas ou outroconteúdo protegido; é todo acessível e autenticado por meiodo dispositivo portátil 705.
Como deveria ser apreciado do antecedente, há nu-merosos aspectos da presente invenção descritos aqui que po-dem ser usados independentemente um do outro, incluindo osaspectos que dizem respeito aos sinais de identidade, sinaisde pagamento, selecionando um de vários provedores de iden-tidade, selecionando um de vários provedores de pagamento, ea presença de software de transação comercial em um sistemade usuário final, um sistema de provedor de serviços, umsistema de provedor de identidade, e um sistema de provedorde pagamento. Deve também ser apreciado que em algumasmodalidades, todas as características acima descritas podemlidades, todas as características acima descritas podem serusadas juntas, ou qualquer combinação ou subconjunto das ca-racterísticas descritas acima pode ser empregado j unto emuma implementação particular, visto que os aspectos da pre-sente invenção não são limitados neste respeito.
As modalidades acima descritas da presente inven-ção podem ser implementadas em quaisquer de numerosos modos.Por exemplo, as modalidades podem ser implementadas usandohardware, software ou uma combinação destes. Quando imple-mentada em software, o código de software pode ser executadoem qualquer processador adequado ou coletânea de processado-res, fornecidos ou em um computador simples ou distribuídosentre computadores múltiplos. Deveria ser apreciado quequalquer componente ou coletânea de componentes que executamas funções descritas acima podem ser genericamente conside-rados como um ou mais controladores que controlam as funçõesacima debatidas. 0 um ou mais controladores podem ser imple-mentados de numerosos modos, como com hardware dedicado, oucom hardware de propósito geral (por exemplo, um ou maisprocessadores), ou seja, programados usando microcódigo ousoftware para executar as funções recitadas acima.
Deveria ser apreciado que os vários métodos esbo-çados aqui podem ser codificados como software que é execu-tável em um ou mais processadores que empregam qualquer umde uma variedade de sistemas operacionais ou plataformas.Adicionalmente, tal software pode ser escrito usando quais-quer de várias linguagens de programação adequadas e/ou fer-ramentas de programação ou manuscrito convencionais, e tam-bém pode ser compilado como código de linguagem de máquinaexecutável. Neste respeito, deveria ser apreciado que a mo-dalidade da invenção é direcionada a um meio legível porcomputador ou meios legíveis por computador múltiplos (porexemplo, uma memória de computador, um ou mais discos flexí-veis, discos laser, discos ópticos, fitas magnéticas, etc.)codificados com um ou mais programas que, quando executados,em um ou mais computadores ou outros processadores, executammétodos que implementam as várias modalidades da invençãodebatidas acima. 0 meio ou meios legíveis por computador po-dem ser transportáveis, de modo que o programa ou programasneles armazenados podem ser carregados em um ou mais compu-tadores diferentes ou outros processadores para implementarvários aspectos da presente invenção como debatidos acima.
Deveria ser entendido que o termo "programa" é a-qui usado em um sentido genérico para referir a qualquer ti-po de código de computador ou conjunto de instruções que po-dem ser empregados para programar um computador ou outroprocessador para implementar vários aspectos da presente in-venção como debatidos acima. Adicionalmente, deveria ser a-preciado que de acordo com um aspecto desta modalidade, umou mais programas de computação que, quando executados, exe-cutam métodos da presente invenção não necessitam residir emum computador ou processador simples, mas podem ser distri-buídos em uma maneira modular entre vários computadores ouprocessadores diferentes para implementar vários aspectos dapresente invenção.
Vários aspectos da presente invenção podem ser u-sados sozinhos, em combinação, ou em uma variedade de arran-jos não especificamente debatidos nas modalidades descritasno antecedente, e os aspectos da presente invenção descritosaqui não são limitados em sua aplicação aos detalhes e ar-ranjos de componentes expostos na descrição anterior ou i-lustrados nos desenhos. Os aspectos da invenção são capazesde outras modalidades e de ser praticados ou de ser realiza-dos de vários modos. Vários aspectos da presente invençãopodem ser implementados com relação a qualquer tipo de rede,agrupamento ou configuração. Nenhuma limitação é colocada naimplementação de rede. Conseqüentemente, a descrição anteri-or e desenhos são por via de exemplo apenas.
Uso de termos ordinais como "primeiro", "segundo","terceiro", etc, nas reivindicações para modificar um ele-mento da reivindicação por si só não conota qualquer priori-dade, precedência, ou ordem de um elemento de reivindicaçãosobre o outro ou a ordem temporal em que as ações de um mé-todo são executadas, mas são usados meramente como marcaçõespara distinguir um elemento da reivindicação tendo um certonome de outro elemento tendo um mesmo nome (mas para uso dotermo ordinal) para distinguir os elementos da reivindicação.
Também, a fraseologia e terminologia aqui usadassão para o propósito de descrição e não deveriam ser consi-deradas como limitativas. O uso de "incluindo", "compreen-dendo", ou "tendo", "contendo", "envolvendo", e variaçõesdestes aqui, é significado abranger os itens listados depoisdeles e equivalente destes como também itens adicionais.
Claims (190)
1. Método de autorizar uma transação em-linha en-tre um comprador e um comerciantef CARACTERIZADO pelo fatode que o método compreende ações de:fornecer, por meio de um provedor de identidade,verificação de uma identidade do comprador; efornecer, por meio de um provedor de pagamento,verificação de uma habilidade do comprador para pagar pelatransação, em que o provedor de identidade e o provedor de pagamento são entidades de rede diferentes.
2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que adicionalmente compreende umaação de fornecer, por meio do comprador, informação de iden-tificação para facilitar o provedor de identidade na verifi- cação da identidade do comprador.
3. Método, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que a ação de fornecer informaçãode identificação inclui uma ação de fornecer um número demódulo de identidade de assinante (SIM), um endereço de rede, ou uma única identificação de hardware (ID).
4. Método, de acordo com a reivindicação 2,CARACTERIZADO pelo fato de que a ação de fornecer informaçãode identificação inclui fornecer informação de identificaçãoprogramaticamente, por meio de um computador de usuário fi-nal associado ao comprador, a informação de identificaçãofornecida em uma indicação por pelo menos uma aplicação ope-rando no computador de usuário final que o comprador preten-de fazer uma compra.
5. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a ação de fornecer verifica-ção da habilidade do comprador para pagar é executada peloprovedor de pagamento apenas após a identidade do comprador ser verificada.
6. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que o provedor de pagamento em-prega a verificação de identidade para executar a verifica-ção de pagamento.
7. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o provedor de identidade é umbanco ou uma agência governamental.
8. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o provedor de identifique fornece verificação de identificação por meio de um sinal deidentidade a ser recebido pelo provedor de pagamento, e emque o provedor de pagamento fornece verificação de pagamentopor meio de um sinal de pagamento a ser recebido pelo comer-ciante ,
9. Método, de acordo com a reivindicação 8,CARACTERIZADO pelo fato de que o sinal de identidade incluium intervalo predeterminado de tempo durante o qual o sinalde identidade pode ser processado, em que, quando o interva-lo predeterminado de tempo expirar, o sinal de identidade é considerado inválido.
10. Método, de acordo com a reivindicação 8,CARACTERIZADO pelo fato de que o sinal de pagamento incluium intervalo predeterminado de tempo durante o qual o sinalde pagamento pode ser processado, em que, quando o intervalopredeterminado de tempo expirar, o sinal de pagamento é con-siderado inválido.
11. Sistema de computador tendo uma pluralidade de nós interconectados por meio de uma rede, o sistema de com-putador adaptado para conduzir uma transação em-linha entreum comprador e um comerciante, CARACTERIZADO pelo fato deque o sistema de computador compreende:um primeiro nó configurado para fornecer verifica- ção de uma identidade do comprador; eum segundo nó configurado para fornecer verifica-ção de uma habilidade do comprador para pagar pela transação,em que o primeiro nó e o segundo nó são associados a entida-des de rede diferentes.
12. Sistema de computador, de acordo com a reivin-dicação 11, CARACTERIZADO pelo fato de que adicionalmentecompreende um nó de comprador associado ao comprador, o nóde comprador adaptado para fornecer informação de identifi-cação para facilitar o primeiro nó na verificação da identi- dade do comprador.
13. Sistema de computador, de acordo com a reivin-dicação 12, CARACTERIZADO pelo fato de que o nó de compradorfornece um número de módulo de identidade de assinante (SIM),um endereço de rede, ou uma única identificação de hardware como a informação de identificação.
14. Sistema de computador, de acordo com a reivin-dicação 12, CARACTERIZADO pelo fato de que o nó de compradorinclui um computador de usuário final que fornece a informa-ção de identificação programaticamente quando um sinal parainiciar a transação é emitido por pelo menos uma aplicaçãooperando no computador de usuário final.
15. Sistema de computador, de acordo com a reivin- dicação 11, CARACTERIZADO pelo fato de que o segundo nó for-nece verificação da habilidade do comprador para pagar ape-nas após o primeiro nó verificar a identidade do comprador.
16. Sistema de computador, de acordo com a reivin-dicação 15, CARACTERIZADO pelo fato de que o segundo nó em- prega a verificação de identidade para executar a verifica-ção de pagamento.
17. Sistema de computador, de acordo com a reivin-dicação 11, CARACTERIZADO pelo fato de que o primeiro nó éassociado a uma entidade de rede que é um banco ou uma agên- cia governamental.
18. Sistema de computador, de acordo com a reivin-dicação 11, CARACTERIZADO pelo fato de que o primeiro nófornece verificação de identificação por meio de um sinal deidentidade a ser recebido pelo segundo nó, e em que o segun- do nó fornece verificação de pagamento por meio de um sinalde pagamento a ser recebido pelo comerciante.
19. Sistema de computador, de acordo com a reivin-dicação 18, CARACTERIZADO pelo fato de que o sinal de iden-tidade inclui um intervalo predeterminado de tempo durante oqual o sinal de identidade pode ser processado, em que quan-do o intervalo predeterminado de tempo expira, o sinal deidentidade é considerado inválido.
20. Sistema de computador, de acordo com a reivin-dicação 18, CARACTERIZADO pelo fato de que o sinal de paga-mento inclui um intervalo predeterminado de tempo durante oqual o sinal de pagamento pode ser processado, em que quandoo intervalo predeterminado de tempo expira, o sinal de paga-mento é considerado inválido.
21. Programa distribuído para conduzir transaçõesem-linha, o programa tendo uma pluralidade de componentes desoftware distribuído em um sistema de computador tendo umapluralidade de nós interconectados por meio de uma rede, ca-da um de a pluralidade de componentes configurados para co-municar na rede com pelo menos um outro da pluralidade decomponentes de software, CARACTERIZADO pelo fato de que oprograma distribuído compreende:um primeiro componente instalado em um primeiro nódo qual um usuário final acessa a rede, o primeiro componen-te adaptado para fornecer um identificador na rede em res-posta a uma indicação para conduzir uma transação entre ousuário final e um comerciante, o identificador associado aousuário final'e/ou o primeiro nó;pelo menos um segundo componente do programa dis-tribuído instalado em pelo menos um segundo nó, o pelo menosum segundo componente configurado para receber o identifica-dor e fornecer verificação de uma habilidade do usuário fi-nal para pagar pela transação; eum terceiro componente do programa distribuídoinstalado em um terceiro nó associado ao comerciante, o ter-ceiro componente configurado para receber a verificação dahabilidade do usuário final para pagar antes de prosseguircom a transação em-linha.
22. Programa distribuído, de acordo com a reivin-dicação 21, CARACTERIZADO pelo fato de que o pelo menos umsegundo componente compreende:um componente de identificação do programa distri-buído instalado em um nó de identificador associado a pelomenos um provedor de identidade, o componente de identifica-ção configurado para receber o identificador e fornecer umsinal de identidade que verifica a identidade do usuário fi- nal com base no identificador; eum componente de pagamento do programa distribuídoinstalado em um nó de pagamento associado a pelo menos umprovedor de pagamento, o componente de pagamento configuradopara receber o sinal de identidade e fornecer um sinal de pagamento com base em sinal de identidade, o sinal de paga-mento inclui a verificação da habilidade do usuário finalpara pagar.
23. Sistema de computador tendo uma pluralidade denós interconectados por meio de uma rede, o sistema de com-putador adaptado para facilitar uma transação em-linha entreum comprador e um comerciante fornecendo um ou mais de mer-cadoria, serviços, ou ambos, CARACTERIZADO pelo fato de queo sistema de computador compreende:um primeiro dispositivo de rede associado ao com-prador, o primeiro dispositivo de rede adaptado para progra-maticamente emitir informação de identificação indicativa docomprador em uma indicação do comprador iniciar a transação,em que a informação de identificação não é uma senha estabe-lecida pelo comprador; eum segundo dispositivo de rede associado ao prove-dor de identidade, o segundo dispositivo de rede adaptadopara receber a informação de identificação e emitir um sinalde identidade que verifica a identidade do comprador pelatransação.
24. Método de autorizar uma transação em-linha en-tre um comprador e um comerciante, CARACTERIZADO pelo fatode que o método compreende ações de:gerar um sinal de identidade que fornece verifica-ção de uma identidade do comprador, com base em informaçãode identificação diferente de uma senha estabelecida pelocomprador; egerar um sinal de pagamento que fornece verifica-ção de uma habilidade do comprador para pagar pela transação.
25. Em um dispositivo de computação em um ambientede rede distribuído, método de autenticar um módulo móvel dedispositivo portátil como sendo amarrado a uma conta de fa-turamento de uma infra-estrutura móvel para permitir um a-cesso de usuário a serviços, mercadoria, ou ambos, validandoo módulo móvel em uma rede independente da rede de rádio dainfra-estrutura móvel, CARACTERIZADO pelo fato de que o mé-todo compreende:receber uma solicitação para autenticar um módulomóvel ao tentar ganhar acesso a serviços, mercadoria, ou am-bos;receber uma ou mais credenciais do módulo móvelusado por uma infra-estrutura móvel validando informação deconta de faturamento desta;enviar a uma ou mais credenciais à infra-estruturamóvel em uma rede independente separada da rede de rádio dainfra-estrutura móvel; ereceber na rede independente informação de auten-ticação que corresponde a um estado de ativação para a contade faturamento do módulo móvel na infra-estrutura móvel,desse modo permitindo uma identidade digital portátil con-trolar acesso aos serviços, mercadoria, ou ambos.
26. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) para a infra-estrutura móvel,e em que a uma ou mais credenciais incluem informação combase em um desafio da infra-estrutura móvel e uma chave com-partilhada entre o SIM e a infra-estrutura móvel.
27. Método, de acordo com a reivindicação 26,CARACTERIZADO pelo fato de que o SIM é incluido dentro de umpedaço de hardware diferente de um dispositivo de transmis-são de rádio e é ligado ao dispositivo de computação pormeio de uma ou mais portas com fios rigidos ou sem.
28. Método, de acordo com a reivindicação 26,CARACTERIZADO pelo fato de que o SIM é ligado diretamente aodispositivo de computação por meio de uma conexão de hardwa-re especial especificamente projetada para o SIM.
29. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são requeridos de um serviço remoto conectado à redeindependente.
30. Método, de acordo com a reivindicação 29,CARACTERIZADO pelo fato de que a rede independente inclui aInternet.
31. Método, de acordo com a reivindicação 30,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são distribuídos livremente na Internet e residem emum dispositivo de computação local, e em que a autenticaçãodo módulo móvel permite os conteúdos dos serviços, mercado-ria, ou ambos, serem destravados no dispositivo de computa-ção local.
32. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são um ou mais de: um programa de software no dispo-sitivo de computação; parte do hardware ligada ao dispositi-vo de computação; conteúdo de multimídia para consumo pelodispositivo de computação; ou acesso ao próprio dispositivode computação.
33. Método, de acordo com a reivindicação 32,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, têm niveis múltiplos de acesso disponível, e em quecom base na autenticação do dispositivo móvel um ou mais dosniveis disponíveis são ativados.
34. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que o método adicionalmente com-preende :com base no estado de ativação do módulo móvel,determinar se um acordo de contrato feito entre um comerci-ante para os serviços, mercadoria, ou ambos, e a infra-estrutura móvel requer do usuário entrar uma ou mais creden-ciais de entrada de usuário para autenticar o usuário, emque se verdadeiro o método adicionalmente inclui:enviar uma solicitação ao usuário para introduzira uma ou mais credenciais de entrada de usuário; ecom base na entrada de usuário, determinar se ousuário é autorizado para acessar o serviço protegido.
35. Método, de acordo com a reivindicação 34,CARACTERIZADO pelo fato de que as credenciais de entrada deusuário são armazenadas em um ou mais do módulo móvel, dainfra-estrutura móvel, ou de um servidor que corresponde aocomerciante.
36. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que se o módulo móvel não é au-tenticado pela infra-estrutura móvel, o método adicionalmen-te compreende:receber na rede independente uma mensagem de desa-tivação para desativar o módulo móvel.
37. Em uma infra-estrutura móvel em um ambiente derede distribuído, método de autenticar um módulo móvel de umdispositivo portátil como sendo amarrado a uma conta defaturamento da infra-estrutura móvel para permitir um acessode usuário a serviços, mercadoria, ou ambos, validando o mó-dulo móvel em uma rede independente da rede de rádio da in-fra-estrutura móvel, CARACTERIZADO pelo fato de que o métodocompreende:receber uma solicitação para autenticar um módulomóvel quando um usuário estiver tentando ganhar acesso aserviços, mercadoria, ou ambos, em que o módulo móvel cor-responde a uma conta de faturamento de uma infra-estruturamóvel, e em que a solicitação é recebida em uma rede inde-pendente separada da rede de rádio da infra-estrutura móvel;receber na rede independente uma ou mais credenci-ais do módulo móvel; ecom base em validação do um ou mais credenciais,enviar na rede independente informação de autenticação quecorresponde a um estado de ativação para a conta de fatura-mento do módulo móvel, desse modo permitindo uma identidadedigital portátil controlar acesso aos serviços, mercadoria,ou ambos, por meio de duas redes independentes.
38 Método, de acordo com a reivindicação 37,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) para a infra-estrutura móvel,e em que o método adicionalmente inclui:enviar um desafio ao dispositivo de SIM na redeindependente;receber uma resposta que inclui a uma ou mais cre-denciais que correspondem à informação dentro do desafio euma chave compartilhada entre o SIM e a infra-estrutura mó-vel;e com base na resposta ao desafio, autenticar oestado de ativação do SIM de acordo com informação para aconta de faturamento.
39. Método, de acordo com a reivindicação 38,CARACTERIZADO pelo fato de que a solicitação, a uma ou maiscredenciais, e informação de autenticação são roteadas paraa infra-estrutura móvel por meio de um servidor confiado eem que a autenticação estabelece uma comunicação confiadaentre o SIM e o servidor confiado.
40. Método, de acordo com a reivindicação 38, CARACTERIZADO pelo fato de que o SIM faz parte de um dispo-sitivo que não pode comunicar na rede de rádio da infra-estrutura móvel.
41. Método, de acordo com a reivindicação 37,CARACTERIZADO pelo fato de que os serviços, mercadoria, ou ambos, são requeridos de um serviço remoto conectado à redeindependente.
42. Método, de acordo .com a reivindicação 37,CARACTERIZADO pelo fato de que a rede independente inclui aInternet.
43. Método, de acordo com a reivindicação 42, CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são distribuídos livremente na Internet e residem emum dispositivo de computação local, e em que a autenticaçãodo módulo móvel permite os conteúdos dos serviços, mercado- ria, ou ambos, serem destravados em um dispositivo de compu-tação local.
44. Método, de acordo com a reivindicação 37,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são um ou mais de: um programa de software em um dis- positivo de computação; um pedaço de hardware ligado ao dis-positivo de computação; conteúdo de multimídia para consumopelo dispositivo de computação; ou acesso ao próprio sistemade computação.
45. Método, de acordo com a reivindicação 37,CARACTERIZADO pelo fato de que o método adicionalmente com-preende: com base no estado de ativação do módulo móvel, de-terminar se um acordo de contrato feito entre um comerciante para os serviços, mercadoria, ou ambos, e a infra-estruturamóvel requer de um usuário entrar em uma ou mais credenciaisde entrada de usuário para autenticar o usuário, em que severdadeiro o método adicionalmente inclui:enviar uma solicitação ao módulo móvel para inci- tar o usuário introduzir a uma ou mais credenciais de entra-da de usuário; ecom base na entrada de usuário, determinar se ousuário está autorizado para acessar o serviço protegido.
46. Método, de acordo com a reivindicação 34,CARACTERIZADO pelo fato de que as credenciais de entrada deusuário são armazenadas em um ou mais do módulo móvel, dainfra-estrutura móvel, ou de um servidor que corresponde aocomerciante.
47. Método, de acordo com a reivindicação 37, CARACTERIZADO pelo fato de que se o módulo móvel não é au-tenticado pela infra-estrutura móvel, o método adicionalmen-te compreende:enviar uma mensagem de desativação na rede de rá-dio da infra-estrutura móvel, a rede independente, ou ambos, para desativar o módulo móvel.
48. Dispositivo portátil usado para interfacear ummódulo móvel com uma máquina de computação local usada naautenticação do módulo móvel como tendo uma conta de fatura-mento válida para uma infra-estrutura móvel para permitir umacesso de usuário a serviços, mercadoria, ou ambos,CARACTERIZADO pelo fato de que o dispositivo portátil com-preende : um retentor de caixa para reter prendendo um módu-lo móvel que tem uma conta de faturamento com uma infra-estrutura móvel usada para validar o módulo móvel ao tentarganhar acesso aos serviços, mercadoria, ou ambos, em uma má-quina de computação local; uma interface que permite o dispositivo portátil: enviar uma ou mais credenciais do módulo móvel pa-ra o dispositivo de computação local para autenticar o módu-lo móvel para a infra-estrutura móvel, ereceber informação de autenticação do dispositivode computação local que valida um estado para a conta de fa-turamento, em que a interface possibilita o envio e recebi-mento de informação em uma rede independente separada da re-de de rádio da infra-estrutura móvel, desse modo permitindouma identidade digital portátil controlar acesso aos servi-ços, mercadoria, ou ambos por meio de duas redes independen-tes .
49. Dispositivo portátil, de acordo com a reivin-dicação 48, CARACTERIZADO pelo fato de que o módulo móvel éum módulo de identidade de assinante (SIM) para a infra-estrutura móvel, e em que a uma ou mais credenciais inclueminformação com base em um desafio da infra-estrutura móvel euma chave compartilhada entre o SIM e a infra-estrutura mó-
50. Dispositivo portátil, de acordo com a reivin-dicação 4 9, CARACTERIZADO pelo fato de que o retentor decaixa é um pedaço de hardware diferente de um dispositivo detransmissão de rádio e depois interface permite o dispositi-vo portátil ligar ao dispositivo de computação local pormeio de uma ou mais portas com fios rígidos ou sem.
51. Dispositivo portátil, de acordo com a reivin-dicação 4 9, CARACTERIZADO pelo fato de que a rede indepen-dente inclui a Internet.
52. Dispositivo portátil, de acordo com a reivin-dicação 49, CARACTERIZADO pelo fato de que os serviços, mer-cadoria, ou ambos, são distribuídos livremente na Internet eresidem no dispositivo de computação local, e em que a au-tenticação do módulo móvel permite os conteúdos dos serviços,mercadoria, ou ambos, serem destravados no dispositivo decomputação local.
53. Dispositivo portátil, de acordo com a reivin-dicação 49, CARACTERIZADO pelo fato de que os serviços, mer-cadoria, ou ambos, são um ou mais de: um programa de softwa-re no dispositivo de computação local; um pedaço de hardwareligado ao dispositivo de computação local; conteúdo de mul-timídia para consumo pelo dispositivo de computação local;ou acesso ao próprio dispositivo de computação local.
54. Dispositivo portátil, de acordo com a reivin-dicação 53, CARACTERIZADO pelo fato de que os serviços, mer-cadoria, ou ambos, têm niveis múltiplos de acesso disponível,e em que com base na autenticação do dispositivo um móvel oumais dos niveis disponíveis é ativado.
55. Dispositivo portátil, de acordo com a reivin-dicação 4 9, CARACTERIZADO pelo fato de que a interface é a-dicionalmente usada para receber credenciais de usuário para validar o usuário.
56. Dispositivo portátil, de acordo com a reivin-dicação 55, CARACTERIZADO pelo fato de que as credenciais deentrada de usuário são armazenadas em um ou mais do módulomóvel, da infra-estrutura móvel, ou de um servidor que cor- responde ao comerciante.
57. Em um dispositivo de computação em um ambientede rede distribuído, método de permitir acesso a serviçoslivremente distribuídos, mercadoria, ou ambos, em um dispo-sitivo de computação configurado para autenticar um dispôsi- tivo portátil como sendo amarrado a uma conta de faturamentode uma infra-estrutura móvel em uma rede independente da re-de de rádio da infra-estrutura móvel, CARACTERIZADO pelo fa-to de que o método compreende:receber em um dispositivo de computação local um ou mais serviços livremente distribuídos, mercadoria, ou am-bos, que inclui conteúdo protegido que apenas dispositivosde computação autorizados são permitidos acesso a estes;receber uma ou mais credenciais de um módulo móvelusadas por uma infra-estrutura móvel na validação de infor- mação de conta de faturamento deste;enviar a uma ou mais credenciais à infra-estruturamóvel em uma rede independente separada da rede de rádio dainfra-estrutura móvel;receber na rede independente informação de auten-ticação que corresponde a um estado de ativação para a contade faturamento do módulo móvel na infra-estrutura móvel; ecom base na informação de autenticação, receberuma licença que permite o dispositivo de computação localacessar pelo menos uma porção do conteúdo protegido, dessemodo permitindo uma identidade digital portátil acessar osserviços, mercadoria, ou ambos, em uma pluralidade de dispo-sitivos de computação diferentes sem restringir vários dis-positivos de computação autorizados para acessar o conteúdoprotegido.
58. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que os serviços livremente dis-tribuídos, mercadoria, ou ambos, são recebidos por meio darede independente ou comprados em um armazenamento e direta-mente instalado no dispositivo de computação local.
59. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que a licença está limitada emvida, se o módulo móvel é conectado à máquina de computaçãolocal, ou ambos.
60. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) para a infra-estrutura móvel,e em que a uma ou mais credenciais incluem informação combase em um desafio da infra-estrutura móvel e uma chave com-partilhada entre o SIM e a infra-estrutura móvel.
61. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que o SIM é incluído dentro de umpedaço de hardware diferente de um dispositivo de transmis-são de rádio e é ligado ao dispositivo de computação pormeio de uma ou mais portas com fios rígidos ou sem.
62. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que o SIM é ligado diretamente aodispositivo de computação local por meio de uma conexão dehardware especial especificamente projetada para o SIM.
63. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são requeridos de um serviço remoto conectado à redeindependente.
64. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que a rede independente inclui aInternet.
65. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são um ou mais de: um programa de software no dispo-sitivo de computação local; um pedaço de hardware ligado aodispositivo de computação local; ou conteúdo de multimídiapara consumo pelo dispositivo de computação local.
66. Método, de acordo com a reivindicação 57,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, têm niveis múltiplos de acesso disponível, e em quecom base na licença um ou mais dos niveis disponíveis sãoativados.
67. Em um sistema de computação amarrado a uma re-de distribuída, método de usar um dispositivo de hardwareportátil simples para permitir acesso a serviços protegidos,mercadoria, ou ambos, que requer autenticação ou de fatorsimples ou multif atorial, CARACTERIZADO pelo fato de que ométodo compreende: enviar uma ou mais credenciais de um módulo móvel para um dispositivo de computação local que requer acesso aserviços protegidos, mercadoria, ou ambos para permitir odispositivo de computação local acessar a estes se o módulomóvel tiver uma conta de faturamento ativa com uma infra-estrutura móvel, que é configurada adicionalmente para au- tenticar um usuário em um processo multifatorial, e em que auma ou mais credenciais para o módulo móvel são enviadas emuma rede independente separada da rede de rádio da infra-estrutura móvel; receber, do dispositivo de computação local, in-formação de autenticação que corresponde a um estado de ati-vação para a conta de faturamento do módulo móvel; e com base na informação de autenticação, determinarse os serviços protegidos, mercadoria, ou ambos, adicional-mente requerem autenticação de usuário, em que se verdadeiro o método adicionalmente compreende: enviar uma solicitação por uma ou mais credenciaisde entrada de usuário para comparação com uma versão segura-mente armazenada desta; e com base em informação acerca da comparação, de-terminar se o usuário é autorizado acessar os serviços pro-tegidos, mercadoria, ou ambos, para permitir.
68. Método, de acordo com a reivindicação 67, emque a um ou mais credenciais de entrada de usuário são crip-tografadas usando uma chave compartilhada entre o módulo mó-vel e a infra-estrutura móvel, CARACTERIZADO pelo fato deque o método adicionalmente compreende:enviar a uma ou mais credenciais de entrada de u-suário criptografadas ao dispositivo de computação local pa-ra transferência para a infra-estrutura móvel por meio darede independente para comparação destas;receber a informação acerca da comparação indican-do que o usuário como apropriadamente autenticado para a in-fra-estrutura móvel; eenviar uma licença ao dispositivo de computaçãolocal que permite o acesso de usuário a serviços protegidos,mercadoria, ou ambos.
69. Método, de acordo com a reivindicação 68,CARACTERIZADO pelo fato de que a licença é limitada com baseem: vida, a proximidade do módulo móvel ao dispositivo decomputação local, ou ambos, e em que sob expiração da licen-ça o usuário e o módulo móvel são requeridos re-autenticarpara a infra-estrutura móvel para ganhar acesso adicional-mente aos serviços protegidos, mercadoria, ou ambos.
70. Método, de acordo com a reivindicação 68,CARACTERIZADO pelo fato de que a uma ou mais credenciais deentrada do usuário são especificas ao comerciante da merca-doria, serviços, ou ambos, e em que o comerciante tem umarelação contratual confiada com a infra-estrutura móvel in-dicando que a um ou mais credenciais de usuário são necessá-rias para propósitos de autenticação.
71. Método, de acordo com a reivindicação 68,CARACTERIZADO pelo fato de que os serviços protegidos, mer-cadoria, ou ambos, correspondem a uma aplicação operando nodispositivo de computação local conectado ao módulo móvel.
72. Método, de acordo com a reivindicação 67,CARACTERIZADO pelo fato de que os serviços protegidos, mer-cadoria, ou ambos, correspondem a uma aplicação operando nodispositivo de computação local conectado ao módulo móvel, eem que a uma ou mais credenciais de entrada do usuário sãoarmazenadas no dispositivo de computação local.
73. Método, de acordo com a reivindicação 67,CARACTERIZADO pelo fato de que os serviços protegidos, mer-cadoria, ou ambos, são remotamente controlados por um servi-ço no sistema distribuído, e em que a uma ou mais credenci-ais de entrada do usuário são armazenadas em um servidor re-moto .
74. Método, de acordo com a reivindicação 67,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) , e em que a uma ou mais cre-denciais são determinadas com base em um desafio da infra-estrutura móvel e uma chave compartilhada entre o dispositi-vo de SIM e a infra-estrutura móvel.
75. Método, de acordo com a reivindicação 74,CARACTERIZADO pelo fato de que o SIM é incluido dentro de umpedaço de hardware diferente de um dispositivo de transmis-são de rádio e é ligado ao dispositivo de computação pormeio de uma ou mais portas com fios rigidos ou sem.
76. Método, de acordo com a reivindicação 74,CARACTERIZADO pelo fato de que o SIM é ligado diretamente aodispositivo de computação local por meio de uma conexão dehardware especial especificamente projetada para o SIM.
77. Método, de acordo com a reivindicação 67,CARACTERIZADO pelo fato de que os serviços, mercadoria, ouambos, são um ou mais de: um programa de software no dispo-sitivo de computação local; um pedaço de hardware ligado aodispositivo de computação local; ou conteúdo de multimídiapara consumo pelo dispositivo de computação local.
78. Em uma infra-estrutura móvel amarrada a umarede distribuída, método de usar um dispositivo de hardwareportátil simples para permitir acesso a serviços protegidos,mercadoria, ou ambos, que requerem autenticação de fatorsimples ou multifatorial, CARACTERIZADO pelo fato de que ométodo compreende:receber uma ou mais credenciais de um módulo móvelque indica uma solicitação para acesso para serviços prote-gidos , mercadoria, ou ambos para permitir um acesso de dis-positivo de computação local a este, em que a uma ou maiscredenciais são recebidas para o módulo móvel em uma redeindependente separada da rede de rádio da infra-estruturamóvel;usar a uma ou mais credenciais para autenticar omódulo móvel como tendo uma conta de faturamento ativa com ainfra-estrutura móvel que é configurada adicionalmente paraautenticar um usuário em um processo multifatorial; edeterminar se os serviços protegidos, mercadoria,ou ambos, adicionalmente requerem autenticação de usuário,em que se verdadeiro o método adicionalmente compreende:enviar na rede independente uma solicitação poruma ou mais credenciais de entrada de usuário para compara-ção com uma versão seguramente armazenada desta,receber a uma ou mais credenciais de entrada de usuário na rede independente, em que a uma ou mais credenci-ais de entrada do usuário recebidas são criptografadas usan-do uma chave compartilhada entre o módulo móvel e a infra-estrutura móvel,com base na comparação da uma ou mais credenciais de entrada de usuário criptografadas com a versão seguramen-te armazenada desta, enviar informação que indica a autenti-cação do usuário para a infra-estrutura móvel que permiteuma emissão de uma licença para fornecer o acesso do dispo-sitivo de computação local aos serviços protegidos, mercado- ria, ou ambos.
79. Método, de acordo com a reivindicação 78,CARACTERIZADO pelo fato de que a licença é limitada com baseem: vida, a proximidade do módulo móvel ao dispositivo decomputação local, ou ambos, e em que sob expiração da licen- ça o usuário e o módulo móvel são requeridos a re-autenticarpara infra-estrutura móvel para ganhar acesso adicionalmenteaos serviços protegidos, mercadoria, ou ambos.
80. Método, de acordo com a reivindicação 78,CARACTERIZADO pelo fato de que a uma ou mais credenciais de entrada do usuário são especificas ao comerciante da merca-doria, serviços, ou ambos, e em que o comerciante tem umarelação contratual confiada com a infra-estrutura móvel queindica que a uma ou mais credenciais de usuário são necessá-rias para propósitos de autenticação.
81. Método, de acordo com a reivindicação 78,CARACTERIZADO pelo fato de que os serviços protegidos, mer-cadoria, ou ambos, correspondem a uma aplicação operando no dispositivo de computação local conectado ao módulo móvel.
82. Método, de acordo com a reivindicação 7 8,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) , e em que a uma ou mais cre-denciais são determinadas com base em um desafio da infra- estrutura móvel e uma chave compartilhada entre o dispositi-vo de SIM e a infra-estrutura móvel.
83. Método, de acordo com a reivindicação 82,CARACTERIZADO pelo fato de que a chave compartilhada paracriptografar a uma ou mais credenciais de usuário é diferen- te da chave compartilhada usada para a uma ou mais credenci-ais do módulo móvel.
84. Em um sistema distribuído, estrutura de compu-tação usada para abstrair um computador hospedeiro de umsistema de operador móvel ao conectar um módulo móvel a este a fim de marcar o computador hospedeiro como equipamento pe-riférico ao invés de um terminal móvel sujeito aos requeri-mentos rigidos do sistema de operador móvel, CARACTERIZADOpelo fato de que a estrutura de computação compreende: ummódulo de identidade de assinante (SIM) que inclui informa- ção associada a uma conta de faturamento para um sistema deoperador móvel; um computador hospedeiro que conecta o SIMao sistema de operador móvel em uma rede independente da re-de de rádio do sistema de operador móvel para autenticar ainformação de conta de faturamento para o SIM;uma unidade de SIM ligada ao computador hospedeiropara ler informação do SIM para uso pelo menos na autentica-ção do SIM para o sistema de operador móvel na rede indepen- dente;e uma interface atuando como uma barreira de pro-teção entre o SIM e a unidade de SIM que define um protocolousado para proteger o SIM de ataque restringindo um ou maisde um número, seqüência, ou comprimento, de comandos envia- dos entre a unidade de SIM e o SIM.
85. Estrutura de computação, de acordo com a rei-vindicação 84, CARACTERIZADA pelo fato de que o SIM é conec-tado ao computador hospedeiro através de uma porta de hard-ware, porta sem fios, ou ambas.
86. Estrutura de computação, de acordo com a rei-vindicação 84, CARACTERIZADA pelo fato de que a interface éparte de um dispositivo portátil usado na conexão do SIM aocomputador hospedeiro.
87. Estrutura de computação, de acordo com a rei- vindicação 86, CARACTERIZADA pelo fato de que o dispositivoportátil não é configurado para comunicações de rádio na re-de do sistema de operador móvel.
88. Estrutura de computação, de acordo com a rei-vindicação 84, CARACTERIZADA pelo fato de que a autenticação do SIM na rede independente é usada para ganhar acesso aodispositivo de computação hospedeiro.
89. Estrutura de computação, de acordo com a rei-vindicação 84, CARACTERIZADA pelo fato de que a autenticaçãodo SIM é usada para ganhar acesso a serviços, mercadoria, ouambos, oferecidos na rede independente.
90. Estrutura de computação, de acordo com a rei-vindicação 84, CARACTERIZADA pelo fato de que a autenticação do dispositivo de SIM é para serviços, mercadoria, ou ambos,oferecidos na rede independente e associados a uma aplicaçãode software operando no computador hospedeiro separado deuma aplicação de navegação na Rede.
91. Estrutura de computação, de acordo com a rei- vindicação 84, CARACTERIZADA pelo fato de que o protocolo inclui uma máquina de estado formal que é usada para mantera trilha do um ou mais do número, seqüência, ou comprimentodas comunicações entre a unidade de SIM e o SIM.
92. Em um sistema de computação amarrado a uma re- de distribuída, método de estabelecer comunicações seguras de nivel de transporte entre um cliente e um servidor em umarede do contrário insegura estabelecendo um tunelamento se-guro entre um módulo móvel conectado ao cliente e uma infra-estrutura móvel associada entre eles para delegar chaves de sessão para pelo menos uma pilha de software no cliente paraum ou mais de propósitos de criptografia ou assinatura,CARACTERIZADO pelo fato de que o método compreende: identificar uma ou mais credenciais de um módulomóvel conectado a um computador hospedeiro; enviar a uma ou mais credenciais para uma infra-estrutura móvel para autenticação de uma conta de faturamen-to válida para o módulo móvel, em que a solicitação é envia-da em uma rede independente separada de uma rede de rádiocorrespondendo à infra-estrutura móvel; ecom base na autenticação, receber do módulo móveluma chave de sessão para uso em uma comunicação segura denivel de transporte na rede independente entre o computadorhospedeiro e um servidor.
93. Método, de acordo com a reivindicação 92,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) para a infra-estrutura móvel,e em que a uma ou mais credenciais incluem informação combase em um desafio da infra-estrutura móvel e uma chave com-partilhada entre o SIM e a infra-estrutura móvel.
94. Método, de acordo com a reivindicação 93,CARACTERIZADO pelo fato de que o SIM é incluído dentro de umpedaço de hardware diferente de um dispositivo de transmis-são de rádio e é ligado ao dispositivo de computação pormeio de uma ou mais portas com fios rigidos ou sem.
95. Método, de acordo com a reivindicação 93,CARACTERIZADO pelo fato de que a rede independente inclui aInternet.
96. Método, de acordo com a reivindicação 93,CARACTERIZADO pelo fato de que o servidor faz parte de umaestrutura que tem uma relação confiada com a infra-estruturamóvel de modo que as chaves de sessão são adicionalmentepassadas da infra-estrutura móvel ao servidor para a comuni-cação segura de nivel de transporte com o computador hospe-deiro .
97. Método, de acordo com a reivindicação 96,CARACTERIZADO pelo fato de que adicionalmente compreende:requerer uma conexão a um servidor de terceironão-parte da estrutura;receber outra chave de sessão para comunicação se-gura entre o computador hospedeiro e o servidor de terceiro;eusar a outra chave de sessão para comunicação se-gura de nivel de transporte com o servidor de terceiro.
98. Método, de acordo com a reivindicação 97,CARACTERIZADO pelo fato de que antes de usar a outra chavede sessão para comunicar com o terceiro, o método adicional-mente compreende:enviar a outra chave de sessão e um sinal para oservidor de terceiro, em que o servidor de terceiro valida aoutra chave de sessão autenticando o sinal através do servi-dor confiado que faz parte da estrutura; ecom base na autenticação do sinal, usar a outrachave de sessão para comunicação segura com o servidor deterceiro.
99. Método, de acordo com a reivindicação 98,CARACTERIZADO pelo fato de que o servidor de terceiro é co-merciante de serviços, mercadoria, ou ambos, e em que um u-suário deve adicionalmente autenticar para o servidor deterceiro fornecendo credenciais de entrada de usuário.
100. Método, de acordo com a reivindicação 99,CARACTERIZADO pelo fato de que autenticação do SIM para ainfra-estrutura móvel validando a conta de faturamento destaé usada como verificação de um fundo de pagamento para osserviços, mercadoria, ou ambos, ao fazer uma compra do co-merciante.
101. Método, de acordo com a reivindicação 93,CARACTERIZADO pelo fato de que a chave de sessão expira combase em uma ou mais de toda vida da chave de sessão ou vá- rias mensagens criptografadas, assinadas, ou ambas, com achave de sessão, sob cuja expiração o SIM é requerido parare-autorizar a infra-estrutura móvel para outra comunicaçãosegura entre o computador hospedeiro e o servidor.
102. Método, de acordo com a reivindicação 93, CARACTERIZADO pelo fato de que o SIM é conectado externamen-te ao computador hospedeiro, ainda mantido a este dentro deproximidade intima fisica.
103. Método, de acordo com a reivindicação 102,CARACTERIZADO pelo fato de que a proximidade intima fisica é dentro de 10 jardas (9,14 m) .
104. Método, de acordo com a reivindicação 103,CARACTERIZADO pelo fato de que a conexão externa é uma cone-xão sem fios.
105. Método, de acordo com a reivindicação 93, CARACTERIZADO pelo fato de que a chave de sessão é derivadado SIM e da infra-estrutura móvel com base em um segredocompartilhado entre o SIM e a infra-estrutura móvel.
106. Método, de acordo com a reivindicação 93,CARACTERIZADO pelo fato de que a chave de sessão é recebidada infra-estrutura móvel criptografada por uma chave compar-tilhada entre o SIM e a infra-estrutura móvel, em que antesde receber a chave de sessão do SIM o método adicionalmentecompreende:enviar a chave criptografada ao SIM para descrip-tografia desta usando a chave compartilhada para fornecer achave de sessão ao computador hospedeiro sem comprometer achave compartilhada.
107. Em uma infra-estrutura móvel amarrada a umarede distribuída em uma rede do contrário insegura indepen-dente da rede de rádio da infra-estrutura móvel, método deestabelecer comunicações seguras de nivel de transporte en-tre um cliente e um servidor em rede insegura estabelecendoum tunelamento seguro entre um módulo móvel conectado aocliente e a infra-estrutura móvel para delegar chaves desessão a um servidor confiado para um ou mais de propósitosde criptografia ou assinatura, CARACTERIZADO pelo fato deque o método compreende:receber uma ou mais credenciais de um módulo móvelconectado a um computador hospedeiro, em que a uma ou maiscredenciais são recebidas em uma rede independente separadade uma rede de rádio correspondente à infra-estrutura móvel;autenticar a uma ou mais credenciais como fazendoparte de uma conta de faturamento válida para o módulo móvel;ecom base na autenticação, enviar uma chave de ses-são a um servidor para uso em uma comunicação segura de ni-vel de transporte na rede independente entre o computadorhospedeiro e o servidor.
108. Método, de acordo com a reivindicação 107,CARACTERIZADO pelo fato de que o módulo móvel é um módulo deidentidade de assinante (SIM) para a infra-estrutura móvel,e em que a uma ou mais credenciais incluem informação combase em um desafio da infra-estrutura móvel e uma chave com-partilhada entre o SIM e a infra-estrutura móvel.
109. Método, de acordo com a reivindicação 108,CARACTERIZADO pelo fato de que a rede independente inclui aInternet.
110. Método, de acordo com a reivindicação 108,CARACTERIZADO pelo fato de que o servidor faz parte de umaestrutura que tem uma relação confiada com a infra-estruturamóvel de modo que as chaves de sessão são adicionalmentepassadas da infra-estrutura móvel ao servidor para a comuni-cação segura de nivel de transporte com o computador hospe-deiro .
111. Método, de acordo com a reivindicação 108,CARACTERIZADO pelo fato de que autenticação do SIM para ainfra-estrutura móvel validando a conta de faturamento destaé usada como verificação de fundos de pagamento disponíveispara serviços, mercadoria, ou ambos, ao fazer uma compra deum comerciante.
112. Método, de acordo com a reivindicação 108,CARACTERIZADO pelo fato de que a chave de sessão expira combase em um ou mais de toda vida da chave de sessão ou váriasmensagens criptografadas, assinadas, ou ambas, com a chavede sessão, sob cuj a expiração o SIM re-autoriza a infra-estrutura móvel para outra comunicação segura entre o compu-tador hospedeiro e o servidor.
113. Método, de acordo com a reivindicação 108,CARACTERIZADO pelo fato de que a chave de sessão é derivadado SIM e da infra-estrutura móvel com base em um segredocompartilhado entre o SIM e a infra-estrutura móvel.
114. Em um computador hospedeiro em um sistema decomputação distribuído, método de estabelecer comunicaçãosegura entre o computador hospedeiro e um servidor usando umprotocolo que autentica um módulo de identidade de assinante(SIM) para uma infra-estrutura móvel em uma conexão de redeindependente de uma rede de rádio associada entre elas,CARACTERIZADO pelo fato de que o método compreende:criar uma solicitação por uma chave de sessão queinclui uma resposta de desafio computada de um módulo de i-dentidade de assinatura (SIM) ligado a um computador hospe-deiro que tenta estabelecer uma comunicação segura com umservidor, em que a resposta de desafio é usada para autenti-car o SIM para uma infra-estrutura móvel que retém informa-ção de estado de faturamento desta;enviar a solicitação por uma chave de sessão parao servidor que . tem uma relação confiada com a infra-estrutura móvel, a solicitação pela chave de sessão enviadaem uma rede independente de uma rede de rádio relacionada àinfra-estrutura móvel;receber uma resposta à solicitação por uma chavede sessão que inclui a chave de sessão e é assinada, cripto-grafada, ou ambos, através de infra-estrutura móvel usandouma chave compartilhada que indica que o SIM apropriadamenteautenticou para a infra-estrutura móvel usando a resposta dedesafio;enviar a chave de sessão ao SIM para validação u-sando a chave compartilhada que estabelece uma comunicaçãoem túnel entre o SIM e a infra-estrutura móvel; esob validação da chave de sessão, permitir o com-putador hospedeiro usar a chave de sessão descriptografada para comunicação segura com o servidor.
115. Método, de acordo com a reivindicação 114,CARACTERIZADO pelo fato de que a resposta para a solicitaçãopela chave de sessão é assinada pelo servidor, a infra-estrutura móvel, ou ambos.
116. Método, de acordo com a reivindicação 114,CARACTERIZADO pelo fato de que a resposta de desafio incluique um Nonce assinou por SIM usando a chave compartilhada demodo que a resposta de desafio é auto gerada pelo SIM.
117. Método, de acordo com a reivindicação 114, CARACTERIZADO pelo fato de que a chave compartilhada é SIM-especifica.
118. Método, de acordo com a reivindicação 114,CARACTERIZADO pelo fato de que a solicitação pela chave desessão é assinada, criptografada, ou ambos, usando um sinal especificado pelo servidor.
119. Método, de acordo com a reivindicação 114,CARACTERIZADO pelo fato de que a solicitação pela chave desessão é assinada, criptografada, ou ambos, usando um sinalespecifico para o computador hospedeiro.
120. Método, de acordo com a reivindicação 114,CARACTERIZADO pelo fato de que antes de enviar a resposta dedesafio, é recebido um desafio que é usado pelo SIM para ge-rar a resposta de desafio.
121. Método, de acordo com a reivindicação 114, aoautenticar o SIM para a infra-estrutura móvel, CARACTERIZADOpelo fato de que o método adicionalmente compreende o se-guinte para autenticar um usuário para a infra-estrutura mó- vel na rede independente:criar uma solicitação por um sinal de usuário usa-do na autenticação de um usuário para um ou mais da infra-estrutura móvel, do servidor, ou outros serviços de terceiro;enviar a solicitação pelo sinal de usuário para o servidor na rede independente da rede de rádio relacionada àinfra-estrutura móvel;receber uma resposta à solicitação por um sinal deusuário que inclui um desafio gerado da infra-estrutura mó-vel ;enviar o desafio ao SIM que indica que o desafiocorresponde a uma autenticação de usuário para incitar o SIMpara requerer uma ou mais credenciais de usuário;receber entrada de usuário que especifica a uma oumais credenciais de usuário que são depois enviadas ao SIM para determinar uma resposta de desafio apropriada;enviar a resposta de desafio que inclui a uma oumais credenciais de usuário ao servidor;receber o sinal de usuário que é assinado, cripto-grafado, ou ambos, usando a chave compartilhada pela infra-estrutura móvel que indica que o usuário apropriadamente au-tenticou-se; eenviar o sinal de usuário ao SIM para validaçãousando a chave compartilhada; esob validação da chave de sessão, permitir o com-putador hospedeiro usar o sinal de usuário em comunicaçãosubseqüente para o servidor ou uns serviços de terceiro paracomunicações seguras entre eles.
122. Método, de acordo com a reivindicação 121,CARACTERIZADO pelo fato de que o sinal de usuário é usadopara requerer uma chave de sessão de serviço que é enviadaao serviço de terceiro, e em que o serviço de terceiro vali-da a chave de sessão de serviço através do servidor.
123. Método, de acordo com a reivindicação 122,CARACTERIZADO pelo fato de que a chave de sessão de serviçoé fornecida pelo servidor em um sinal separado do sinal deusuário sob solicitação do computador hospedeiro e autenti-cação do usuário para o servidor.
124. Em um sistema de operador móvel em um ambien-te de computação distribuido, método de estabelecer comuni-cação segura entre um computador hospedeiro e um servidorusando um protocolo que autentica um módulo de identidade deassinante (SIM) para o sistema de operador móvel em uma co-nexão de rede independente de uma rede de rádio associadaentre si, CARACTERIZADO pelo fato de que o método compreendereceber uma solicitação por uma chave de sessãoque inclui uma resposta de desafio computada de um módulo deidentidade de assinatura (SIM) ligado a um computador hospe-deiro que tenta estabelecer uma comunicação segura com umservidor que tem uma relação confiada com uma infra-estrutura móvel correspondente ao SIM em que a solicitaçãopela chave de sessão enviada em uma rede independente de umarede de rádio relacionada à infra-estrutura móvelusar a resposta de desafio para autenticar o SIMtendo uma conta de faturamento válida com a infra-estruturamóvel;proteger a chave de sessão assinando, criptogra-fando, ou ambos, usando uma chave compartilhada que indicaque o SIM apropriadamente autenticou para a infra-estruturamóvel usando a resposta de desafio;enviar uma resposta à solicitação que inclui achave de sessão para o computador hospedeiro para permitir oSIM anexado validar a chave de sessão usando a chave compar-tilhada que estabelece uma comunicação em túnel entre o SIMe a infra-estrutura móvel; eenviar a chave de sessão ao servidor para estabe-lecer um nivel de rede comunicação segura entre o servidor eo computador hospedeiro.
125. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que a resposta para a solicitaçãopela chave de sessão é assinada pelo servidor, a infra-estrutura móvel, ou ambos.
126. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que a resposta de desafio incluium Nonce assinado pelo SIM usando a chave compartilhada demodo que a resposta de desafio é auto gerada pelo SIM.
127. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que a chave compartilhada é SIM-especifica.
128. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que a solicitação pela chave desessão é assinada, criptografada, ou ambos, usando um sinalespecificado pelo servidor.
129. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que a solicitação pela chave desessão é assinada, criptografada, ou ambos, usando um sinalespecifico para o computador hospedeiro.
130. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que antes de enviar a resposta dedesafio, é recebido um desafio que é usado pelo SIM para ge-rar a resposta de desafio.
131. Método, de acordo com a reivindicação 124,CARACTERIZADO pelo fato de que ao autenticar o SIM para ainfra-estrutura móvel, o método adicionalmente compreende oseguinte para autenticar um usuário para infra-estrutura mó-vel na rede independente:receber uma solicitação por um sinal de usuáriousado na autenticação de um usuário para a infra-estruturamóvel, a solicitação pelo sinal de usuário recebido na redeindependente da rede de rádio;enviar um desafio gerado da infra-estrutura móvelpara requerer o SIM para obter uma ou mais credenciais deusuário;receber uma resposta de desafio que inclui a umaou mais credenciais de usuário;com base na validação da uma ou mais credenciaisde usuário, proteger um sinal de usuário assinando, cripto-grafando, ou ambos, usando a chave compartilhada que indicaque o usuário apropriadamente autenticou-se para a infra-estrutura móvel; eenviar o sinal de usuário ao SIM para validaçãousando a chave compartilhada para permitir o computador hos-pedeiro usar o sinal de usuário em comunicação subseqüentepara o servidor ou uns serviços de terceiro para comunica-ções seguras entre eles.
132. Em um dispositivo de computação de consumidorem um sistema distribuído, método de prover uma transaçãocomercial segura para compra em-linha de serviços, mercado-ria, ou ambos, estabelecendo uma permuta de dados de trêsmodos entre os dispositivos de computação para um consumidor,comerciante, e provedor de pagamento, CARACTERIZADO pelo fa-to de que o método compreende:enviar uma solicitação em-linha para comprar um oumais serviços, mercadoria, ou ambos, oferecidos por um co-merciante;receber a informação de faturamento do comercianteque inclui um custo associado à compra do um ou mais servi-ços , mercadoria, ou ambos;enviar uma solicitação para autorização de paga-mento para o custo de um dispositivo de computação de consu-midor para pelo menos um provedor de pagamento, em que oconsumidor tem uma conta de faturamento com o pelo menos umprovedor de pagamento;receber do pelo menos um provedor de pagamento umsinal de pagamento como prova de uma habilidade para o con-sumidor pagar pelo menos uma porção do um ou mais serviços,mercadoria, ou ambos, em que o sinal de pagamento identificaa autorização de pagamento exclusivamente para pelo menosuma porção do custo sem prover informação sensivel acerca daconta de faturamento para o consumidor;enviar o sinal de pagamento do dispositivo de com-putação de consumidor para o comerciante, em que o comerci-ante usa o sinal de pagamento para validar pagamento com oprovedor de pagamento que torna a informação sensivel acercada conta de faturamento opaca para o comerciante enquantoainda provendo validação de pagamento segura; ereceber reconhecimento da validez do sinal de pa-gamento que indica transferência apropriada do um ou maisserviços, mercadoria, ou ambos, do comerciante para o consu-midor.
133. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que a informação de faturamentoadicionalmente inclui uma ou mais de uma descrição dos ser-viços, mercadoria, ou ambos, opções de pagamento disponíveisdo comerciante, ou informação especifica para o comerciante.
134. Método, de acordo com a reivindicação 133,CARACTERIZADO pelo fato de que a informação de faturamento éapresentada ao pelo menos um provedor de pagamento ao reque-rer o pagamento autorizando pelos serviços, mercadoria, ouambos.
135. Método, de acordo com a reivindicação 134,CARACTERIZADO pelo fato de que o sinal de pagamento inclui ainformação de faturamento que é depois assinada, criptogra-fada, ou ambos, por pelo menos um provedor de pagamento paravalidar o sinal de pagamento e para equiparar o sinal de pa-gamento à solicitação para autorização de pagamento do con-sumidor .
136. Método, de acordo com a reivindicação 135,CARACTERIZADO pelo fato de que a solicitação para autoriza-ção de pagamento, a apresentação da informação de faturamen-to ao pelo menos um provedor de pagamento, e o envio do si-nal de pagamento ao comerciante ocorrem automaticamente seminteração do consumidor.
137. Método, de acordo com a reivindicação 133,CARACTERIZADO pelo fato de que com base nas opções de paga-mento disponíveis fornecidas pelo comerciante o método adi-cionalmente inclui:apresentar ao consumidor uma interface do usuárioque mostra uma ou mais das opções de pagamento disponíveis;receber entrada de usuário do consumidor que sele-ciona o pelo menos um provedor de pagamento; ecom base na entrada de usuário, estabelecer um ca-nal de comunicação entre o dispositivo de computação de con-sumidor e o pelo menos um provedor de pagamento para reque-rer a autorização de pagamento.
138 . Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o pelo menos um provedor depagamento é escolhido com base em provedor de pagamento pre-definido prefixado pelo consumidor.
139. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o pelo menos um provedor depagamento é um de uma infra-estrutura móvel que tem informa-ção de conta de faturamento para um dispositivo de SIM pos-suído pelo consumidor, uma companhia de cartão de créditopara o consumidor, um serviço pré-pago para o consumidor, ouuma conta bancária para o consumidor.
140. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que a transação comercial é umaexperiência de dentro-da-banda ininterrupta em que o paga-mento e seleção do serviço, mercadoria, ou ambos, são inte-grados em uma aplicação simples que não faz parte de um na- vegador de rede.
141. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o sinal de pagamento expiraapós algum periodo de tempo predeterminado, freqüência deuso, ou ambos, ajustados por pelo menos um provedor de paga- mento.
142. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o custo é variável e apresen-tado na informação de faturamento como uma faixa de valores.
143. Método, de acordo com a reivindicação 132, CARACTERIZADO pelo fato de que o sinal de pagamento é revo-cável pelo consumidor, o pelo menos um provedor de pagamento,ou ambos.
144. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o custo está acima de umaquantidade predeterminada permitida por pelo menos um prove-dor de pagamento, e em que interação de usuário adicional énecessária para autorização do sinal de pagamento.
145. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o sinal de pagamento é assi-nado, criptografado, ou ambos, por pelo menos um provedor depagamento, e em que a validação do sinal de pagamento porpelo menos um provedor de pagamento inclui validação da as- sinatura, a criptografia, ou ambas.
146. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o um ou mais serviços, merca-doria, ou ambos, requerem assinatura ou pagamentos múltiplos,e em que o sinal de pagamento pode ser usado múltiplas vezes para tal pagamento.
147. Método, de acordo com a reivindicação 132,CARACTERIZADO pelo fato de que o um ou mais serviços, merca-doria, ou ambos, requerem assinatura ou pagamentos múltiplos,e em que o sinal de pagamento é válido para apenas um paga- mento único da assinatura ou pagamentos múltiplos, e em queos sinais adicionais são necessários para pagamentos subse-qüentes .
148. Em um dispositivo de computação comercianteem um sistema distribuído, método de executar uma transação comercial segura ao permitir uma compra de serviços, merca-doria, ou ambos, estabelecendo uma permuta de dados de trêsmodos entre os dispositivos de computação para um consumidor,comerciante, e provedor de pagamento, CARACTERIZADO pelo fa-to de que o método compreende: receber uma solicitação em-linha para comprar umou mais serviços, mercadoria, ou ambos, oferecidos por umcomerciante;enviar a informação de faturamento a um consumidorque inclui um custo associado à compra do um ou mais servi-ços, mercadoria, ou ambos;receber um sinal de pagamento do consumidor comouma oferta de prova de uma habilidade para o consumidor pa-gar pelo menos uma porção do um ou mais serviços, mercadoria,ou ambos, em que o sinal de pagamento identifica uma autori-zação de pagamento exclusivamente para um provedor de paga-mento para o pelo menos uma porção do custo sem prover in-formação sensivel acerca de uma conta de faturamento do con-sumidor para o provedor de pagamento;enviar uma solicitação para validação do sinal depagamento para o provedor de pagamento, desse modo permitin-do o comerciante validar pagamento com segurança de pelo me-nos uma porção do custo tornando a informação sensivel acer-ca da conta de faturamento opaca para o comerciante; ecom base na validação do sinal de pagamento, envi-ar um reconhecimento da vaiidez do sinal de pagamento indi-cando transferência apropriada do um ou mais serviços, mer-cadoria, ou ambos, do comerciante para o consumidor.
149. Método, de acordo com a reivindicação 148,CARACTERIZADO pelo fato de que a informação de faturamentoadicionalmente inclui um ou mais de uma descrição dos servi-ços, mercadoria, ou ambos, opções de pagamento disponíveisdo comerciante, ou informação especifica para o comerciante.
150. Método, de acordo com a reivindicação 149,CARACTERIZADO pelo fato de que o sinal de pagamento inclui ainformação de faturamento que é assinada criptografada, ouambos, por pelo menos um provedor de pagamento para validaro sinal de pagamento e para equiparar o sinal de pagamento auma solicitação para autorização de pagamento do consumidor.
151. Método, de acordo com a reivindicação 148,CARACTERIZADO pelo fato de que o sinal de pagamento expira após algum periodo de tempo predeterminado, freqüência deuso, ou ambos, ajustados pelo provedor de pagamento.
152. Método, de acordo com a reivindicação 148,CARACTERIZADO pelo fato de que pelo menos uma porção do cus-to é variável e apresentada na informação de faturamento co- mo uma faixa de valores.
153. Método, de acordo com a reivindicação 14 8,CARACTERIZADO pelo fato de que o sinal de pagamento é revo-cável pelo consumidor, o provedor de pagamento, ou ambos.
154. Método, de acordo com a reivindicação 148, CARACTERIZADO pelo fato de que o custo está acima de umaquantidade predeterminada possibilitada pelo provedor de pa-gamento, e em que interação de usuário adicional é necessá-ria para autorização do sinal de pagamento.
155. Método, de acordo com a reivindicação 148, CARACTERIZADO pelo fato de que o um ou mais serviços, merca-doria, ou ambos, requerem assinatura ou pagamentos múltiplos,e em que o sinal de pagamento pode ser usado múltiplas vezespor tal pagamento.
156. Em um dispositivo de computação de provedor de pagamento em um sistema distribuído, método de autorizarpagamento em uma transação comercial para uma compra de ser-viços , mercadoria, ou ambos, estabelecendo uma permuta dedados de três modos entre os dispositivos de computação paraum consumidor, comerciante, e provedor de pagamento,CARACTERIZADO pelo fato de que o método compreende:receber uma solicitação para autorização de paga-mento de um consumidor que compra um ou mais serviços, mer- cadoria, ou ambos, de um comerciante, em que a solicitaçãopara autorização de pagamento inclui informação de fatura-mento para um custo associado à compra;com base em um estado da conta de faturamento parao consumidor, enviar um sinal de pagamento ao consumidor co- mo prova de uma habilidade para o consumidor pagar pelo umou mais serviços, mercadoria, ou ambos, em que o sinal depagamento identifica a autorização de pagamento exclusiva-mente para o um ou mais serviços, mercadoria, ou ambos, semprover informação sensivel acerca da conta de faturamento ao consumidor;receber do comerciante uma solicitação para vali-dar o sinal de pagamento; ecom base na comparação do sinal de pagamento com ainformação de faturamento da solicitação para autorização de pagamento, enviar um reconhecimento da validez do sinal depagamento que indica que o pagamento será fornecido ao co-merciante sob transferência apropriada do um ou mais servi-ços, mercadoria, ou ambos, para o consumidor.
157. Método, de acordo com a reivindicação 156, CARACTERIZADO pelo fato de que a informação de faturamentoadicionalmente inclui um ou mais de uma descrição dos servi-ços, mercadoria, ou ambos, opções de pagamento disponíveisdo comerciante, ou informação especifica comerciante.
158. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o pelo menos um provedor depagamento é um de uma infra-estrutura móvel que tem informa-ção de conta de faturamento para um dispositivo de SIM pos- suido pelo consumidor, uma companhia de cartão de créditopara o consumidor, um serviço pré-pago para o consumidor, ouuma conta bancária para o consumidor.
159. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o sinal de pagamento expira após algum periodo de tempo predeterminado, freqüência deuso, ou ambos, ajustados pelo provedor de pagamento.
160. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o custo é variável e apresen-tado na informação de faturamento como uma faixa de valores.
161. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o sinal de pagamento é revo-ca vel pelo consumidor, provedor de pagamento, ou ambos.
162. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o custo está acima de uma quantidade predeterminada possibilitada pelo provedor de pa-gamento, e em que a interação de usuário adicional é neces-sária para autorização do sinal de pagamento.
163. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o sinal de pagamento é assi-nado, criptografado, ou ambos, pelo provedor de pagamento, eem que a validação do sinal de pagamento para o provedor depagamento inclui validar a assinatura, a criptografia, ouambas.
164. Método, de acordo com a reivindicação 15 6,CARACTERIZADO pelo fato de que o um ou mais serviços, merca-doria, ou ambos, requerem assinatura ou múltiplos pagamentose em que o sinal de pagamento pode ser usado múltiplas vezespor tal pagamento.
165. Método, de acordo com a reivindicação 156,CARACTERIZADO pelo fato de que o um ou mais serviços, merca-doria, ou ambos, requerem assinatura ou pagamentos múltiplose em que o sinal de pagamento é válido para apenas um paga-mento simples da assinatura ou pagamentos múltiplos, e emque sinais adicionais são necessários para pagamentos subse-qüentes .
166. Em um sistema de computação distribuído paraexecutar uma transação comercial em-linha, método de fazerautorização de pagamento com base em uma apresentação deconta eletrônica para manter um registro da transação em-linha para auditoria, proteção de fraude, e outros propósi-tos, CARACTERIZADO pelo fato de que o método compreende:receber em um dispositivo de computação de consu-midor uma conta eletrônica que inclui uma descrição e custoupara comprar um ou mais serviços, mercadoria, ou ambos, decomerciante durante uma transação comercial em-linha deste;eenviar uma cópia da conta eletrônica a um provedorde pagamento para autorizar pagamento do um ou mais serviçosmercadoria, ou ambos.
167. Método, de acordo com a reivindicação 166,CARACTERIZADO pelo fato de que uma ou mais porções da contaeletrônica são criptografadas pelo comerciante para tornar aum ou mais porções opaca para o consumidor, provedor de pa-gamento, ou ambos.
168. Método, de acordo com a reivindicação 167,CARACTERIZADO pelo fato de que a uma ou mais porções da con-ta eletrônica que é criptografada são usadas para federaçãode pagamento automática para um ou mais sócios empresariaisdo comerciante.
169. Método, de acordo com a reivindicação 166,CARACTERIZADO pelo fato de que adicionalmente compreende:armazenar uma cópia da conta eletrônica no dispo-sitivo de computação de consumidor;receber uma solicitação de pagamento do provedorde pagamento para encargos correspondendo ao pagamento aocomerciante, em que a solicitação de pagamento inclui umacópia da conta eletrônica do comerciante; ecomparar a cópia armazenada da conta eletrônicacom a cópia recebida do provedor de pagamento para examinaro pagamento apropriado feito ao comerciante.
170. Método, de acordo com a reivindicação 166, emque uma cópia da conta eletrônica é assinada pelo comercian-te, CARACTERIZADO pelo fato de que o método adicionalmentecompreende:receber do provedor de pagamento um sinal de paga-mento para autorizar o pagamento do um ou mais serviços,mercadoria, ou ambos, em que o sinal inclui a cópia assinadada conta eletrônica; eenviar o sinal de pagamento ao comerciante paraautorização de pagamento, em que o comerciante pode validaro sinal de pagamento como vindo do consumidor com base nacópia assinada da conta eletrônica.
171. Em um sistema de computação distribuído paraexecutar uma transação comercial em-linha, método de autori-zar pagamento para serviços, mercadoria, ou ambos, de comer-ciante com base em uma apresentação de conta eletrônica paramanter um registro da transação em-linha para auditoria,proteção de fraude, e outros propósitos, CARACTERIZADO pelofato de que o método compreende:receber em um provedor de pagamento uma conta ele-trônica que inclui uma descrição e custo para comprar de umou mais serviços, mercadoria, ou ambos, por um dispositivode computação de consumidor durante uma transação comercialem-linha; eenviar um sinal de pagamento ao consumidor que in-clui uma cópia de pelo menos uma porção da conta eletrônicapara autorizar pagamento do um ou mais serviços, mercadoria,ou ambos, de um comerciante.
172. Método, de acordo com a reivindicação 171,CARACTERIZADO pelo fato de que uma ou mais porções da contaeletrônica são criptografadas pelo comerciante para tornar aum ou mais porções opacas para o consumidor, provedor de pa-gamento, ou ambos.
173. Método, de acordo com a reivindicação 172,CARACTERIZADO pelo fato de que a uma ou mais porções da con-ta eletrônica que são criptografadas são usadas para federa-ção de pagamento automática para um ou mais sócios empresa-riais do comerciante.
174. Método, de acordo com a reivindicação 171,CARACTERIZADO pelo fato de que adicionalmente compreende:armazenar uma cópia da conta eletrônica no dispo-sitivo de computação de provedor de pagamento;receber uma solicitação de pagamento do comercian-te para pagamento de encargos correspondentes ao um ou maisserviços, mercadoria, ou ambos, em que a solicitação de pa-gamento inclui uma cópia de pelo menos uma porção da contaeletrônica do comerciante; ecomparar a cópia armazenada da conta eletrônicacom a cópia de pelo menos uma porção da conta eletrônica re-cebida do comerciante para autorizar pagamento apropriado aeste.
175. Método, de acordo com a reivindicação 171, emque uma cópia da conta eletrônica é assinada pelo comercian-te, CARACTERIZADO pelo fato de que o método adicionalmentecompreende:enviar um sinal de pagamento ao consumidor que in-clui a cópia assinada da conta eletrônica que o comerciantepode usar para validar que o sinal de pagamento faz parte deuma transação comercial que origina entre o comerciante econsumidor;receber do comerciante uma solicitação para auto-rizar o sinal de pagamento para o um ou mais serviços, mer-cadoria, ou ambos; eenviar o um reconhecimento da validez do sinal depagamento para o comerciante para permitir o comerciantetransferir o um ou mais serviços, mercadoria, ou ambos aoconsumidor.
176. Em um sistema de computação distribuído paraexecutar uma transação comercial em-linha, método de validarautorização de pagamento com base em uma apresentação deconta eletrônica para manter um registro da transação em-linha para auditoria, proteção de fraude, e outros propósi-tos, CARACTERIZADO pelo fato de que o método compreende:enviar a um dispositivo de computação de consumi- dor uma conta eletrônica que inclui uma descrição e custopara comprar de um ou mais serviços, mercadoria, ou ambos,de comerciante durante uma transação comercial em-linha des-te ; e receber um sinal de pagamento que inclui pelo menosuma porção da conta eletrônica para validar que o sinal de pagamento faz parte de uma transação comercial que originaentre o comerciante e o consumidor.
177. Método, de acordo com a reivindicação 176,CARACTERIZADO pelo fato de que uma ou mais porções da contaeletrônica são criptografadas pelo comerciante para tornar a uma ou mais porções opacas para o consumidor, o provedor depagamento, ou ambos.
178. Método, de acordo com a reivindicação 177,CARACTERIZADO pelo fato de que a uma ou mais porções da con-ta eletrônica que são criptografadas são usadas para federa- ção de pagamento automática para um ou mais sócios empresa-riais do comerciante.
179. Método, de acordo com a reivindicação 176CARACTERIZADO pelo fato de que adicionalmente compreende:enviar o sinal de pagamento a um provedor de paga-mento para autorizar o pagamento do um ou mais serviços,mercadoria, ou ambos, em que o sinal inclui a cópia assinadada conta eletrônica;receber validação do sinal de pagamento do prove-dor de serviços que indica a habilidade do consumidor pagarpelo um ou mais serviços, mercadoria, ou ambos; ecom base na autorização, enviar o um ou mais ser-viços, mercadoria, ou ambos, para o consumidor concluir atransação comercial.
180. Em um sistema distribuído, método de distri-buição de pagamento automático para uma série de sócios em-presariais com uma relação empresarial predefinida com baseem um pagamento simples de um consumidor por uma transaçãocomercial em-linha, CARACTERIZADO pelo fato de que o métodocompreende:receber um pagamento em-linha simples para servi-ços, mercadoria, ou ambos, oferecidos por um comerciante quetem uma relação empresarial contratual com pelo menos um ou-tro negócio associado que ajuda fornecer pelo menos uma por-ção dos serviços, mercadoria, ou ambos;com base na relação contratual definida, identifi-car uma porção do pagamento em-linha simples como pertencen-do o pelo menos um associado empresarial; eautomaticamente transferir a porção do pagamentopara uma conta para o pelo menos um associado empresarialpara federar pagamento ao comerciante e pelo menos um asso-ciado empresarial com base em uma relação confiada e politi-ca associada entre eles.
181. Método, de acordo com a reivindicação 180,CARACTERIZADO pelo fato de que a porção é adicionalmente i-dentificada com base em umas porções designadas dentro dainformação de conta gerada pelo comerciante que é apresenta-da a um consumidor que autorizou o pagamento simples.
182. Método, de acordo com a reivindicação 181,CARACTERIZADO pelo fato de que a porção é assinada pelo co-merciante para tornar a federação de pagamento transparentepara o consumidor.
183. Em um sistema em-linha distribuído para exe-cutar uma transação comercial, método de apresentar a umconsumidor opções de pagamento com base em análise de umaconta eletrônica e políticas ou regras definidas pelo comer-ciante, consumidor, ou ambos, CARACTERIZADO pelo fato de queo método compreende:receber em um dispositivo de consumidor uma contaeletrônica que inclui informação acerca de uma solicitaçãode compra para mercadoria, serviços, ou ambos, de um comer-ciante;comparar a informação de dentro da conta eletrôni-ca com uma ou mais rege predefinidas do consumidor, comerci-ante, ou ambos; ecom base na comparação, determinar uma ação apro-priada que satisfaz os requerimentos da um ou mais regraspredefinidas.
184. Método, de acordo com a reivindicação 183,CARACTERIZADO pelo fato de que a uma ou mais regras predefi-nidas são uma lista de tipo disponivel de opções de pagamen-to para o comerciante, consumidor, ou ambos, e em que a açãoescolhe da lista uma ou mais opções de pagamentos para apre-sentação a um usuário.
185. Método, de acordo com a reivindicação 184,CARACTERIZADO pelo fato de que a uma ou mais regras predefi-nidas limitam o tipo de pagamento com base em uma relação deconfiança com o comerciante e a informação dentro da contaeletrônica identifica a relação de confiança com base em umaassinatura, criptografia, ou ambas do comerciante.
186. Método, de acordo com a reivindicação 184,CARACTERIZADO pelo fato de que a uma ou mais regras predefi-nidas limitam o tipo de pagamento com base nos tipos de pa-gamento disponíveis para o consumidor comparados com o tipode pagamentos concordado pelo comerciante.
187. Método, de acordo com a reivindicação 184,CARACTERIZADO pelo fato de que a uma ou mais regras predefi-nidas limitam o tipo de pagamento com base no custo total doum ou mais serviços, mercadoria, ou ambos.
188. Método, de acordo com a reivindicação 184,CARACTERIZADO pelo fato de que a informação dentro da contaeletrônica adicionalmente inclui regras para o comerciantetal que as regras para o comerciante são comparadas com asregras para o consumidor.
189. Método, de acordo com a reivindicação 188,CARACTERIZADO pelo fato de que quaisquer conflitos entre asregras para o comerciante e as regras para o consumidor sãoresolvidas a favor do comerciante, ou a transação comercialé cancelada.
190. Método, de acordo com a reivindicação 184,CARACTERIZADO pelo fato de que a transação comercial é umaassinatura tipo pagar quando incorrer, e onde as uma ou mais regras limitam a duração da assinatura com base em uma quan-tidade de pagamento, período de tempo ou ambos.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US67275405P | 2005-04-19 | 2005-04-19 | |
| US11/376,535 US7849020B2 (en) | 2005-04-19 | 2006-03-15 | Method and apparatus for network transactions |
| US11/379,133 US20060235795A1 (en) | 2005-04-19 | 2006-04-18 | Secure network commercial transactions |
| US11/379,143 US8996423B2 (en) | 2005-04-19 | 2006-04-18 | Authentication for a commercial transaction using a mobile module |
| PCT/US2006/014801 WO2006113834A2 (en) | 2005-04-19 | 2006-04-19 | Network commercial transactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BRPI0608591A2 true BRPI0608591A2 (pt) | 2010-01-19 |
Family
ID=37115927
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BRPI0608591-1A BRPI0608591A2 (pt) | 2005-04-19 | 2006-04-19 | transaÇÕes comerciais em rede |
Country Status (12)
| Country | Link |
|---|---|
| EP (1) | EP1872188A4 (pt) |
| JP (1) | JP2008541206A (pt) |
| KR (1) | KR20070120125A (pt) |
| CN (1) | CN102368325A (pt) |
| AU (1) | AU2006236243B2 (pt) |
| BR (1) | BRPI0608591A2 (pt) |
| CA (1) | CA2601785A1 (pt) |
| IL (1) | IL185978A0 (pt) |
| MX (1) | MX2007012648A (pt) |
| NO (1) | NO20074614L (pt) |
| SG (1) | SG161290A1 (pt) |
| WO (1) | WO2006113834A2 (pt) |
Families Citing this family (186)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8762263B2 (en) | 2005-09-06 | 2014-06-24 | Visa U.S.A. Inc. | System and method for secured account numbers in proximity devices |
| US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
| US8121942B2 (en) | 2007-06-25 | 2012-02-21 | Visa U.S.A. Inc. | Systems and methods for secure and transparent cardless transactions |
| US7937324B2 (en) | 2007-09-13 | 2011-05-03 | Visa U.S.A. Inc. | Account permanence |
| CN107066862B (zh) | 2007-09-24 | 2022-11-25 | 苹果公司 | 电子设备中的嵌入式验证系统 |
| DE102007048044A1 (de) * | 2007-10-05 | 2009-04-09 | T-Mobile International Ag | Contentdistribution mit inhärenter nutzerorientierter Berechtigungsprüfung |
| US8600120B2 (en) | 2008-01-03 | 2013-12-03 | Apple Inc. | Personal computing device control using face detection and recognition |
| US9015074B2 (en) | 2008-02-01 | 2015-04-21 | Mazooma Technical Services, Inc. | Device and method for facilitating financial transactions |
| US7720764B2 (en) * | 2008-02-01 | 2010-05-18 | Kenneth James Emerson | Method, device, and system for completing on-line financial transaction |
| US8620826B2 (en) | 2008-03-27 | 2013-12-31 | Amazon Technologies, Inc. | System and method for receiving requests for tasks from unregistered devices |
| US20090307140A1 (en) | 2008-06-06 | 2009-12-10 | Upendra Mardikar | Mobile device over-the-air (ota) registration and point-of-sale (pos) payment |
| US8219489B2 (en) | 2008-07-29 | 2012-07-10 | Visa U.S.A. Inc. | Transaction processing using a global unique identifier |
| BRPI0921124A2 (pt) | 2008-11-06 | 2016-09-13 | Visa Int Service Ass | sistema para autenticar um consumidor, método implementado por computador, meio legível por computador, e, computador servidor. |
| US9715681B2 (en) | 2009-04-28 | 2017-07-25 | Visa International Service Association | Verification of portable consumer devices |
| US7891560B2 (en) | 2009-05-15 | 2011-02-22 | Visa International Service Assocation | Verification of portable consumer devices |
| US10846683B2 (en) | 2009-05-15 | 2020-11-24 | Visa International Service Association | Integration of verification tokens with mobile communication devices |
| US9105027B2 (en) | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
| US9038886B2 (en) | 2009-05-15 | 2015-05-26 | Visa International Service Association | Verification of portable consumer devices |
| US8534564B2 (en) | 2009-05-15 | 2013-09-17 | Ayman Hammad | Integration of verification tokens with mobile communication devices |
| US8602293B2 (en) | 2009-05-15 | 2013-12-10 | Visa International Service Association | Integration of verification tokens with portable computing devices |
| US8893967B2 (en) | 2009-05-15 | 2014-11-25 | Visa International Service Association | Secure Communication of payment information to merchants using a verification token |
| US10140598B2 (en) | 2009-05-20 | 2018-11-27 | Visa International Service Association | Device including encrypted data for expiration date and verification value creation |
| JP5418025B2 (ja) | 2009-07-08 | 2014-02-19 | 株式会社リコー | 情報処理装置、システム管理方法、システム管理プログラム、及びそのプログラムを記録した記録媒体 |
| US10255591B2 (en) | 2009-12-18 | 2019-04-09 | Visa International Service Association | Payment channel returning limited use proxy dynamic value |
| BR112012017000A2 (pt) | 2010-01-12 | 2016-04-05 | Visa Int Service Ass | método |
| US10255601B2 (en) | 2010-02-25 | 2019-04-09 | Visa International Service Association | Multifactor authentication using a directory server |
| US9245267B2 (en) | 2010-03-03 | 2016-01-26 | Visa International Service Association | Portable account number for consumer payment account |
| US9342832B2 (en) | 2010-08-12 | 2016-05-17 | Visa International Service Association | Securing external systems with account token substitution |
| US20120089450A1 (en) * | 2010-10-07 | 2012-04-12 | Microsoft Corporation | Loyalty offer |
| US9525548B2 (en) | 2010-10-21 | 2016-12-20 | Microsoft Technology Licensing, Llc | Provisioning techniques |
| US8805434B2 (en) | 2010-11-23 | 2014-08-12 | Microsoft Corporation | Access techniques using a mobile communication device |
| US9509686B2 (en) | 2010-12-03 | 2016-11-29 | Microsoft Technology Licensing, Llc | Secure element authentication |
| AU2012217606A1 (en) | 2011-02-16 | 2013-05-09 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
| US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
| WO2012116125A1 (en) | 2011-02-22 | 2012-08-30 | Visa International Service Association | Universal electronic payment apparatuses, methods and systems |
| AU2012225684B2 (en) | 2011-03-04 | 2016-11-10 | Visa International Service Association | Integration of payment capability into secure elements of computers |
| BG66795B1 (bg) * | 2011-04-11 | 2018-12-17 | Николаев Попов Красимир | Метод и система за реализиране на комплексни задачи, остойностяване и разплащане, осъществявани в обща компютърно базирана среда |
| US9280765B2 (en) | 2011-04-11 | 2016-03-08 | Visa International Service Association | Multiple tokenization for authentication |
| US8880040B2 (en) | 2011-05-23 | 2014-11-04 | Microsoft Corporation | Mobile network operator identification |
| US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
| US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
| AU2012278963B2 (en) | 2011-07-05 | 2017-02-23 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
| WO2013019567A2 (en) | 2011-07-29 | 2013-02-07 | Visa International Service Association | Passing payment tokens through an hop/sop |
| US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
| US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
| US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
| WO2013029014A2 (en) | 2011-08-24 | 2013-02-28 | Visa International Service Association | Method for using barcodes and mobile devices to conduct payment transactions |
| US8862767B2 (en) | 2011-09-02 | 2014-10-14 | Ebay Inc. | Secure elements broker (SEB) for application communication channel selector optimization |
| US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
| US9002322B2 (en) | 2011-09-29 | 2015-04-07 | Apple Inc. | Authentication with secondary approver |
| US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
| SG11201403861XA (en) | 2012-01-05 | 2014-08-28 | Visa Int Service Ass | Data protection with translation |
| US9830595B2 (en) | 2012-01-26 | 2017-11-28 | Visa International Service Association | System and method of providing tokenization as a service |
| AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
| US10282724B2 (en) | 2012-03-06 | 2019-05-07 | Visa International Service Association | Security system incorporating mobile device |
| CN102646252A (zh) * | 2012-03-19 | 2012-08-22 | 重庆先迈通信技术有限公司 | 一种议价交易业务的业务服务器系统及业务处理方法 |
| US20130297501A1 (en) | 2012-05-04 | 2013-11-07 | Justin Monk | System and method for local data conversion |
| US9524501B2 (en) | 2012-06-06 | 2016-12-20 | Visa International Service Association | Method and system for correlating diverse transaction data |
| US9547769B2 (en) | 2012-07-03 | 2017-01-17 | Visa International Service Association | Data protection hub |
| US9846861B2 (en) | 2012-07-25 | 2017-12-19 | Visa International Service Association | Upstream and downstream data conversion |
| US9256871B2 (en) | 2012-07-26 | 2016-02-09 | Visa U.S.A. Inc. | Configurable payment tokens |
| US9665722B2 (en) | 2012-08-10 | 2017-05-30 | Visa International Service Association | Privacy firewall |
| US20140067689A1 (en) * | 2012-08-31 | 2014-03-06 | Ncr Corporation | Security module and method of securing payment information |
| US10192216B2 (en) | 2012-09-11 | 2019-01-29 | Visa International Service Association | Cloud-based virtual wallet NFC apparatuses, methods and systems |
| US8959032B2 (en) | 2012-10-10 | 2015-02-17 | Quisk, Inc. | Self-authenticating peer to peer transaction |
| US10176478B2 (en) | 2012-10-23 | 2019-01-08 | Visa International Service Association | Transaction initiation determination system utilizing transaction data elements |
| US9911118B2 (en) | 2012-11-21 | 2018-03-06 | Visa International Service Association | Device pairing via trusted intermediary |
| US10304047B2 (en) | 2012-12-07 | 2019-05-28 | Visa International Service Association | Token generating component |
| US10740731B2 (en) | 2013-01-02 | 2020-08-11 | Visa International Service Association | Third party settlement |
| US9741051B2 (en) | 2013-01-02 | 2017-08-22 | Visa International Service Association | Tokenization and third-party interaction |
| CA2900605C (en) * | 2013-02-26 | 2020-06-02 | Cornelius Johannes Badenhorst | Methods and systems for providing payment credentials |
| US20140258123A1 (en) * | 2013-03-05 | 2014-09-11 | Quisk, Inc. | Tokenized Payment Service Registration |
| WO2014143776A2 (en) | 2013-03-15 | 2014-09-18 | Bodhi Technology Ventures Llc | Providing remote interactions with host device using a wireless device |
| GB2512080A (en) | 2013-03-19 | 2014-09-24 | Visa Europe Ltd | A method and system for transferring data |
| US11055710B2 (en) | 2013-05-02 | 2021-07-06 | Visa International Service Association | Systems and methods for verifying and processing transactions using virtual currency |
| CN104144146B (zh) * | 2013-05-10 | 2017-11-03 | 中国电信股份有限公司 | 一种访问网站的方法和系统 |
| CN105359179B (zh) | 2013-05-15 | 2019-12-10 | 维萨国际服务协会 | 移动令牌化枢纽 |
| US10878422B2 (en) | 2013-06-17 | 2020-12-29 | Visa International Service Association | System and method using merchant token |
| SG10201800629WA (en) | 2013-07-24 | 2018-02-27 | Visa Int Service Ass | Systems and methods for communicating risk using token assurance data |
| CN115907763A (zh) | 2013-07-26 | 2023-04-04 | 维萨国际服务协会 | 向消费者提供支付凭证 |
| US10496986B2 (en) | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
| CA2920661C (en) | 2013-08-08 | 2019-05-21 | Visa International Service Association | Methods and systems for provisioning mobile devices with payment credentials |
| US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US9978094B2 (en) | 2013-10-11 | 2018-05-22 | Visa International Service Association | Tokenization revocation list |
| EP3937108A1 (en) | 2013-10-11 | 2022-01-12 | Visa International Service Association | Network token system |
| US11574299B2 (en) | 2013-10-14 | 2023-02-07 | Equifax Inc. | Providing identification information during an interaction with an interactive computing environment |
| US10115102B2 (en) | 2013-10-14 | 2018-10-30 | Equifax Inc. | Providing identification information to mobile commerce applications |
| US10515358B2 (en) | 2013-10-18 | 2019-12-24 | Visa International Service Association | Contextual transaction token methods and systems |
| US10489779B2 (en) | 2013-10-21 | 2019-11-26 | Visa International Service Association | Multi-network token bin routing with defined verification parameters |
| US10366387B2 (en) | 2013-10-29 | 2019-07-30 | Visa International Service Association | Digital wallet system and method |
| US9516487B2 (en) | 2013-11-19 | 2016-12-06 | Visa International Service Association | Automated account provisioning |
| US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
| SG11201604906QA (en) | 2013-12-19 | 2016-07-28 | Visa Int Service Ass | Cloud-based transactions methods and systems |
| US10433128B2 (en) | 2014-01-07 | 2019-10-01 | Visa International Service Association | Methods and systems for provisioning multiple devices |
| US9846878B2 (en) | 2014-01-14 | 2017-12-19 | Visa International Service Association | Payment account identifier system |
| US10026087B2 (en) | 2014-04-08 | 2018-07-17 | Visa International Service Association | Data passed in an interaction |
| US9942043B2 (en) | 2014-04-23 | 2018-04-10 | Visa International Service Association | Token security on a communication device |
| WO2015168334A1 (en) | 2014-05-01 | 2015-11-05 | Visa International Service Association | Data verification using access device |
| US9848052B2 (en) | 2014-05-05 | 2017-12-19 | Visa International Service Association | System and method for token domain control |
| CN106465112A (zh) | 2014-05-21 | 2017-02-22 | 维萨国际服务协会 | 离线认证 |
| US10043185B2 (en) | 2014-05-29 | 2018-08-07 | Apple Inc. | User interface for payments |
| US11256294B2 (en) | 2014-05-30 | 2022-02-22 | Apple Inc. | Continuity of applications across devices |
| US11023890B2 (en) | 2014-06-05 | 2021-06-01 | Visa International Service Association | Identification and verification for provisioning mobile application |
| US20150379505A1 (en) * | 2014-06-30 | 2015-12-31 | Intuit Inc. | Using limited life tokens to ensure pci compliance |
| US9780953B2 (en) | 2014-07-23 | 2017-10-03 | Visa International Service Association | Systems and methods for secure detokenization |
| US10484345B2 (en) | 2014-07-31 | 2019-11-19 | Visa International Service Association | System and method for identity verification across mobile applications |
| US10339293B2 (en) | 2014-08-15 | 2019-07-02 | Apple Inc. | Authenticated device used to unlock another device |
| US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
| US10140615B2 (en) | 2014-09-22 | 2018-11-27 | Visa International Service Association | Secure mobile device credential provisioning using risk decision non-overrides |
| CA2960319A1 (en) | 2014-09-26 | 2016-03-31 | Visa International Service Association | Remote server encrypted data provisioning system and methods |
| US11257074B2 (en) | 2014-09-29 | 2022-02-22 | Visa International Service Association | Transaction risk based token |
| US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
| GB201419016D0 (en) | 2014-10-24 | 2014-12-10 | Visa Europe Ltd | Transaction Messaging |
| US10325261B2 (en) | 2014-11-25 | 2019-06-18 | Visa International Service Association | Systems communications with non-sensitive identifiers |
| CN113537988B (zh) | 2014-11-26 | 2024-05-28 | 维萨国际服务协会 | 用于经由访问装置的令牌化请求的方法和设备 |
| RU2707939C2 (ru) | 2014-12-12 | 2019-12-02 | Виза Интернэшнл Сервис Ассосиэйшн | Платформа обеспечения для межмашинных устройств |
| US10257185B2 (en) | 2014-12-12 | 2019-04-09 | Visa International Service Association | Automated access data provisioning |
| US10187363B2 (en) | 2014-12-31 | 2019-01-22 | Visa International Service Association | Hybrid integration of software development kit with secure execution environment |
| US10096009B2 (en) | 2015-01-20 | 2018-10-09 | Visa International Service Association | Secure payment processing using authorization request |
| US11250391B2 (en) | 2015-01-30 | 2022-02-15 | Visa International Service Association | Token check offline |
| US11176554B2 (en) | 2015-02-03 | 2021-11-16 | Visa International Service Association | Validation identity tokens for transactions |
| US10977657B2 (en) | 2015-02-09 | 2021-04-13 | Visa International Service Association | Token processing utilizing multiple authorizations |
| US10164996B2 (en) | 2015-03-12 | 2018-12-25 | Visa International Service Association | Methods and systems for providing a low value token buffer |
| SG11201706576TA (en) | 2015-04-10 | 2017-09-28 | Visa Int Service Ass | Browser integration with cryptogram |
| US9998978B2 (en) | 2015-04-16 | 2018-06-12 | Visa International Service Association | Systems and methods for processing dormant virtual access devices |
| US10552834B2 (en) | 2015-04-30 | 2020-02-04 | Visa International Service Association | Tokenization capable authentication framework |
| US10298583B2 (en) | 2015-05-11 | 2019-05-21 | Soteria Services Llc | Integrated activity management system and method of using same |
| US20170024733A1 (en) * | 2015-07-20 | 2017-01-26 | Thomas Purves | Seamless transaction minimizing user input |
| JP2018530834A (ja) | 2015-10-15 | 2018-10-18 | ビザ インターナショナル サービス アソシエーション | トークン即時発行システム |
| CN108370319B (zh) | 2015-12-04 | 2021-08-17 | 维萨国际服务协会 | 用于令牌验证的方法及计算机 |
| SG11201805266YA (en) | 2016-01-07 | 2018-07-30 | Visa Int Service Ass | Systems and methods for device push provisioning |
| EP3411846A1 (en) | 2016-02-01 | 2018-12-12 | Visa International Service Association | Systems and methods for code display and use |
| US11501288B2 (en) | 2016-02-09 | 2022-11-15 | Visa International Service Association | Resource provider account token provisioning and processing |
| US10223685B2 (en) * | 2016-02-26 | 2019-03-05 | Arithmetic Operations Incorporated | Systems, methods, and media for pay-per-access micropayment-based web browsing and server applications |
| US10313321B2 (en) | 2016-04-07 | 2019-06-04 | Visa International Service Association | Tokenization of co-network accounts |
| WO2017184121A1 (en) | 2016-04-19 | 2017-10-26 | Visa International Service Association | Systems and methods for performing push transactions |
| US11250424B2 (en) | 2016-05-19 | 2022-02-15 | Visa International Service Association | Systems and methods for creating subtokens using primary tokens |
| DK179186B1 (en) | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
| AU2016409079B2 (en) | 2016-06-03 | 2021-07-22 | Visa International Service Association | Subtoken management system for connected devices |
| US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
| CN114693289A (zh) | 2016-06-11 | 2022-07-01 | 苹果公司 | 用于交易的用户界面 |
| DK201670622A1 (en) | 2016-06-12 | 2018-02-12 | Apple Inc | User interfaces for transactions |
| US11068899B2 (en) | 2016-06-17 | 2021-07-20 | Visa International Service Association | Token aggregation for multi-party transactions |
| EP3261034A1 (en) | 2016-06-23 | 2017-12-27 | Mastercard International Incorporated | Method and system for authorizing and processing payment transactions over a network |
| SG11201808737YA (en) | 2016-06-24 | 2018-11-29 | Visa Int Service Ass | Unique token authentication cryptogram |
| BR112018076196A2 (pt) | 2016-07-11 | 2019-03-26 | Visa International Service Association | método, e, dispositivos de comunicação portátil e de acesso. |
| WO2018017068A1 (en) | 2016-07-19 | 2018-01-25 | Visa International Service Association | Method of distributing tokens and managing token relationships |
| GB201613882D0 (en) * | 2016-08-12 | 2016-09-28 | Mastercard International Inc | Digital secure remote payment(DSRP) Enhancements when transacting with an authenticated merchant |
| US20180068313A1 (en) | 2016-09-06 | 2018-03-08 | Apple Inc. | User interfaces for stored-value accounts |
| US10509779B2 (en) | 2016-09-14 | 2019-12-17 | Visa International Service Association | Self-cleaning token vault |
| CN111340464B (zh) * | 2016-09-20 | 2023-12-12 | 徐蔚 | 一种数字人的支付方法、装置与移动终端 |
| US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| AU2017364118A1 (en) | 2016-11-28 | 2019-05-02 | Visa International Service Association | Access identifier provisioning to application |
| US10755339B2 (en) | 2017-03-17 | 2020-08-25 | Team Labs, Inc. | System and method of purchase request management using plain text messages |
| US10915899B2 (en) | 2017-03-17 | 2021-02-09 | Visa International Service Association | Replacing token on a multi-token user device |
| CA3059371A1 (en) | 2017-04-13 | 2018-04-13 | Equifax Inc. | Location-based detection of unauthorized use of interactive computing environment functions |
| US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
| US10902418B2 (en) | 2017-05-02 | 2021-01-26 | Visa International Service Association | System and method using interaction token |
| US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
| US11494765B2 (en) | 2017-05-11 | 2022-11-08 | Visa International Service Association | Secure remote transaction system using mobile devices |
| CN111343060B (zh) | 2017-05-16 | 2022-02-11 | 苹果公司 | 用于家庭媒体控制的方法和界面 |
| US20220279063A1 (en) | 2017-05-16 | 2022-09-01 | Apple Inc. | Methods and interfaces for home media control |
| EP3642774B1 (en) * | 2017-06-20 | 2023-05-10 | nChain Licensing AG | System and method of multi-round token distribution using a blockchain network |
| AU2018291152B2 (en) | 2017-06-29 | 2021-11-11 | Equifax, Inc. | Third-party authorization support for interactive computing environment functions |
| US10491389B2 (en) | 2017-07-14 | 2019-11-26 | Visa International Service Association | Token provisioning utilizing a secure authentication system |
| KR102185854B1 (ko) | 2017-09-09 | 2020-12-02 | 애플 인크. | 생체측정 인증의 구현 |
| EP4156129A1 (en) | 2017-09-09 | 2023-03-29 | Apple Inc. | Implementation of biometric enrollment |
| WO2019118682A1 (en) | 2017-12-14 | 2019-06-20 | Equifax Inc. | Embedded third-party application programming interface to prevent transmission of sensitive data |
| CN111819555A (zh) | 2018-03-07 | 2020-10-23 | 维萨国际服务协会 | 利用在线认证的安全远程令牌发布 |
| US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
| US11256789B2 (en) | 2018-06-18 | 2022-02-22 | Visa International Service Association | Recurring token transactions |
| EP3627434A1 (de) * | 2018-09-24 | 2020-03-25 | Youki GmbH | System, verfahren und vorrichtung zur durchführung von kryptographisch gesicherten transaktionen |
| US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
| US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
| CN109242488B (zh) * | 2018-11-22 | 2022-02-18 | 腾讯科技（深圳）有限公司 | 一种安全支付控制方法、装置及服务器 |
| GB2580934B (en) | 2019-01-30 | 2022-08-03 | Fusion Holdings Ltd | Systems and methods for authorizing user access to restricted content |
| SG11202108626QA (en) | 2019-05-17 | 2021-09-29 | Visa Int Service Ass | Virtual access credential interaction system and method |
| JP7075547B2 (ja) | 2019-05-31 | 2022-05-25 | アップル インコーポレイテッド | オーディオメディア制御のためのユーザインタフェース |
| US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
| US11651297B2 (en) | 2019-12-30 | 2023-05-16 | Expedia, Inc. | Booking management system |
| US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
| US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
| US11877218B1 (en) | 2021-07-13 | 2024-01-16 | T-Mobile Usa, Inc. | Multi-factor authentication using biometric and subscriber data systems and methods |
| US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
| US20230222246A1 (en) * | 2022-01-07 | 2023-07-13 | Mastercard International Incorporated | Systems and methods for use in imposing a common domain |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7152045B2 (en) * | 1994-11-28 | 2006-12-19 | Indivos Corporation | Tokenless identification system for authorization of electronic transactions and electronic transmissions |
| US5892900A (en) * | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
| US5812668A (en) * | 1996-06-17 | 1998-09-22 | Verifone, Inc. | System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture |
| DE19630920C1 (de) * | 1996-07-31 | 1997-10-16 | Siemens Ag | Verfahren und System zur Teilnehmerauthentifikation und/oder Verschlüsselung von Informationen |
| JP2000036000A (ja) * | 1998-06-30 | 2000-02-02 | Sun Microsyst Inc | 電子商取引における中立的立会人 |
| US6327578B1 (en) * | 1998-12-29 | 2001-12-04 | International Business Machines Corporation | Four-party credit/debit payment protocol |
| WO2001007873A2 (en) * | 1999-07-21 | 2001-02-01 | E-Payments | A method for performing a transaction over a network |
| FI20000760A0 (fi) * | 2000-03-31 | 2000-03-31 | Nokia Corp | Autentikointi pakettidataverkossa |
| AU6661401A (en) * | 2000-05-25 | 2001-12-03 | Echarge Corp | Secure transaction protocol |
| JP2002207929A (ja) * | 2001-01-12 | 2002-07-26 | Nippon Telegr & Teleph Corp <Ntt> | 顧客認証方法、その装置、プロバイダ装置及びその処理方法、販売サービス提供装置及びその処理方法 |
| US20020147820A1 (en) * | 2001-04-06 | 2002-10-10 | Docomo Communications Laboratories Usa, Inc. | Method for implementing IP security in mobile IP networks |
| DE10149298A1 (de) * | 2001-10-05 | 2003-04-17 | Siemens Ag | Verfahren zum elektronischen Zustellen und Begleichen von Rechnungen |
| JP3899890B2 (ja) * | 2001-10-18 | 2007-03-28 | 日本電信電話株式会社 | 課金方法及びシステム及び購入制御端末及び認証課金サーバ及び販売サーバ及び課金プログラム及び課金プログラムを格納した記憶媒体 |
| JP2003168035A (ja) * | 2001-12-04 | 2003-06-13 | Senshukai General Service Co Ltd | クライアントの詳細情報取得方法 |
| US7996888B2 (en) * | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
| JP5078257B2 (ja) * | 2003-08-28 | 2012-11-21 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 属性情報提供サーバ、属性情報提供方法、およびプログラム |
| GB2406925B (en) * | 2003-10-09 | 2007-01-03 | Vodafone Plc | Facilitating and authenticating transactions |
| US20050114261A1 (en) * | 2003-11-21 | 2005-05-26 | Chuang Guan Technology Co., Ltd. | Payment system for using a wireless network system and its method |
-
2006
- 2006-04-19 JP JP2008507849A patent/JP2008541206A/ja active Pending
- 2006-04-19 WO PCT/US2006/014801 patent/WO2006113834A2/en active Application Filing
- 2006-04-19 EP EP06758421A patent/EP1872188A4/en not_active Withdrawn
- 2006-04-19 MX MX2007012648A patent/MX2007012648A/es active IP Right Grant
- 2006-04-19 BR BRPI0608591-1A patent/BRPI0608591A2/pt not_active IP Right Cessation
- 2006-04-19 CN CN2011103649867A patent/CN102368325A/zh active Pending
- 2006-04-19 CA CA002601785A patent/CA2601785A1/en not_active Abandoned
- 2006-04-19 SG SG201002693-8A patent/SG161290A1/en unknown
- 2006-04-19 KR KR1020077022840A patent/KR20070120125A/ko not_active Application Discontinuation
- 2006-04-19 AU AU2006236243A patent/AU2006236243B2/en not_active Ceased
-
2007
- 2007-09-12 NO NO20074614A patent/NO20074614L/no not_active Application Discontinuation
- 2007-09-17 IL IL185978A patent/IL185978A0/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| JP2008541206A (ja) | 2008-11-20 |
| KR20070120125A (ko) | 2007-12-21 |
| SG161290A1 (en) | 2010-05-27 |
| EP1872188A4 (en) | 2011-04-27 |
| CN102368325A (zh) | 2012-03-07 |
| WO2006113834A9 (en) | 2007-11-01 |
| CA2601785A1 (en) | 2006-10-26 |
| MX2007012648A (es) | 2007-12-13 |
| WO2006113834A2 (en) | 2006-10-26 |
| NO20074614L (no) | 2007-11-16 |
| IL185978A0 (en) | 2008-01-20 |
| WO2006113834A3 (en) | 2009-04-23 |
| AU2006236243B2 (en) | 2011-03-24 |
| AU2006236243A1 (en) | 2006-10-26 |
| EP1872188A2 (en) | 2008-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BRPI0608591A2 (pt) | transaÇÕes comerciais em rede | |
| US8996423B2 (en) | Authentication for a commercial transaction using a mobile module | |
| RU2402814C2 (ru) | Сетевые коммерческие транзакции | |
| US7849020B2 (en) | Method and apparatus for network transactions | |
| US20060235795A1 (en) | Secure network commercial transactions | |
| US20080243702A1 (en) | Tokens Usable in Value-Based Transactions | |
| JP2004511028A (ja) | 情報を安全に収集、格納、及び送信する方法及びシステム | |
| BRPI0708276A2 (pt) | métodos para efetuar autenticação de transação em um pedido por correio eletrÈnico e pedido por telefone e para efetuar autenticação em uma transação de pagamento on-line | |
| US11816666B2 (en) | Secure payment processing | |
| CN102592239A (zh) | 网络商业交易 | |
| JP2005512225A (ja) | 埋込コンテンツの自動化された権利管理及び支払いシステム | |
| CN112970234A (zh) | 账户断言 | |
| AU2011202945B2 (en) | Network commercial transactions | |
| Niya et al. | A Blockchain-based Anonymous P2P Trading System | |
| KR20240001416A (ko) | 블록체인 기반의 nft를 이용한 음원 플랫폼의 서버에서 수행되는 서비스 제공 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B08L | Patent application lapsed because of non payment of annual fee [chapter 8.12 patent gazette] |
Free format text: REFERENTE AO NAO RECOLHIMENTO DAS 7A E 8A ANUIDADES. |
|
| B08I | Publication cancelled [chapter 8.9 patent gazette] |
Free format text: ANULADA A PUBLICACAO CODIGO 8.12 NA RPI NO 2260 DE 29/04/2014 POR TER SIDO INDEVIDA. |
|
| B08F | Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette] |
Free format text: REFERENTE AS 7A, 8A, 9A, 10A, 11A, 12A, 13A E 14A 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: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2602 DE 17-11-2020 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013. |