CN113475047A - 用于保护操作的方法和***以及相关联的用户站 - Google Patents

Abstract

一种用于保护操作的方法，包括：由用户(U)制定用户请求服务提供商装置(20)执行操作的步骤(F30)，服务提供商装置向认证装置(30)发出(F40)证实所请求的操作、同时指示与用户(U)相关联的密钥(CL)的请求。认证装置(30)识别与密钥(CL)相关联的用户，并向用户发出(F60)动态代码请求。生成分配给用户的动态代码的设备(12)生成(F70)动态代码的第一版本(CC1)，并将其发送(F80)到认证装置(30)，认证装置(30)将其与代码的第二版本(CC2)进行比较(F90)，以决定通知服务提供商装置已经证实所请求的操作是否合适。

Description

用于保护操作的方法和***以及相关联的用户站

技术领域

本发明涉及通过计算机化方式(computerized means)保护(securing)操作(例如，为任何服务创建账户或对该账户的访问，或更具体地对账户的线上访问、线上支付、实体(physical)支付等)的一般领域。

背景技术

考虑到寻求窃取用户的身份和金融数据的黑客的激增，保护这些操作是当今的重要问题。关于不同类型的操作，近年来已经开发了若干解决方案，但是这些解决方案仍然具有一定数量的限制。

关于直接支付交易，即，非线上交易(在商家处或用于现金提取)：通过将银行卡***到读取所述卡的数据的终端或支付终端中，这些交易在其基本版本中被区分，整体的安全性通过输入仅用户知道的补充密码来确保。这个级别的主要安全问题涉及密码的盗窃(例如，通过虚拟终端)。

一种有趣且快速增长的方法涉及NFC(近场通信)类型的非接触式支付，针对NFC类型的非接触式支付，将银行卡保持在支付终端附近以验证交易就足够了。优点是对用户的简单性(单个手势就足够了)，加上一定级别的安全性，这是因为用户不输入他的号码或他的密码，因此不会显露它们。另一方面，在卡被盗的情况下，窃贼不再需要密码。为了限制卡盗窃的影响，每个交易的最高价格水平和每个时段(period)的累积价格水平被设置为低阈值。

非接触式智能手机支付解决方案旨在利用与安全措施相关联的类似技术(通常是客户的先前扫描的指纹或他的面部或虹膜的扫描)。然而，后一种数据可能被黑客攻击。实际上，这里的实践是为了用智能手机替代银行卡以方便用户而不是使过程安全。

关于与银行卡相关的线上交易，这些交易在其基本版本中的特征在于提供***的事实，后续通过输入称为CVV代码的补充3位数字代码(名称因银行而异)来保护。由于黑客仅需要得到号码和CVV代码或窃取卡，因此安全性仍然很低。

存在动态密码卡，诸如结合Idemia公司的技术的那些动态密码卡，其3位数字确认代码(称为CVV代码)有规律地(例如，每小时)改变。于是，优点是大大减少了在例如商家站点上的交易期间例如经由键盘记录器工具或由于网络钓鱼(phishing)而对银行***(与客户的账号相关)和该CVV代码的线上黑客攻击的优势，这是因为潜在的黑客只能在非常短的时间段内使用它。这种方法是线上交易中的真正进步，即使它不涵盖银行卡本身被盗的情况。它也不适合与电商的报销相关联的问题。

银行使用的所谓的“安全代码”方法允许他们在他们已经在站点上输入他们的银行数据之后从他们的客户请求线上交易验证：为此目的，银行向他们的移动电话发送验证代码(与银行的内部数据库中的银行账户相关)，并指示他们在返回商家站点之前将该代码复制到交易界面上显示的专用界面中。

这种方法是有效的，但比前一种方法更昂贵，并且不能防止移动电话和银行卡被盗的情况，这是因为它们通常被一起携带。它也不能防止银行卡数据(号码和CVV代码)被盗，并且由于其成本，安全代码的实现不是***性的。最后，当移动电话既用于线上订购又用于接收具有安全代码的SMS时，经验丰富的黑客设法侵入所接收的SMS消息的内容，这种做法倾向于成为主导。公开的法国专利申请FR3044789允许避免后一个问题，但是它的实现更复杂，并且应该被预留用于高额交易或用于安全处理。

还存在银行详细信息存储在线上商家处的情况。这里的目的是在线上订购时简化客户体验。在确认购物篮时，客户仅需选择他们的支付方式并通过输入他们的CVV代码来确认交易。因此，在安全性方面，黑客仅需要得到该CVV代码或银行卡/移动电话。这种方法还为黑客攻击电商的服务器打开了大门，然后黑客攻击客户的CVV代码。

因此，在所有上述情况下，仍然存在安全问题。

另一个薄弱环节实际上甚至保护得更差，并且涉及由用户创建关于任何服务(例如商家服务、或分类广告服务...)的帐户，并且涉及该用户通过简单的标识符和密码登录到该帐户，这些数据可以容易地被黑客攻击。

*稍微更安全的方法在于使用动态表输入密码代码：显示在其上允许的数字或字母在框中的图像，客户有责任点击正确的框，服务得到点击的位置并推断它们的对应关系。这里，黑客攻击有点困难，但对于本领域的专家来说不是问题。

*另一种变型是服务提供商(例如，银行)可以通过另一种方式(例如，另一个电子邮件)或可替代地通过接近安全代码的技术(在客户的移动电话上发送具有代码的确认SMS消息)来传达(communicate)确认代码。这最后一种保护情况不覆盖移动电话被盗的情况(或者可选地，通过标识符和密码对电子邮件进行黑客攻击，以便访问他们的电子邮件)。此外，根据这种情况，假设黑客已经具有客户的标识符/密码，并且错误的答案将仅阻挡客户的账户，这将产生其他问题。

随着关于线上服务的身份数据的盗窃正在上升，这些缺陷都更加令人遗憾。

发明内容

本发明通过提出一种用于保护操作的方法(该方法在用户站处实施)、以及在包括用户站以及服务提供商装置和认证装置的***中实施的用于保护操作的整体方法，特别克服了上述缺点。在用户站处实施的方法也可以被称为“用于处理操作的方法”。

因此，本发明提供了一种用于保护操作的方法，包括：

-从与由认证机构发出的密钥(CL)相关联的用户(U)制定实施与服务提供商装置的操作的请求的步骤；

-由用户站从认证机构的装置接收意图针对与密钥(CL)相关联的用户的对于动态代码的请求的步骤；

-由与所述用户的密钥相关联的动态代码生成器设备生成动态代码的第一版本(CC1)的步骤；

-将动态代码的第一版本(CC1)发送到认证装置的步骤；以及

-在动态代码的第一版本对应于在认证机构处生成的动态代码的第二版本的情况下，从服务提供商装置接收确认所请求的操作的实现的消息的步骤。

相应地，本发明还涉及一种用户站，包括：

-被配置为允许与由认证机构发布的密钥(CL)相关联的用户(U)制定实施与服务提供商装置的操作的请求的用户接口；

-意图用于从认证机构的装置接收意图针对与密钥(CL)相关联的用户的对于动态代码的请求的第一接收模块；

-用于向认证装置发送由与用户的密钥(CL)相关联的动态代码生成器设备产生的代码的模块；以及

-意图用于从服务提供商装置接收确认所请求的操作的实现的消息的第二接收模块。

本发明还提供了一种用于保护操作的整体方法，该用于保护操作的方法包括：

-由用户请求实施与服务提供商装置的操作的步骤；

-由服务提供商装置向认证装置发出证实(validate)所请求的操作的请求的步骤，所述请求指示与所述用户相关联的密钥(CL)；

-从认证装置发出意图针对与密钥(CL)相关联的用户的对于动态代码的请求的步骤；

-由用户动态代码生成器设备生成动态代码的第一版本(CC1)的步骤；

-将动态代码的第一版本(CC1)发送到认证装置的步骤；

-由认证装置获取所述动态代码的第二版本(CC2)并比较动态代码的第一版本和第二版本的步骤；以及

-在动态代码的第一版本(CC1)和第二版本(CC2)匹配的情况下，由认证装置向服务提供商装置发送指示对用户请求的操作的证实的信号的步骤。

相应地，本发明还涉及一种用于保护操作的***，该操作保护***包括服务提供商装置和认证装置，其中：

该服务提供商装置包括：

-用于从用户(U)接收实施操作的请求的模块，

-用于向认证装置发出证实所请求的操作的请求的模块，所述请求指示与用户相关联的密钥(CL)，以及

-用于在从认证装置接收到证实信号之后实施所请求的操作的模块；以及

该认证装置包括：

-用于发出意图针对分配给与所述密钥(CL)相关联的用户的动态代码生成器设备的动态代码请求的步骤，

-用于接收由分配给与所述密钥(CL)相关联的用户的动态代码生成器设备生成的动态代码的第一版本(CC1)的模块，

-用于获取动态代码的第二版本(CC2)的模块，

-用于比较动态代码的第一版本(CC1)和第二版本(CC2)的模块，以及

-用于当动态代码的第一版本(CC1)和第二版本(CC2)匹配时向服务提供商装置发送证实信号的模块。

根据本发明的方法、用户站和***允许避免现有技术的几个缺点，特别是与用户登录线上帐户相关的缺点。此外，这些方法、该站和该***允许实施用于线上支付的双重认证，从而确保根据欧洲指令DSP2的高水平安全性。

在本发明的一些实施例中，用户站具有它自己的集成动态代码发生器设备。然而，可以使用其他解决方案，例如，使用外部动态代码生成器设备。

在本发明的一些实施例中，认证装置包括其自己的动态代码生成器设备，该动态代码生成器设备被配置为同时生成与分配给用户的设备相同的代码。然而，可以使用其他解决方案，例如，从外部设备获得代码的第二版本。

在特定实施例中，服务提供商装置从用户获得标识符，并且使用所述标识符获取与用户相关联的密钥(CL)，特别是从其存储装置之一或从可靠的外部源获取。对于不再需要输入与其标识符相关联的密码的用户来说，保护用户期望的操作变得甚至更便宜。此外，用户可以在具有实施该实施例的若干服务提供商的他的账户上使用相同的标识符，而不损失安全性，这是因为是与他的账户相关联的密钥CL，而不是标识符，来保护连接。

在另一实施例中，发出证实操作的请求的步骤包括发出包括关于所请求的操作的信息的请求；并且该方法包括检索与密钥(CL)相关联的用户的数据的步骤，后一步骤包括：

■检索验证数据，该验证数据指示与所允许的操作有关的至少一个限制，以及

■分析接收到的关于所请求的操作的信息，以便与验证数据相关地确定该操作是否被允许。

检索验证数据的该步骤可以包括检索定义关于与密钥CL相关的所允许的操作的至少一个限制的数据。这些数据例如是：时间段，其中在该时间段操作被允许，地理区域，其中在该地理区域或从该地理区域，操作被允许，服务提供商，其中利用服务提供商，操作被允许，以及与操作的实现相关联的价格。根据一个特定实施例，由验证数据定义的限制可以由用户参数化，例如，取决于他打算对他的密钥CL进行的使用。

验证数据使得可以定义用于使用分配给用户的密钥的终端，这些终端由认证机构、用户或两者设置。操作的安全性将更加增强，因为黑客将不知道应用于密钥CL的使用的限制，并且将不能够采用满足限制所需的行为。

另外，验证数据的使用提供了方法/***的参数化的广泛可能性，并且使得可以定义新的特定安全应用。这些参数的一个大优点是它们的组合。作为非穷举性示例，除了它们在保护账户方面的优点之外，这些组合允许在不创建新账户并且不需要新的支付卡的情况下将支付密钥CL作为零花钱(pocket money)传输给孩子，将他限制在某些商店、线上商家站点列表和/或每月特定金额。这些组合还使得可以向将要在国外实习的孩子提供具有特定金额的密钥CL卡，该密钥在实习期间在所述国家有效。

验证数据的使用使得可以执行反垃圾邮件(anti–spam)方法，整体安全方法被适配如下：

-该请求不是由用户而是由服务提供商装置制定的，并且包括向与密钥(CL)相关联的用户发送消息的请求；

-由认证装置检索与密钥(CL)相关联的用户的数据的步骤包括检索指示用户的反垃圾邮件参数的验证数据并检索用户的细节；

-省略发出对动态代码的请求和生成动态代码的第一版本和第二版本的步骤；

-发送指示对所请求的操作的证实的信号的步骤包括：当认证装置发现消息的发送与用户的反垃圾邮件参数兼容时，根据由认证装置检索的细节将消息发送给用户。

根据该反垃圾邮件方法，服务提供商SQ不具有用户的联系细节，并且只有当消息符合与该用户相关而定义的反垃圾邮件参数时，认证装置才允许向用户发送服务提供商的消息。因此，例如，用户可以指定他同意从特定服务提供商和/或他同意通过其接收消息的通信装置(例如，SMS、电子邮件)接收的每个时隙的消息的数量。

根据一个实施例，限制可由用户参数化。例如，用户接口允许他在该方法的初始步骤期间或在任何时间修改与给定密钥CL相关联的参数，例如，通过登录到他的认证机构的账户并通过选择想要的密钥CL。因此，用户可以修改有效期、使用授权、授权金额等。该修改将对过去的使用没有影响，但是将适用于密钥CL的未来使用。以这种方式，用户获得对他执行的敏感操作的增加的控制水平。

在另一实施例中，由与用户的密钥CL相关联的动态代码生成器设备生成动态代码的第一版本是由用户的动作触发的。以这种方式，将被发送到认证装置的动态代码的可预测性将被进一步降低，从而进一步降低数据被黑客攻击的可能性，因为除了与代码的动态生成相关联的可变性之外，还存在用户主动的随机可变性。

通过用户的动作触发由分配给用户的动态代码生成器设备产生新代码意味着需要使认证装置侧的动态代码生成器设备与用户侧的动态代码生成器设备同步。各种方法适合于实现这种同步，诸如例如使用有序的代码序列。在特定实施例中，认证装置被配置为当发现代码的第一版本和第二版本不匹配时，尝试解决代码序列内的定位中的间隙。为此，认证装置可以实施迭代过程，该迭代过程包括获取动态代码的新版本，将新版本与动态代码的第一版本(CC1)进行比较，并且在肯定比较的情况下确定存在代码的匹配，但是在否定比较的情况下，重复迭代过程的步骤，直到已经获取了代码的n个版本并将其与代码的第一版本进行比较。该过程可以在一个实施例中使用，根据该实施例，动态代码包括用于这些同步目的的子代码(CCs)，并且动态代码的演变包括同步子代码的每个字符根据相应规则的渐进变化。此外，根据一些特定实施例，同步子代码的字符分布在动态代码的其他字符之间。

上述措施确保了在两个(用户和认证机构)侧的动态代码生成器设备之间的良好同步，同时获得高水平的安全性。

根据一个特定实施例，用户站设置有致动模块，该致动模块旨在由用户致动以触发由动态代码生成器设备生成代码，并且设置有生物识别数据传感器。在该用户站中，生物识别数据传感器可以在致动模块被用户致动时获得用户的生物识别数据。如果生物识别数据传感器没有证实在用户的所述动作期间检测到的生物识别数据，则代码发送模块不向认证装置发送有效代码(例如，没有信号被发送到认证装置，或者发送指示已经检测到不正确的生物识别数据的信号)。

根据另一方面，本发明还涉及一种用户站，该用户站包括动态代码生成器设备、用于向认证装置发送由动态代码生成器设备产生的代码的模块、以及生物识别数据传感器。

通过使代码的第一版本的发送以用户的生物识别数据的有效性为条件，第二级认证被引入到该方法中，从而进一步提高了安全性。

在特定实施例中，认证装置发出对动态代码的请求的步骤包括向用户站发送关于所请求的操作的信息。这允许警告用户第三方正在尝试通过使用用户的密钥CL来执行操作。因此，用户可以使用他的站向认证装置发送指示拒绝操作的信号，并且因此认证装置将不向服务提供商装置发出证实(validation)信号(例如，将发送未经证实(non–validated)的操作信号)。

在特定实施例中，认证装置发出对动态代码的请求的步骤包括向用户站发送对补充信息的请求，并且认证装置对操作的证实以用户站返回的补充信息为条件。作为非限制性示例，认证装置可以请求关于用户站的地理位置的数据，并且认证装置对操作的证实然后以用户站返回的地理位置信息为条件。例如，认证装置验证该信息是否符合与用户的密钥CL相关联的验证数据。因此，可以向基本方法/***添加安全层。

根据本发明的用于保护操作的方法和***允许使几种类型的不同敏感操作变得安全，例如：创建或安全登录到帐户、金融交易、银行操作、在实体或线上站点上购买、从自动柜员机(ATM)提取现金、或甚至创新的反垃圾邮件服务。与现有技术的方法相比，该方法和***的巨大优点是增加的安全性，伴随着极大的易用性。

该方法在创建账户期间为服务提供商和用户提供了强安全性，因为账户的证实与服务外部的过程相关。

根据另一示例，该方法在登录账户时提供强安全性：服务提供商仅需要用户标识符(不需要密码，或者作为变体，不需要其他个人信息)和他的密钥CL。在不拥有为所讨论的客户生成动态代码的不同设备的情况下，该信息对于可能的黑客是不可用的，特别是如果服务提供商不存储可以在该方法结束时发送回它的个人数据。

关于用户体验，根据本发明的各种实施例，用户简单地输入他的标识符，然后复制他的CC代码。

线上金融交易也是如此。电子商家不再担心黑客攻击的风险，因为他关于客户存储与银行***无关的密钥CL(并且可能仅对于每个时段预定义的金额对该电子商家有效)。代替输入银行***，然后是到期日期和CVV代码，用户仅输入由他的动态代码生成器设备生成的CC代码。另外，该装置与现有技术的方法兼容。

在特定实施例中，安全方法的不同步骤由计算机程序指令管理。因此，本发明还涉及相应信息介质上的计算机程序，这些程序能够在服务提供商装置、认证装置和用户站中实施，或者更一般地在计算机中实施。这些程序包括适配于实施如上所述的用于确保操作的计算机化方法的步骤的指令。

这些程序可以使用任何编程语言，并且可以是源代码、目标代码或源代码与目标代码之间的中间代码的形式，诸如部分编译的形式或任何其他期望的形式。

本发明还涉及计算机可读的信息介质，并且包括来自如上所述的计算机程序的指令。

信息介质可以是能够存储程序的任何实体或设备。例如，介质可以包括存储装置，诸如ROM，例如，CD ROM或微电子电路ROM，或磁记录装置，例如，软盘或硬盘。

另一方面，信息介质可以是诸如电信号或光信号的可传输介质，其可以经由电缆或光缆、通过无线电或其他方式来传送。特别地，根据本发明的程序可以从互联网类型的网络下载。

可替代地，信息介质可以是其中包含程序的集成电路，该电路适配于执行或用于执行所讨论的方法。

此外，在其他实施例中，还可以设想，根据本发明的保护方法、保护***和用户站具有全部或部分上述特征的组合。

附图说明

图1示意性地表示在一个特定实施例中的根据本发明的保护***；

图2以流程图的形式表示根据本发明的用于保护操作的整体方法的主要步骤；

图3示意性地表示在图2的方法的过程期间***的元件之间的主要交互；

图4以流程图的形式表示根据本发明的一个实施例的在用户站处的用于保护操作的方法的主要步骤；

图5表示在一个特定实施例中根据本发明的用户站的架构；

图6表示在一个特定实施例中根据本发明的服务提供商装置的架构；

图7表示在一个特定实施例中根据本发明的认证装置的架构；

图8表示在一个特定实施例中根据本发明的用户站的硬件架构；以及

图9以流程图的形式表示根据本发明的一个实施例的反垃圾邮件方法的主要步骤。

具体实施方式

图1示意性地表示在一个特定实施例中的根据本发明的保护***。注意，图1中表示的示例涉及包括用户站以及服务提供商装置和认证装置的***。作为替代，***不包括用户站，并且用户U通过使用例如由服务提供商提供的单元(means)引入必要的数据(例如，标识符、动态生成的代码的第一版本以及可选地，密钥CL)。

在图1中考虑的示例中，用于保护操作的***1包括经由网络40(例如，互联网、电话网络、WAN、LAN、有线或无线网络等)彼此通信的用户站10、服务提供商装置20和认证装置30。

用户站10可以是移动电话、平板电脑、PC或用户U的任何其他设备。通常，服务提供商装置20包括由服务提供商SQ操作的服务器或一组服务器，可能与其他设备相关联。服务提供商SQ可以是商家、银行等。典型地，认证装置30包括由认证机构CERT操作的服务器或服务器组，其可能与其他设备相关联。认证机构CERT可以是银行、移动运营商或适于发布密钥CL并向服务提供商SQ提出根据下面描述的标准化方法的任何其他类型的机构。

现在将参考图2和图3描述在特定实施例中根据本发明的用于保护操作的方法期间实施的主要步骤。该方法可以由图1中表示的***实现。图2以流程图的形式表示该方法的主要步骤，并且图3示意性地表示在该方法的过程期间***的元件之间的主要交互。

根据某些特定实施例，图2中表示的方法可以包括初始阶段或步骤(EP)，在该初始阶段或步骤期间，密钥CL被分配给用户U。该初始步骤EP可以特别地包括第一子步骤F10，根据该第一子步骤，用户与认证机构制定倾向于产生(生成)密钥CL以及将该密钥CL分配给用户的请求。在子步骤F20中，认证机构CERT将密钥CL发送给用户，并且通常还将发送给动态代码生成器设备DC。可替代地，用户已经具有动态代码生成器设备，并且在该阶段从认证机构CERT仅获得所生成的密钥CL。

当用户U希望通过使用他的密钥CL进行交易或其它操作，特别是敏感操作时，用户在该方法的第一步骤E1期间制定对服务提供商SQ的请求DEM_OP(F30)。

然后，在该方法的第二步骤E2期间，服务提供商装置20向认证装置30发送请求REQ_VAL(CL)以证实所请求的操作，所述请求指示与用户U相关联的密钥CL(F40)。

在该方法的第三步骤E3期间，认证装置30例如通过借助于密钥CL在数据库中执行搜索来识别与密钥CL相关联的用户。根据本发明的一些实施例，认证装置30检索(F50)在初始阶段EP期间记录的、与密钥CL的使用相关联的验证数据，并且执行某些验证，例如，与涉及从用户U请求的操作的信息相关地，该信息已经由服务提供商装置20(例如，在包括密钥CL的消息中)发送到认证装置30。如果合适，则认证装置30可以已经向服务提供商装置发送指示所请求的操作在所准许的对密钥CL的使用之外的消息(F55)。然后，认证装置30发出意图针对与密钥(CL)相关联的用户的动态代码请求REQ_CC(F60)。当然，如果认证装置已经向服务提供商SQ指示所请求的操作无效，则该方法可以在步骤F55结束。在根据图1所示示例的***中，认证装置30可以在将被显示在屏幕上的表单(form)上向用户站10发送请求REQ_CC。

在接收到由认证装置30发送的请求REQ_CC之后，并且在该方法的第四步骤E4期间，与用户的密钥CL相关联的动态代码生成器设备DC产生动态代码的第一版本CC1(F70)。根据本发明的一些实施例，动态代码生成器设备DC设置有按钮(或可以由用户致动的其他单元)，并且在用户致动该按钮之后生成动态代码。接着是向认证装置30发送包括动态代码的第一版本CC1的消息TX_CC1的步骤(F80)。

该方法以第五步骤E5结束，在第五步骤E5期间，认证装置(30)获取动态代码的第二版本(CC2)并将其与代码的第一版本进行比较，并且如果动态代码的第一和第二版本(CC1，CC2)匹配，则向服务提供商装置20发送指示对用户U所请求的操作的证实的信号TX_RES(F100)。当然，在比较结果为否定的情况下，认证装置30可以向服务提供商SQ发送指示所请求的操作尚未被证实的消息。可选地，可以在步骤E5结束时向服务提供商装置发送进一步的信息。此外，比较(F90)的结果可以获得由认证装置30对其他操作的执行(例如，与CL代码相关联的信用量的更新)。

现在将更详细地解释执行图2和图3中所示的步骤EP和E1至E5的不同方式。

初始步骤(EP)

在该方法的初始步骤EP期间，负责认证操作(例如，交易或连接)的机构向用户提供与生成动态密码代码CC的设备DC相关联的密钥CL(该设备DC已经由用户持有或者在步骤EP期间由认证机构提供给用户)。

用于获得与所述用户相关联的密钥CL的方式

为此目的，根据一个优选实施例，所述用户必须首先向所述认证机构CERT注册并向其提供各种元素：姓氏、名字、联系方式(电话、电子邮件地址)等。

注册可以线上完成(可能使用诸如本发明的方法)或实体地完成，如利用传统的银行分行。它也可以混合：例如，线上注册的第一阶段和在将实体设备DC递送到他的预先指示的地址(例如，他的邮政地址，在诸如中继的商定位置)之后的第二阶段。

与密钥CL相关联的(用户)数据

根据一个实施例，用户向他的认证机构请求密钥CL并且指定各种参数，该参数对应于认证机构将以一种方式或另一种方式(例如，借助于专用于所述认证机构的数据库或用于管理这些数据的持久性的任何其他装置)将其与所述密钥CL相关联的不同类型的信息。信息类型的列表可以是非常多样的，并且这里仅提及一个非穷举子集。一些信息将用作验证数据，但是其他信息对应于与用户相关联的元数据(当然，一些信息可以履行两个角色)。

例如，信息的类型可以涉及：

密钥CL的用户：

*如果没有指定名称，则可以用用户U-lnit的名称建立链接，如在他的注册期间所指示的(如在前一步骤开始的描述期间所指示的)。

*用户可以指定另一个第三方名称或别名(他希望与该密钥CL相关的名称)。

*如果想要共享密钥(有点像联合账户)，则用户可以可选地指定若干名称。

对于这些不同的情况，以使用数据库进行关联为例，认证机构将管理密钥CL与其所有者U-lnit和上述不同的互补标识U-Comp的关联。

可以向每个标识U-Comp(可选的)添加补充数据，这取决于例如在相关国家中生效的立法：

*U-Comp的年龄(如果密钥例如被分配给U-lnit的小孩，该小孩是未成年人)或者可替代地对应的(未成年人或成年人...)状态。默认情况下，该参数被初始化为U-lnit的参数。

*如果它是法律或自然人(加上任何规格：公司名称...)。

*相关联的一个或多个通信标识，其可能不同于U-lnit的那些(例如，电话号码、消息传递标识符、电子邮件……)，以及可替代地，相关联的方式(例如，通过SMS发送)。

授权向SQ公开与密钥CL相关的信息：

作为非穷举示例，授权或非授权公开姓氏、名字、年龄、地址、通信方式等…可以被参考。在没有指定这些数据的情况下，可以对这些数据的全部或部分提供默认授权。作为非穷举性示例，在该方法和设备的步骤E5中，用户同意公开的数据的所述发布可以是有效的。

与密钥CL相关的使用(由SQ)授权

授权总是给予SQ。作为非穷举示例，在本文件末尾描述的反垃圾邮件应用的情况下采用这些使用授权。

密钥CL的安全操作/使用情况

可选地，可以指定密钥CL的至少一个特定使用情况。存在许多使用情况的示例。

作为非穷举示例，使用情况是：

*到网站或应用程序的注册和/或连接，

*对任何服务(报纸或印刷杂志…)的订阅，

*一般的实体支付或线上支付，

*在至少一个特定商店(例如，给定超市连锁店的给定商店)中的支付。

*在至少一个商家站点上的线上支付。

根据用户的请求，密钥CL因此可以被限制于可能在特定站点上的注册和连接或线上支付手续或两者。

因此，密钥可以具有若干使用情况(不要与使用授权混淆)：例如，注册、连接到站点以及在所述站点上的线上支付。

在没有任何使用情况限制的情况下，密钥CL可以用于所讨论的用户的所有可能的使用情况。实际上，这些使用情况限制是可选的。用户可以使用单个密钥在不同的站点或服务上连接/注册，而不指定哪些站点或服务，或者如果它们是商家站点，则在所述站点上支付。但是他将不能从上面提到的优点中受益，也不能从下面将说明的优点中受益。

使用密钥CL时的其他限制

可选地，可以关于密钥CL的使用来定义至少一个限制。限制的示例很多，并且下面仅列出了几个：

*在密钥CL的持续时间或有效期方面的限制。

可选地，可以存在与所述密钥相关联的若干有效期。

*地理位置方面的限制

可以做出这些限制，例如，以将密钥CL的使用限制到给定的地理区域，作为非穷举的示例：在一个国家中，或者在特定商店的地理位置处。

*金额方面的限制(与付款类型用途有关)

例如，可以指定最大量，并且可能是每个时间段的量(可能有取决于时间段的单独的量)。

同样在这个级别，可以指定支付是仅基于服务收费进行还是允许订阅(在持续时间和时段方面的上述限制可以限制它们的范围)。

用于设置与所述密钥CL相关联的验证信息的参数化的方式

当使验证信息参数化时，可以使用常规方式来允许用户指定他的愿望。指定所有已知方式并不落入本专利申请的范围内，但是作为非穷举性示例，在对密钥CL的请求期间，不管为所述请求实施的方式如何(在分支机构中实体的、通过电话的、经由来自认证机构的表单线上的)，用户可以指定与所述目标相关的数据，可能使用可从认证机构获得的参考列表。

作为其他非穷举示例：

*在意图用于线上支付的密钥的情况下，用户可以指定线上支付选项。

*在意图用于一个人的支付的密钥的情况下，用户可以指定通用支付选项。

根据另一示例，在线上请求期间，用户可以指定“注册服务”，然后从已知服务的列表中进行选择，或者如果所述服务或站点的名称不在已知站点的列表中，则手动添加所述服务或站点的名称(并且在网站的情况下可能添加与域名相对应的URL)。

可替代地，在存在这些服务的参考列表的情况下，对应于SQ本身的所述服务在初始步骤之前提供由认证机构按照其参考所述服务的名称或代码名称。

参数也可以彼此依赖地呈现。

因此，在没有先前限制的情况下，用户可以在支付金额方面制定限制请求，以便能够指定所述金额和相关联的条款。只有当针对他的密钥CL已经指示支付使用时，才自动向客户提出该选项。

与密钥CL相关的这些不同类型的参数化数据的组合可能需要在后续步骤中进行验证：例如，仅允许在给定商店中进行实体支付的密钥CL可能需要在后续步骤期间进行以下验证中的全部或部分：非线上支付处理、从卖方发送数据以验证它们与和密钥相关的数据的一致性、待检查的卖方的可能地理位置与和密钥相关的地理位置的关系...。根据本发明的该实施例的方法和***的一个优点，除了其极大的参数化能力之外，是卖方或黑客在任何时候都不知道与所述密钥相关联的验证数据。

此外，如上所述，这些参数的一个重要优点来自于可以进行的组合。

与CL相关联的用户信息的参数化的时序

注意，根据本发明的一些实施例，用户不仅可以在初始步骤EP期间而且可以在任何时间修改与给定密钥CL相关联的参数。用户可以通过登录到他的认证机构的帐户，然后选择期望的密钥CL，然后通过修改所述参数来执行期望的修改。

密钥CL

根据本发明的特定实施例，密钥CL是银行卡的号码，其可能与到期日期相结合，并且CC代码是所述动态密码代码。充当认证机构的实体则是银行机构。

然而，尽管其所有优点(成熟的技术、现有的参与者、通过***自动识别认证机构(这里是银行)...)，但是该实施方式具有一些缺点：商家站点与其银行之间的API(应用编程接口)已经就位并且根据银行机构(银行机构然后以标准化方式交换交易数据)而不同，不能适应第三方数据与市场数据的证实，反馈与由这里描述的方法和设备设想的信息不同的信息...

根据一个实施例，由认证机构提供的密钥CL不一定对应于银行卡的号码，而是意图针对所述用户的唯一密钥。该密钥由预定数量的一连串字符(例如，数字和/或字母)组成。可替代地，该一连串符号也可以包含特殊字符。

该唯一密钥可以以电子方式或以任何其他形式提供给用户。因此，它可以在塑料卡上实现，如银行卡的情况。

根据具体的一个实施例，像银行卡一样，密钥CL在该密钥的代码中包括允许标识认证机构的方式，其允许该一连串字符的标准化，并且允许独立于认证机构的标准化API。当然，该变型的另一个优点是所述密钥CL是全球唯一的：在市场上不可能重复。

例如，如果所述密钥由16个字符组成，则前12个字符可以专用于用户的特定密钥，最后4个字符专用于发布机构的标识。在这种情况下，无论密钥CL如何，所述认证机构及其代码的列表都是唯一的。

在银行机构提出可以在银行卡上查看的密钥CL并且可能包含已知的动态密码设备的情况下，关于这些情况进行以下解释以更好地解释解决方案的优点。

根据第一变型，密钥CL对应于银行***，其可能与到期日期组合，并且动态密码代码CC的设备DC对应于动态密码卡上可用的设备，其中3位数字代码(称为CVV代码)根据上面已经解释的方法和方式周期性地改变。然而，已经提到了该第一变型的缺点，特别是相对于已经就位的程序的刚性及其低可扩展性。

根据另一变型，密钥CL不是***，并且可以包括一连串字母和/或数字，其具有特定的标准化序列和位置，特别是便于辨识已经指示的认证机构。密钥例如由认证机构电子地或通过任何其他方式传达给用户。可替代地，它被粘附在任何介质(例如，塑料卡)上并且在任何介质上可见。

如下面所公开的，根据一个实施例，密钥CL的代码元素可以使得有可能明确地确定发布所述密钥CL的认证机构。

根据一个实施例，密钥CL的代码元素(作为非穷举示例，密钥的第11和/或第12个字符)允许对所述密钥的使用的特定限制，当存在一些限制时，将被指定：作为非穷举示例，没有限制的密钥将在第11个字符中具有A，而仅可用于注册请求的密钥将在第11个字符中具有I。

设备DC可以与若干密钥CL相关联

用户可以指示用于默认使用的有效数据，然后请求由认证机构创建具有不同数据(特别是如果他想要所述密钥中的一个用于第三方，例如，孩子)或部分不同数据的不同密钥。

具有用于所有这些密钥或它们中的一些的单个设备DC极大地简化了用户的任务(不需要具有5个卡(或戒指、手表等)，每个卡具有这些设备DC中的一个)。可替代地，他可以具有有限数量的设备DC：例如，第一设备意图用于他的具有不同服务的账户，而另一设备意图用于他的支付方式。

根据另一实施例，用户的若干设备DC被组合在同一介质上。作为非穷举性示例，诸如具有屏幕的环(ring)的介质具有2个设备DC和相应的显示屏幕，第一屏幕意图用于显示第一设备的密钥CC，该密钥CC例如对应于用于访问各种服务的密钥，第二屏幕意图用于显示第二设备的密钥CC，该密钥CC例如对应于用于访问线上支付的密钥。

根据另一种可能的实施方式，所述介质仅具有一个显示屏，并且作为非穷举示例的诸如按钮的单元允许从一种类型的显示切换到另一种类型的显示，该单元与用户使用来生成动态代码的下一个值的可能存在的脉冲(pulse)单元不同。在这种情况下，显示器上的视觉线索(例如，符号或颜色)允许区分2个设备DC中的每一个。

根据第一变型，所述公共设备DC具有用于显示其支持的不同密钥的单元，使得用户选择期望的密钥以获得对应的当前(或脉冲)CC代码。然而，该变型使得设备DC更复杂，并且还使得其使用复杂：例如，如果密钥CL包括一系列16个数字和/或字母，则用户必须记住这些相当费力的序列中的每一个对应于什么使用。

在一个优选实施例中，设备DC与密钥的选择无关地，根据以上详细描述的实施方式之一生成CC代码。然后，该设备DC和用户的一个或多个密钥CL之间的链接仅保存在认证机构的数据库中。除了消除上述缺点之外，后一种变型对于用户具有另一个优点，即，他能够在任何时间添加或删除与该设备DC相关的新密钥CL，而不必修改所述设备(在认证机构的数据库中添加或移除CL和DC之间的所述链接就足够了)。

例如，通过这种方式，用户可以具有设置有按需生成密码代码CC的这种脉冲设备DC的环，并在该方法和设备的以下步骤中使用所述代码来：

a)保护在对应于第一密钥CL的站点A上的注册或连接(登录)

b)保护在对应于第二密钥CL的站点A或B上的注册或连接，其中，对于第二密钥CL，所述站点A或B发布其他身份数据(例如，别名)

c)通过指示第三密钥CL(并允许所讨论的站点将其保存用于下一次交换)来进行线上支付，

d)利用他的银行卡的号码进行线上支付，该银行卡的号码然后用作第四密钥CL，不再需要将CVV代码写入所述卡的背面(因为在我们的示例中，CVV代码被转移到用户的环上(根据另一示例性实施方式，设备DC被合并到银行卡中并且用于所有使用情况的示例))。

e)保护他与发行所述卡的银行站点的连接，其对应于第五密钥CL

第一步骤:E1

在第一步骤E1期间，用户请求执行与任何SQ服务的装置的操作。目标操作是多种多样的，这里给出了一些没有限制的示例：创建帐户的请求、发起交易的请求、访问经营场所或者实体或数字资源的请求(例如，打开车或启动车的请求、进入私人住宅或公司的请求)等。在这种情况下，他指示或关联他的密钥CL和认证机构。根据包括认证机构的代码的密钥CL的变型，用户不需要在该步骤E1期间提供该信息。

在该步骤E1期间，可以隐式地确定操作类型(账户创建、账户登录、支付交易的开始…)。

例如，如果用户点击或按下“创建您的帐户”类型的按钮，则SQ服务的装置将确定这是帐户创建，并且该信息将在该方法的其余部分中被使用。

根据一个实施例，认证机构使标准化API可用于SQ服务的装置，并允许其选择操作类型，然后提供如这种类型的操作的功能所需的补充信息。根据该变型，在该方法的后续步骤期间，这种相同的API将用于SQ装置和认证机构之间的不同数据交换。

第一示例：用户利用SQ服务的装置选择“帐户创建”类型的操作。

由用户提供的唯一有用信息是密钥CL。根据在前一步骤中执行的配置，密钥CL仅意图用于SQ服务上的使用，或者意图用于包括在SQ服务上的使用的更一般的使用。

但是如稍后在其他类型的操作的描述期间将看到的，考虑到它要求用户保留与其在SQ服务上的使用相关联的所述密钥的组成，限于该单个信息对于用户而言可能是有问题的。

因此，除了密钥CL之外，SQ服务的装置还可以向用户提出填写例如包括补充信息(诸如连接(登录)标识符)的表单。作为非穷举示例，所述标识符是个人电话号码或个人电子邮件。根据另一变型，注册表单包括其他信息，作为非穷举示例，诸如姓氏、名字以及例如所述用户的地址或另一联系人数据。

然而，根据一个实施例，如果用户已经授权它，则在后续步骤期间由认证机构而不是由用户提供该补充信息。

第二示例：用户利用SQ服务选择“帐户登录”类型的操作。

应当注意，该第二示例的实施方式意味着用户先前已经利用SQ服务选择了“帐户创建”类型的操作，然后积极地(positively)跟进着根据本发明的一个实施例的方法的所有步骤，该步骤涉及使用适当的密钥CL利用SQ服务的这种帐户创建。显然，他已经拥有了SQ的帐户，该帐户是使用所描述的方法和设备创建的。

可替代地，如果用户已经经由常规注册过程注册了所述SQ服务，则为了随后借助于所描述的方法和设备连接到该相同的服务，他必须通过添加他的密钥CL来利用所述SQ服务预先完成他的简档(profile)。在该更新之后，用户随后将能够使用实施本发明的方法和***进行连接。在这种情况下，为了登录到SQ的所述帐户，用户必须指示与该帐户相关的密钥CL。

如上面所看到的，这样的实施方式要求用户记住密钥CL的组成，如果密钥CL的组成包括16个字母或数字，作为非穷举示例，则密钥CL的组成一点也不简单(straightforward)。根据一个实施例，用户输入他在先前操作期间创建他的帐户时指示的个人登录ID。归功于该方法和设备的实施，他不必在该步骤输入密码。然后，SQ服务的装置在其存储装置之一(诸如所述SQ服务的数据库)中检索与用户的账户相关联的密钥CL，所述用户在创建其账户时或在随后更新其所述服务的账户的操作期间已经指示了与该登录ID有关的密钥CL。存储装置可以在SQ服务的装置20的内部或外部。

第三示例，用户利用SQ服务在选择了商品或组成购物篮之后选择“线上支付”类型的操作。

要区分两种场景：

a)用户已经为所述SQ服务指示的密钥CL既用于注册和/或连接(登录)，也用于线上支付。在这种情况下，一旦如上所述连接到SQ服务设备，用户就没有什么需要指示。在该步骤中，他必须做的是证实他的购物篮的金额或交易的金额，并等待由该方法的后续步骤产生的交互。

b)用户使用另一密钥CL作为支付方式，无论该密钥CL对于他的所有支付是通用的还是被限制于(在初始步骤期间)在SQ服务上使用。

在第一种情况下，作为非穷举性示例，它可以是与我们的方法和设备兼容的银行卡背面上指示的数字。在除了银行卡之外的情况下，它可以是任何密钥CL。在这种情况下，用户只需指示他的支付密钥CL的数量或所述序列，并等待由后续步骤产生的交互。

与现有技术的方法和设备不同，用户可以不用担心，特别是在除了银行***之外的情况下，将他的支付密钥保留在所述SQ服务处，这是因为如随后将看到的，在没有相关联的设备DC的情况下，任何黑客都将无法使用所述密钥。

更不用说显著增强的安全性，这也导致在支付侧的无与伦比的客户体验：不是在输入他的银行详细信息之后证实金额，而是在该步骤中用户仅必须证实他的支付金额。

当然，如果商家站点限于经典支付API，则这里提供的解决方案是兼容的，这是因为可以根据现有技术的状态的方式使用相同的***来访问不属于我们的方法的商家服务(用户将仅需要在该步骤直接以常规方式输入他的银行详细信息：银行***、到期日期和由设备DC生成的CVV代码)，并且访问属于我们的方法的SQ服务。

第二步骤：E2

在该方法的步骤E2期间，服务提供商SQ的装置20请求认证机构证实在步骤E1中执行的操作。这里，该步骤包括向所述认证机构传达由用户在步骤E1中选择的密钥CL，并且附随地传达与所述操作相对应的上下文数据。

根据一个实施例，所述信息的传输是标准化的，并且通过由第三方机构OT提供的接口(API)来执行，其中，对于该API，所述SQ服务附属于该第三方机构OT(该第三方机构也可以是认证机构，但是密钥CL不一定由认证机构管理，而是由市面上的任何认证机构管理)，该API是详述用于与市面上的不同认证服务交互的过程以及所交换的数据的格式的接口。

根据该变型，除了与用户相关联的密钥CL之外，SQ服务的装置还以标准化方式提供与用户在步骤E1中请求的操作类型有关的不同信息。

例如，SQ服务的装置向认证机构提供用户的密钥CL和与所执行的操作相对应的符码(codification)。它还可以提供特定于SQ服务的装置的KSQ密钥。

符码例如是3个字母的序列。

该符码例如是用于账户创建的“CRE”、用于账户登录的“CNX”、用于一次性支付的“PAY”、用于分期付款的“PAYn”(其关联数据有次数……)、用于通过订阅支付的“PAYAb”(其关联数据有订阅持续时间、周期性金额……)。

许多其他用途是可能的(例如，转移到第三方账户或另一密钥)。每次使用与特定代码相关联以及与和操作类型相关的一项或多项补充信息相关联(例如，除了“VIR”类型的关键字、金额、账户或第三方密钥和截止期限指示之外，还有转账)。

应当注意，在SQ服务的装置处实施的API程序的处理还允许在SQ服务处执行第一系列检查，诸如，例如验证密钥CL的一致性(字符的数量)、认证机构的确定(根据密钥中包括的对应代码的功能...)以及根据在初始步骤结束时详述的变型来验证所述密钥是否被授权用于这种类型的操作(也根据用于这些检查的在密钥中预定义位置处包括的对应代码的功能...)。

根据另一实施例，由SQ服务的装置提供的密钥CL允许认证机构或对于该API(其然后将所收集的信息发送到认证机构)所述SQ服务所附属于的第三方机构OT检索根据本发明的方法所需的并且涉及SQ服务的信息，诸如例如SQ服务的名称、所涉及的域名的URL(或关于任何商店的应用标识符，作为非穷举性示例，Apple商店或Play商店类型的应用标识符)。在这种情况下，可以提供其他信息，例如，如果所述SQ服务是实体商店，则可以提供与所述SQ服务的地理坐标相关的信息(在SQ的注册期间向提供其密钥API的服务提供的信息)。

本领域技术人员将理解，在这方面，实施方式的其他变型是可能的，但是为了简洁起见，这里不详细描述它们。例如，仅提供密钥，并且认证机构向SQ服务的装置请求补充信息。

根据实施方式的第一变型，在SQ服务的装置处实施的API程序的处理中包括的相关表使得有可能基于对与密钥CL相对应的认证机构的确定(经由密钥CL内的一系列专用代码)来找到要查询的认证机构的地址(URL类型，作为非穷举示例)。在这种情况下，SQ服务的装置根据该相关表，通过按照上述标准化方式向其发送信息，来直接查询(优选地经由安全链路(例如https类型))在适当的地址处的所述认证机构。该第一变型更快，但是需要频繁更新由各种SQ服务使用的相关表。

根据实施方式的另一变型，SQ服务的请求被发送到第三方机构OT，第三方机构OT在可选地检索到与所述第三方服务OT的存储装置中的SQ的密钥KSQ API相关联的信息之后，将SQ服务的请求以及从初始请求检索到的或通过使用来自API密钥的数据确定的所有相关联的数据重新路由到对应认证机构的服务。

第三步骤：E3

在该方法的步骤E3期间，认证机构CERT的装置30接收密钥CL以及可能的来自步骤E1或E2的相关联信息，在其数据库中识别对应于该密钥的用户，并向该用户发送提供动态代码的请求(例如，通过向该用户发送证实表单)。

该步骤E3开始于由在认证机构处为此目的而设计的接收单元可能借助于第三方服务OT接收来自SQ服务的请求。

然后，所述接收单元检索请求中包含的不同信息并对其进行分类：

a)它确定与SQ服务的标识相关的数据、或者在OT服务处注册所述SQ服务期间提供的或者直接在认证机构处提供的数据。

b)它通过分析对应的代码(例如，用于帐户创建的CRE)来确定所请求的操作类型。

c)根据所请求的交易的类型，它还检索必要的补充数据(作为非穷举性示例，对于支付请求，请求的金额)和可能的相关联的信息(例如，如果它是分期付款，则次数和在每个最后期限的金额...)。

d)它还检索密钥CL。

将该信息发送到认证机构可以通过使用各种已知的解决方案来完成，这些解决方案在此没有全部详细描述。作为非穷举性示例，该信息经由XML形式或json文件或以Post模式从第三方机构OT发送到认证机构。许多其他或多或少安全的方法是可能的。

然后，操作认证机构的装置30的查询单元，以通过查询其存储单元(例如，数据库)来确定所提供的密钥CL属于哪个用户(或别名)。通过该查询单元检索上述不同的相关联信息项。

更具体地，在这方面，检索与密钥CL的用户相关联并且在初始步骤期间为该密钥CL指示的所有特定数据(名称或别名、相关联的通信单元...)。还检索与公开授权和特别是在使用方面的各种限制相关的信息。

然后，实施验证单元，以针对特别涉及针对所述密钥CL授权的使用和使用限制的数据，检查在步骤E1和E2期间发送的数据。可能的分析和比较是已知的，并且在此不全部详述。

*作为非穷举性示例，该验证单元允许验证与密钥CL相关联的交易符码是否符合认证机构的存储单元中的针对该密钥CL授权的交易。

*根据另一示例，如果认证机构的存储单元处的密钥CL与特定站点或应用SA相关联，则该验证单元验证与密钥CL相关联并且与SQ服务相关的补充数据对应于所述站点或应用SA。

*根据又一示例，验证单元验证可能在给定时段内与所述密钥CL相关联的用户的最大支付未超出。

本领域技术人员将知道如何使用已知方式来实施上述措施，因此这里将不详细描述它们，包括：描述和/或数量的比较、在两侧(在API侧和认证机构侧)对可能的SQ服务的中央数据库的参考等。

如果由该验证单元执行的分析和比较的结果不符合预期的结果，则停止该方法，并且向SQ服务通知交易失败。

在相反的情况下，该方法继续，并且选择单元允许选择与用户的密钥CL相关联的通信细节，以及可能地相关联的通信单元，并且生成向用户发送证实表单。

根据另一可能但不太安全的变型，经由用户向SQ服务指示并且在步骤E2期间由SQ服务发送的通信细节(电子邮件、用户的移动电话号码...)进行与用户的通信。

根据一个实施例，与由SQ服务发送的请求相关的补充数据与所述发送相关联。例如，它可以是一系列信息，其在步骤E4期间允许用户接收证实表单与创建针对给定服务的帐户或连接到给定服务或为给定服务支付这样的金额的请求相关的指示，以上面已经提到的3个示例为例。

根据另一实施例，与(在认证机构的存储数据库中)与密钥CL相关联的使用限制相关的补充数据被补充到所述发送。作为非穷举性示例，如果密钥CL与特定地理区域上的使用限制相关(例如，与实体商店相关)，则它可以是检查用户的地理位置的请求。

第四步骤:E4

在步骤E4期间，用户的站点10接收提供动态生成的代码的请求。例如，在他的站(蜂窝电话、平板电脑等)处，用户可以接收并且然后完成具有由与他的密钥CL相关联的他的设备DC生成的密码代码的表单。

用户如何接收对CC的请求

认证装置有几种方式来制定其对动态代码的请求并将该请求呈现给用户，特别是在用户站(例如，蜂窝电话、PC、平板电脑)上。在下面描述的示例中，认证装置向用户站发送证实表单。应当注意，本发明不限于涉及呈现对动态代码的请求的这种方式。

接收单元允许接收证实表单和任何相关联的补充数据，然后将所述证实表单呈现给用户。许多已知的方法允许这种类型的接收和显示。

根据第一示例，用户从认证装置接收包括与表单相关的链接的电子邮件。电子邮件本身可以包含与交易相关的补充信息。

根据第二示例，用户接收来自认证装置SMS消息、包括与表单相关的链接的电子邮件。SMS消息本身可以包含与操作有关的补充信息。

根据第三示例，用户在他的即时消息传递上接收包含该表单的消息，并且可能接收与交易相关的细节。

根据第四示例，类似于在一些金融交易期间使用的证实表单，SQ服务和认证装置之间的API(可能借助于已经提到的OT服务)协作，使得证实表单被发送到SQ服务的装置，并且在用户请求之后(最多几秒)在用户已经经由其制定他的请求的设备上显示，而用户无需打开另一应用。

根据第五示例，将集成到商家服务机器人(机器人程序)中的表单发送给用户。表单可以仅包括输入区域和证实按钮。可替代地，它可以包括调用(recall)请求的上下文的文本区域(例如，请求创建关于给定服务的账户，或者请求按3个分期付款支付关于给定服务的特定金额...)。

注意，在线上支付的框架内，至少从用户的角度来看，根据本发明的方法的优点之一是消除了已知方法的最小响应时间(与代码相关联的有效期...)。与第四和第五示例的实施方式类似的实施方式特别适合于需要快速响应的请求。另一方面，如果所请求的操作容忍显著的延迟，则类似于上述示例1至3的实施方式是可能的(通过电子邮件发送...)。

对CC的请求随附对补充信息的请求

根据另一实施例，根据在步骤E4开始时与证实表单的发送一起提供的不同参数，仅在用户同意某些条件之后才显示证实表单。

作为非穷举性示例，如果对密钥CL的使用的限制与特定地理区域相关联，则所述证实表单的显示以用户同意访问他的地理位置为条件(如果它是移动电话，则激活地理定位功能...)。在拒绝的情况下，该方法因此在该阶段停止。

在同意的情况下，这样收集的信息与在证实表单上输入的数据并行发送。

可替代地，认证装置请求物理上与代码生成设备DC不同的用户终端的地理位置数据(该第二终端已经在初始阶段EP期间与用户相关联或者稍后利用认证机构更新)。根据另一变型，认证机构可以随机地请求用户站的地理位置或其他身份证明(指纹等)，所有这些都符合指南DSP2。

可替代地，在拒绝的情况下，显示所述表单，但是在步骤E4结束时不发送相关联的数据，这导致在步骤E5期间拒绝请求。

当已经向用户显示该表单时，用户可以根据在初始步骤中详述的所述设备DC的实施方式的不同变型，使用来自与他的密钥CL相关联的他的设备DC的CC代码来填写该表单。

动态生成的代码

根据现有技术，表述“动态密码”的定义是指在市面上的银行卡背面可见的称为3位数字密码代码的代码。所述代码由不包含在所述卡的磁条中的数据(在银行卡的情况下为3位数字)组成，并且通过单独提供它们来允许保护交易。

动态代码技术通过每时段(每半小时、每小时...)改变***及其密码来限制与线上黑客攻击***及其密码相关的主要风险之一：已经检索到线上支付所需的不同信息(***、到期日期和可见密码)的可能的黑客在密码变得过时之前将确实具有非常短的时间来使用这些数据。在步骤E5中说明用于随后验证所述代码的有效性的方法。

如何获得代码的第一版本CC1

作为非穷举性示例，根据最简单的实现，用户输入当前显示在他的设备DC上的CC代码。

具体地，在现有技术中，具有动态密码的银行卡集成了***该卡厚度内的电子纸屏幕(电子纸)、可以持续3年的微型电池(这些卡的使用寿命)和NFC天线。时钟驱动的微控制器每半小时生成一个密码。然后将生成的代码发送到电子纸LCD屏幕并保持显示，直到生成下一个代码，使得用户可以在任何时间读取它。

根据另一示例，用户通过按下他的设备DC中的按钮或者通过在所述设备上扫描他的指纹…(其触发设备DC对所述代码CC1的计算以及其随后在所述设备DC的显示区域上的显示)来请求显示代码CC1。

若干代码生成方法是可能的，并且描述这些方法不属于本专利申请。作为非穷举性示例，它可以是考虑若干数据(诸如***、时间戳和在卡与发行方之间共享的秘密)的密码方法，或者甚至是集成到存储器中的预先计算的密码的列表，以便降低设备的成本。

设备DC可以以各种方式实施，不仅以动态密码卡的形式，而且还可以***专用于产生代码的设备中或以非物化(dematerialized)的方式实施，例如，以从用户的至少一个个人设备DP(诸如他的PC或他的移动电话)下载的软件、代码或应用的形式，前提是所述设备具有用于根据期望的规范生成密码CC的第一子单元和用于向用户呈现/显示所述密码CC的第二子单元。

然而，根据优选实施例，该设备是与传统互联网连接单元分离的设备，并且由认证装置提供给客户。作为一个非穷举性示例，包括密码生成单元和呈现/显示单元的设备DC如此可以结合到诸如塑料卡、手表、戒指、手镯等的介质中。这些类型的介质然后必须具有允许查看当前密码代码的显示设备。这样的对象的主要优点是它们总是可以独立于用于与线上服务交互的其他单元，由用户可用的和可访问的。

操作原理依照上面已经呈现的现有技术的操作原理。

所生成的密码代码可以是字母和/或数字的序列，或者甚至包括一些特殊字符。除了使用该方法的处理的安全性增加之外，该方法的一个巨大优点在于用户侧的简化。这种简化的需要促进了选择相对短的序列，例如，在3和6位数字和/或连续字母之间的序列，如由具有动态密码的银行卡生成的代码，其限于连续的3位数字(然而，这种限制和与其他银行卡的3位数字确认代码的兼容性有关)。

触发单元

根据一个变型，CC代码的显示需要称为触发器或脉冲单元(例如，按下按钮)的工具，其启动代码的显示。

根据另一变型，除了该显示之外，所述触发工具还控制(触发)CC代码的生成。后一种变型的优点在于，除了上面已经提到的周期可变性之外(例如，即使在存在触发机制的情况下，代码每半小时改变一次)，存在由用户主动时的随机可变性。

该变型意味着需要确保由设备DC生成的代码CC1与在步骤E5期间在针对该密钥CL的设备DCC上的所述认证装置的服务器处生成的代码的第二版本CC2之间的同步。因此，问题在于，对于由设备DC触发新CC代码的生成的任何动作(例如，脉冲)，设备DCC必须被同步，使得在步骤E5中，可以在认证装置处证实CC密钥。

例如，如果用于生成CC代码的方法基于集成在与密钥CL相关的设备DC的存储器中的预先计算的密码的有序列表，在与密钥CL相关的设备DCC处具有可用的预先计算的密码的相同列表，则在用户侧DC处，驱动脉冲切换到列表的下一个密码，并且该进展(advance)必须以一种方式或另一种方式传达到DCC侧以保持同步。(另一方面，对于根据预编程周期(例如，每半小时)发生的其它CC代码改变没有影响：然后在所述密钥CL的DC和DCC之间同步地完成CC代码的进展(除了通过驱动脉冲的进展之外))。

根据第一变型，为了获得期望的同步，所述设备DC根据许多已知方式之一以一种方式或另一种方式连接到互联网网络，以便将与驱动脉冲(或另一触发动作)有关的所述信息发送到主管设备DCC的服务器。除了在DC处必要的通信单元的成本和能量消耗之外，该第一变型还涉及在安全性方面的潜在风险，因为在DC和DCC之间需要连接和认证路径。另外，返回信道也是必要的，以便验证在DCC处安全接收脉冲的确认。

根据第二变型，在步骤E5中通过特定单元管理同步。

根据第三更高级的优选变型，由于设备DC处的脉冲，为同步而预留包括在CC码中的字符序列。作为非穷举性示例，CC代码由6个字符组成，前4个字符形成密码密钥CCv，最后2个字符形成代码CCs，在步骤E5期间，代码CCs允许设备DCC确定自创建密钥CL以来产生的脉冲数。将关于步骤E5更详细地描述该变型。

这两个最后的变型使得有可能忽视由用户产生的无意脉冲，或者未被我们的方法的以下步骤的实施方式遵循的脉冲。

根据第四变型，施加2个脉冲之间的最小时间段，作为非穷举性示例，最多每3秒，该间隔能够由每单位时间的最大数量的脉冲(作为非穷举性示例，最多每分钟5个脉冲和每小时40个脉冲)完成。这些限制具有限制不想要的脉冲序列的优点(例如，为了避免与由于错误而保持激活的脉冲机构相关的问题：所述机构可以是必须被按压以产生脉冲的按钮、或者覆盖显示单元的掩模，该掩模一旦被移除就产生脉冲...)。可选地，这些最后的限制数据可以由用户针对给定密钥CL参数化。

根据第五优选变型，若干密钥CL使用相同的设备DC来生成CC码。后一种变型除了使用简单之外，还具有使潜在黑客面临的问题更加复杂的巨大优点。

简单性是清楚的，这是因为对于他的所有密钥CL，或者对于他的密钥CL的子组，用户只需要与生成和显示CC代码的单个设备交互。这种变型是可能的，因为上面已经看到，具有认证装置的账户的用户可以请求一个或多个不同的密钥CL，每个密钥CL可以与不同类型的信息相关联，这些信息可以彼此不同。

对于触发单元，许多实施方式的变型是可能的。根据我们的优选变型之一，脉冲与集成到设备DC中的指纹传感器相关，其具有允许我们的方法和***执行双重认证，提供安全性的增强并满足欧洲指令DSP2的优点，这是因为除了重新输入代码之外，用户必须通过他的指纹认证自己。在这种情况下，必须辨识指纹以便产生脉冲。因此，可以设想包括指纹传感器环的设备：拇指朝向环的移动足以将拇指的掌心放置在该环上。因此，即使在盗窃所述环的情况下，也不能操作设备DC。这些变型不仅限于指纹传感器；可以使用其他类型的生物识别传感器(例如，声纹传感器、虹膜扫描设备)。

CC代码与常规CVV代码的兼容性

注意：这些段落涉及与银行卡的CVV代码相关的我们的变型的特定使用情况。

这种场景下的问题在于需要与已经就位的线上支付方法兼容，该线上支付方法结合了与银行卡的其他数据(密钥和到期日期)相关的3位数字CVV代码的输入。如上所示，根据本发明的实施例使用的设备DC生成CC代码，该CC代码不一定由3位数字的连续组成，而是可以是例如6或8位数字和/或字母的连续。在这种情况下，默认地，我们的CC代码将与银行交易预期的3位数字CVV代码不兼容。

两种变型允许解决与已经就位的标准化***的兼容性问题。

*第一变型在于要求所述生成的代码的前3个字符是数字。为此，在设备DC处以及在认证装置侧在设备DCC处适配生成方法就足够了。

在传统的银行交易期间，用户必须限制自己输入这些前3个数字，该前3个数字可能以不同于该系列的其他字符的方式(例如，另一种颜色)显示在设备DC的屏幕上。

尽管该变型对于向用户解释稍微复杂并且减少了可用组合的数量，但是它允许非常简单地解决该问题。

*限于脉冲设备DC的第二变型消除了这两个缺点。根据该变型，用于生成所述CC代码的方法包括根据预定脉冲间隔(例如，每4个脉冲)生成数字类型的3字符代码的可能性。在这种情况下，如果当前显示的CC代码不是3位数字代码，则用户启动脉冲(最多连续3次)，直到显示3位数字CC代码。

*第三变型混合了上述2个提议：每n个脉冲，生成具有n个字符(例如，6或8)的CC代码，所述代码的前3个字符是3位数字的连串，因此其与使用CVV类型代码的方法兼容。

注意，第一变型和第三变型可能需要在步骤E5处的适配。

无论代码的第一版本CC1如何在用户侧生成，其然后发送到认证装置。根据非限制性示例，用户将代码CC1复制到呈现给他的证实表单上并证实所述表单。该证实生成证实结果的发送，即，向认证装置的自组织(ad hoc)单元传达与密钥CL相关联的所述复制的CC1代码以及可能还有相关联的补充数据。

为了确保认证，该表单可以与第三方设备(诸如例如指纹读取或虹膜分析设备)或者特定于用户并且为认证装置所知的任何其他信息(密码、对问题的响应等)组合，其中认证装置的所收集的信息可以被与步骤E4结束时描述的信息并行发送。

第五步骤:E5

然后，该方法以第五和最后一个步骤E5结束，在该步骤期间，认证机构检索从用户的设备DC接收的CC代码的第一版本CC1，然后将其与在针对所述用户的所述密钥CL的所述认证机构的服务器处生成的(或由认证机构例如从外部设备DCC获取的)第二版本CC2进行比较。认证装置比较代码的两个版本。如果两者匹配(例如，相同)，则认证装置同意该请求，否则它拒绝该请求。在所有情况下，指示比较结果的信息可能与补充信息一起被返回给SQ服务。

该步骤E5的主要操作在于验证在步骤E4中在用户侧提供的CC代码的第一版本是否符合预期的CC代码。为此，服务器或包含所述认证机构的服务器的***应该能够在步骤E4中验证由假定用户指示的密码的准确性。

为此，对于每个密钥CL，该认证机构必须具有允许在给定时间产生与CL相关联(或者与密钥CL的集合相关联，这取决于变型，根据该变型，单个对的设备DC和DCC与若干密钥CL相关联)的所述代码CCs的单元和设备DCC。

在这方面，所有都取决于用于在用户的设备DC处生成CC的方法，知道必须在DCC处使用相同的方法。下面将仅参考在步骤EP的描述期间已经提到的方法的两个非穷举性示例：

根据第一示例，预先计算的密码的列表，其中每个时间步长对密码的选择(例如，每小时切换到所述列表中的下一个代码)被记录在关于CL的存储器中，预先计算的密码的相同列表也必须在关于CL的设备DCC处可用。

根据第二示例，在动态代码生成器设备和认证机构之间共享时间戳和秘密。然后，容纳针对所述CL代码的设备DCC的服务器必须与容纳用户的设备DC的服务器完全同步(以便检索相同的时间戳)。

注意，在认证机构设备处可以使用若干方法，要知道对于给定的密钥CL将仅实施一种方法。

除了这些方法之外，对于给定的密钥CL，2个设备DC和DCC必须同步。

在设备DC的简单实施的情况下，该同步在两个设备DC和DCC的制造或编程时执行，并且之后不改变。在这种情况下，设备DCC允许重新计算与CL相关联的代码CC2，然后在步骤E4结束时将其与关于密钥CL传达的代码CC1进行比较。该比较的结果被保存于步骤E5的结束。

如在步骤EP期间所提到的，在设备DC使用脉冲工具(例如，通过按下按钮)以隔离的方式或作为对按时间步长等的演变的补充来生成CC代码的情况下，同步问题更复杂(当然，如果脉冲单元仅用于显示当前代码，因此如果它仅用于节省电池，或者在根据其脉冲与指纹或其他生物数据参数相关的变型中，用于保护显示，则没有特别的问题)。

如在步骤EP的描述期间所提到的，第一变型用以解决与使用设备DC处的任何脉冲单元在步骤E4期间生成CC码相关的同步问题，其在步骤E5期间包括特定管理单元GS。

所述单元GS的实施方式包括在第一子步骤中保存代码CC2-init及其相应的同步数据。这些同步数据取决于用于生成与密钥CL相关的所述代码CC2-init的方法。以基于预先计算的密码的有序列表的方法为例，这将是代码CC2-init在所述有序列表中的位置。

在第二子步骤期间，单元GS使用设备DCC以常规方式为所述密钥CL生成下一个代码(CC2-init)+1，然后将所述代码(CC2-init)+1与在步骤E4结束时传达的代码CC1进行比较。如果所述代码(CC2-init)+1和CC1不匹配，则不是在步骤E5结束时直接返回否定响应，而是在第三个连续子步骤n期间，单元GS生成代码(CC2-init)+i(i＝2，3，...，n)，并将其与在步骤E4结束时传达的代码CC1进行比较，直到发现匹配为止。

根据一个变型，作为非穷举性示例，连续子步骤的数量被限制为值100。因此，如果在n＝100个第三连续子步骤之后没有发现与CC1的一致性，则比较将被认为是否定的(代码CC1错误，或者设备DC有故障，从处理请求的角度来看，这给出了相同的结果)。

在第4个子步骤期间，如果认为比较是否定的，则特定管理单元GS在代码CC2-init处重新同步针对密钥CL的设备DCC。

如果在第2个、或第3个连续子步骤之一期间认为比较是肯定的，则特定管理单元GS在找到匹配的代码(CCS-init)+i处重新同步针对密钥CL的设备DCC。该比较的结果被保存于步骤E5的结束。

如在第四步骤的描述期间所提到的，第二变型用以解决在用户侧使用设备DC处的任何脉冲单元生成CC码相关的同步问题，其包括集成到CC码中的子代码CCs。该代码CCs可以例如包括2个数字或字母数字字符的序列或者3个数字或字母数字字符的变型(除此之外，用户在该方法的步骤E4中重新输入代码将花费很长时间)。

根据第一简化变型，代码CCs是在密钥CL的创建期间从起始点开始的预定义的时间先后(chronological)顺序的简单序列。例如，序列将以代码J8v开始，并且时序(chronology)将是：

*对于第1个字符：从J(从起始点起的第1个字符)直到返回到I的字母顺序，然后从7升序直到返回到6，然后从s反转字母顺序直到返回到t。

*对于第2个字符：从8降序直到返回到9…。

对于第3个字符以此类推。

根据该变型，该信息也在创建所述密钥期间(或者如果所述设备DC和DCC对于若干密钥是公共的，则在创建第一密钥CL期间)在与密钥CL相关的设备DC和DCC上被实施。在这种情况下，重新同步被使用类似单元GS但与代码CCs相关，以与针对上述第一变型所指示的方式类似的方式执行。

这样的实施方式允许基于由数字或字母组成的3个字符的序列来管理大约175,000个不同的脉冲，排除可能导致数字和字母之间混淆的那些。然而，检查允许通过检测返回到起始点来增加该容量。尽管用户可以容易地识别代码CCs的序列的可能性相对较高，但是代码CCv仍然是不可预测的。

可替代地，所述代码CCs可以以与代码CCv完全类似的方式通过用于生成代码CCs的可能方法(对于代码CCv和代码CCs可以实施两种不同的方法)之一来管理。在这种情况下，重新同步使用类似工具GS但与代码CCs相关，以与针对上述第一变型所指示的方式类似的方式来执行。

注意，为了提高安全性，代码CCv和CCs可以在设备DC和DCC上显示期间混合。例如，对于6个字符的整个序列，代码CCv显示在第2、第3和第6个字符上，而代码CCs显示在第1、第4和第5个字符上。该信息当然必须在设备DCC处是已知的，以便既执行重新同步又验证在步骤E4中输入的代码与预期代码之间的一致性。

仍然为了提高安全性，根据某些实施例，代码CCs和CCv保存在始终与相应的密钥CL(或密钥CL的集合)相关的2个单独的服务器上。在这种情况下，特定单元GS在容纳CL结合代码序列CCs的服务器处实施，并且当已经执行同步时，结果被发送到保存CCv的服务器，以检查与相同密钥CL相关的CCv。一旦进行了比较，则所述比较的结果被保存于步骤E5的结束。

在否定比较结果的情况下，关于拒绝操作或交易的信息被返回到请求SQ服务，可选地，后者具有通知用户的责任。

在肯定比较结果的情况下，还可以执行多个特定处理操作以证实或不证实操作。

作为非穷举性示例，如果与密钥CL相关联的信用量(可能在所述密钥CL的级别定义的时隙内)与购买量兼容，则将同意与线上购买相关的操作。如果不是这种情况，则将关于拒绝操作或交易的信息返回到请求SQ服务，可选地，后者具有通知用户的责任。如果是，则与CL相关联的所述信用量按照购买量记入借方。

根据另一非穷举示例，如果对密钥CL的使用的限制与特定地理区域相关联，则专用单元验证地理位置数据是否确实已经在步骤E4结束时作为对由用户输入的CC代码的补充而被传达，并且如果是，则它们是否对应于授权的地理位置区域。如果不是这种情况，则将关于拒绝操作或交易的信息返回到请求SQ服务，可选地，后者具有通知用户的责任。用于验证地理位置(或指纹...)的单元可以在用户的另一终端上实施。

如本领域技术人员将理解的，许多其他补充检查是可能的，并且为了简洁起见，这里没有详细描述它们中的全部。

如果所有检查都是肯定的，则将关于对操作或交易的证实(或对操作或交易的同意)的信息返回到请求SQ服务，可选地，后者具有通知用户的责任。

根据一个变型，除了该证实/协议信息之外，并且取决于操作类型和与密钥CL相关联的公开授权，补充信息由认证机构CERT传达到SQ服务。

例如，对于帐户创建和/或帐户连接/登录，与该帐户相关联的数据，诸如与CL相关联的姓氏或别名、名字、电子邮件等，被返回到SQ。SQ服务的优点之一是，即使在数据库已经被黑客攻击的情况下，如果SQ本身没有存储该数据，则潜在的黑客也不能访问该数据。该SQ服务不需要向诸如CNIL(国家信息和自由委员会)的机构发表声明，因为该服务不保存个人数据。与GDPR(通用数据保护条例)相关的要求也被大大简化，因为所涉及的SQ服务不存储任何个人数据。

根据另一示例，在操作之后用户账户中剩余的信用量被返回到SQ服务(例如，如果该SQ服务是金融服务并且操作是转账等)。

可能释放的各种各样的补充信息根据利用密钥CL执行的操作的类型和公开授权而变化很大。

在后续连接期间，用户可以以经典方式登录他的帐户(例如，电子邮件+密码)，但是他将总是通过密码接收证实请求：为此，SQ在其数据库中搜索与其所述帐户相关联的密钥，然后查询认证机构(连续步骤E2至E4)。因此，如果SQ服务确保用户的标识符的唯一性，则后者甚至将不再需要密码，输入与他的密钥相关联的CC代码就足够了。

可替代地，用户可以使用他的密钥CL登录帐户(但他必须记住它)。

相同的过程可以用于支付。

参考图4，下面将描述根据本发明的一个实施例在用户站处实施的方法的步骤。

该方法包括第一步骤E1a，从用户站的观点来看，第一步骤E1a包括从与由认证机构发出的密钥(CL)相关联的用户(U)制定实施与服务提供商装置的操作的请求的步骤(F30a)。可以在类似于上述步骤的初始步骤EP期间完成将密钥CL分配给用户。然后，存在由用户站接收(F60a)意图针对与密钥(CL)相关联的用户的对于动态代码的请求的步骤，该请求由认证机构的装置发送。接着是由用户动态代码生成设备生成动态代码的第一版本(CC1)的步骤(F70)和将动态代码的第一版本(CC1)发送到认证装置的步骤(F80)。在该方法结束时，存在从服务提供商装置接收(F110)确认所请求的操作的实现的消息的步骤。

可以认为，步骤F60a是类似于上述步骤E3的步骤E3a的一部分，并且步骤F110是类似于上述步骤E5的步骤E5a的一部分。因此，应当理解，上面关于步骤EP、E1和E3至E5阐述的说明和变型通常也适用于图4的步骤EP、E1a、E3a、E4和E5a。

参考图5至图7，呈现了图1的***1的主要元件的架构的示例。图5至图7表示适配于构造用户站10、服务提供商装置20和认证装置30的功能模块，要知道实际上所描述的功能通常使用来自计算机程序的指令而不是使用物理模块来实施。此外，本领域技术人员将理解，功能模块的数量可以与图5至图7中表示的功能模块的数量不同。换句话说，一些模块的功能可以分布在增加数量的模块上，并且/或者单个模块可以累积若干所表示的模块的功能。

在这里描述的实施例中，用户站10可以包括图5中表示的功能模块。根据该示例，用户站10包括用于生成动态代码的设备12和用于向认证装置发送由动态代码生成器设备12产生的代码的模块14。该站还包括：用户接口15，用户可以经由该用户接口15制定实施与服务提供商装置的操作的请求；第一接收模块17a，意图从认证机构的装置30接收对动态代码的请求；以及第二接收模块17b，意图从服务提供商装置接收确认所请求的操作的实现的消息。如图5所示，第一接收模块17a和第二接收模块17b可以集成到单个模块。

可选地，用户站10可以包括致动单元15a和生物识别数据传感器16。在图5所示的示例中，致动单元15a形成用户接口15的一部分。根据一些实施例，动态代码生成设备12被配置为响应于用户的动作(特别是集成到用户接口15中的致动单元15a的致动)而生成新代码。然后，生物识别数据传感器16被布置为在用户的动作期间获得用户的生物识别数据，该动作触发新代码的生成。然后，代码发送模块14被配置为仅在生物识别数据传感器16证实在用户的所述动作期间检测到的生物识别数据的情况下才将有效代码发送到认证装置。

在这里描述的实施例中，服务提供商装置20可以包括图6中表示的功能模块。根据该示例，服务提供商装置20包括：用于从用户U接收实施操作的请求的模块22；用于(向认证装置)发出证实所请求的操作的请求的模块24，所述请求指示与用户U相关联的密钥CL；以及用于在从认证装置接收到证实信号之后实施所请求的操作的模块26。

在这里描述的实施例中，认证装置30可以包括图7中表示的功能模块。根据该示例，认证装置30包括：用于发出意图针对分配给与所述密钥(CL)相关联的用户的动态代码生成器设备的对于动态代码的请求的模块34。认证装置30还包括：用于接收由用户侧上的动态代码生成器设备GC生成的动态代码的第一版本CC1的模块35；用于获取动态代码的第二版本CC2的模块37；用于比较动态代码的第一版本CC1和第二版本CC2的模块38；以及用于当动态代码的第一版本(CC1)和第二版本(CC2)匹配时向服务提供商装置20发送证实信号的模块39。用于获取动态代码的第二版本CC2的模块37可以对应于动态代码生成器设备GCC。认证装置还可以包括：用于检索与从服务提供商装置接收的密钥CL相关联的用户的数据的模块32，其意图例如检索上述验证数据。

如上所述，在特定实施例中，保护方法的不同步骤由意图在服务提供商装置、认证装置和用户站中或更一般地在计算机中实施的计算机程序指令来确定。通常，这样的计算机包括图8中表示的元件，也就是说，处理器CPU、通信接口I/O、只读存储器ROM、随机存取存储器RAM和管理计算机(未示出)处的显示的模块DISP，这些部件通常经由总线连接。当然，也可以存在其他常规部件。

应当理解，在不脱离本发明的情况下，可以对上述实施例进行各种修改。

例如，根据本发明的特定实施例，不执行该方法的步骤E1。设备SQ通过请求证实操作来从第二步骤E2发起该方法。该变型可以在许多使用情况(作为非穷举示例，包括反垃圾邮件***，无论是经由SMS、经由电子邮件还是通过电话)中示出。在这种情况下，所述SQ服务不具有客户的细节，而是仅具有密钥CL，其中用于联系客户的不同单元可能与所述密钥CL相关联(例如，客户同意通过电子邮件和SMS联系，但是不提供相应的细节)，并且可能地，如果用户已经在初始步骤中被授权了针对每个单元的时隙和/或每时隙的最大联系数量的相应公开。

现在参考图9描述根据本发明的一个实施例的由反垃圾邮件***实施的方法的一个示例。

根据图9的示例，服务提供商SQ通过请求(F35)认证装置向与密钥CL相关联的用户U发送消息(例如，电子邮件的联系人)来发起该方法。服务提供商SQ的请求REQ_OP由服务提供商装置20发出，并且标识目标用户的密钥CL。可以认为该步骤F35对应于上述步骤E2的变型E2b。在上述步骤E3的变型E3b期间，认证装置30检索(F50b)关于与由服务提供商装置提供的密钥CL相关联的用户的数据，例如，标识用户的细节的数据和可以被表征为反垃圾邮件参数的验证数据。

认证机构CERT验证根据服务提供商SQ的请求向用户发送消息是否符合与和密钥CL相关联的用户相关联的反垃圾邮件参数。例如，认证机构验证SQ服务是否形成出现在发送授权列表中的授权服务的一部分，该发送授权列表是用户已经在初始步骤中关于所涉及的密钥CL以及可能的相关条件(每时段的呼叫和/或SMS/电子邮件的数量......)指示的。该方法正在进行并且直接从步骤E3b切换到步骤E5b，而无需在步骤E3b结束时向用户发送证实表单。在认证装置的肯定确定的情况下，认证机构同意发送，并且电子邮件/SMS…TX_MES在遵守用户的匿名性的同时被发送/重新路由(F100b)。

可以执行电子邮件、SMS...的最小格式化。例如，服务提供商装置可以根据讨论中的API的预定义制定，请求认证服务启动具有变量名字然后姓氏的消息，并且如果认证装置同意将消息发送给用户，则认证装置用对应的数据(如果它们被持有)替换名字然后姓氏变量。

根据该实施例的一个变型，如果SQ服务不包括在发送授权列表中，则认证机构CERT向用户发送寻求他同意将服务提供商SQ添加到授权向他发送消息的服务列表中的特定请求。为此，认证装置在步骤E3b结束时发送(F60b)证实表单TX_FRM，并且执行步骤E4的变型E4b。在这种情况下，用户在步骤E4b期间可以在表单上通过输入机密代码CC来证实将SQ服务添加到授权服务列表的请求，或者拒绝它。用户站将其响应U_REP发送到认证装置(F80b)。在根据步骤E4b的响应，步骤E5b正常进行将SQ添加到与CL和对应的发送相关的发送授权，或者发布拒绝。

作为该实施例的变型，步骤E4b中的证实表单包括补充信息的可选输入，其类型为：在一个或多个预定义时隙上的永久授权、同意的联系人的数量等。另外，如已经针对初始步骤所指示的，用户可以在他认证机构的账户上在任何时间修改针对他的密钥CL的授权，包括是否被给予相关的SQ服务的发送授权。

在本发明的一些实施例的上述描述中，一些说明涉及密钥CL从服务提供商装置到认证装置的发送。应当回想起，来自服务提供商装置的消息可以通过第三方机构OT传送。

Claims (15)

1.一种用于保护操作的方法，其特征在于，所述方法包括：

-由与由认证机构发出的密钥(CL)相关联的用户(U)制定实施与服务提供商装置(20)的操作的请求的步骤(F30a)；

-由用户站接收由服务提供商的装置(30)发出的、意图针对与所述密钥(CL)相关联的用户的对于动态代码的请求的步骤(F60a)；

-由与所述用户的所述密钥(CL)相关联的动态代码生成器设备(12)生成所述动态代码的第一版本(CC1)的步骤(F70)；

-将所述动态代码的所述第一版本(CC1)发送到认证装置(30)的步骤(F80)；以及

-在所述动态代码的所述第一版本(CC1)对应于在所述认证机构处生成的所述动态代码的第二版本的情况下，从所述服务提供商装置接收确认所请求的操作的实现的消息的步骤(F110)。

2.根据权利要求1所述的用于保护操作的方法，其特征在于，由所述动态代码生成器设备生成所述动态代码的所述第一版本(CC1)是由所述用户的动作触发的。

3.根据权利要求2所述的用于保护操作的方法，其特征在于，所述用户的生物识别数据在触发代码的生成的所述用户的动作期间被检测，并且仅在检测到的生物识别数据被证实的情况下才发生将所述动态代码的所述第一版本(CC1)发送到所述认证装置(30)的步骤(F80)。

4.根据权利要求1至3中任一项所述的用于保护操作的方法，其特征在于，所述动态代码包括子代码(CCs)，并且所述动态代码的演变包括所述子代码的每个字符根据相应规则的渐进变化。

5.根据权利要求4所述的用于保护操作的方法，其特征在于，所述子代码的字符分布在所述动态代码的其他字符之中。

6.一种用户站(10)，其特征在于，所述用户站包括：

-被配置为允许与由认证机构发出的密钥(CL)相关联的用户(U)制定实施与服务提供商装置(20)的操作的请求的用户接口(15)；

-意图用于从所述认证机构的装置(30)接收意图针对与所述密钥(CL)相关联的用户的对于动态代码的请求的第一接收模块(17a)；

-用于向所述认证装置发送由与所述用户的所述密钥(CL)相关联的动态代码生成器设备生成的所述动态代码的第一版本的模块(14)；以及

-意图用于在所述动态代码的所述第一版本(CC1)对应于在认证机构侧生成的所述动态代码的第二版本的情况下，从所述服务提供商装置接收确认所请求的操作的实现的消息的第二接收模块(17b)。

7.根据权利要求6所述的用户站，其特征在于，所述用户站包括：

-用于由所述用户激活以触发由所述动态代码生成器设备生成代码的致动模块(15a)，以及

-生物识别数据传感器(16)；

其中

-所述生物识别数据传感器(16)被布置为当所述致动模块(15a)被所述用户激活时获得所述用户的生物识别数据，以及

-代码发送模块(14)被配置为仅在在由所述用户对所述致动模块(15a)的所述激活期间由所述生物识别数据传感器(16)检测到的生物识别数据有效的情况下，才将所述代码的所述第一版本发送到所述认证装置。

8.一种用于保护操作的***，其特征在于，所述***包括服务提供商装置(20)和认证装置(30)，其中：

所述服务提供商装置(20)包括：

-用于从用户(U)接收实施操作的请求的模块(22)，

-用于向所述认证装置发出证实所请求的操作的请求的模块(24)，所述请求指示与所述用户(U)相关联的密钥(CL)，以及

-用于在从所述认证装置接收到证实信号之后实施所请求的操作的模块(26)；以及

所述认证装置(30)包括：

-用于发出意图针对与所述密钥(CL)相关联的用户的动态代码请求的模块(34)，

-用于接收由分配给与所述密钥(CL)相关联的用户的动态代码生成器设备生成的动态代码的第一版本(CC1)的模块(35)，

-用于获取所述动态代码的第二版本(CC2)的模块(37)，

-用于比较所述动态代码的所述第一版本(CC1)和所述第二版本(CC2)的模块(38)，以及

-用于当所述动态代码的所述第一版本(CC1)和所述第二版本(CC2)匹配时发送指示对所述操作的证实的信号的模块(39)。

9.一种用于保护操作的方法，其特征在于，所述方法包括：

-由用户(U)请求实施与服务提供商装置(20)的操作的步骤(F30)；

-由所述服务提供商装置(20)向认证装置(30)发出证实所请求的操作的请求的步骤(F40)，所述请求指示与所述用户(U)相关联的密钥(CL)；

-从所述认证装置(30)发出意图针对与所述密钥(CL)相关联的用户的对于动态代码的请求的步骤(F60)；

-由分配给与所述密钥(CL)相关联的用户的动态代码生成器设备(12)生成所述动态代码的第一版本(CC1)的步骤(F70)；

-将所述动态代码的所述第一版本(CC1)发送到所述认证装置(30)的步骤(F80)；

-由所述认证装置(30)获取所述动态代码的第二版本(CC2)并比较所述动态代码的所述第一版本和所述第二版本的步骤(F90)；以及

-在所述动态代码的所述第一版本(CC1)和所述第二版本(CC2)匹配的情况下，由所述认证装置(30)向所述服务提供商装置(20)发送指示对从所述用户(U)请求的操作的证实的信号的步骤(F100)。

10.根据权利要求9所述的用于保护操作的方法，其特征在于，发出证实所述操作的请求的所述步骤(F40)包括发出包括关于所请求的操作的信息的请求，并且所述方法包括检索与所述密钥(CL)相关联的所述用户的数据的步骤(F50)，所述数据检索步骤包括：

-检索验证数据，所述验证数据指示与所允许的操作有关的至少一个限制，以及

-分析接收到的关于所请求的操作的信息，以便与所述验证数据相关地确定该操作是否被允许。

11.根据权利要求10所述的用于安全操作的方法，其特征在于：

-检索验证数据的步骤包括检索定义从包括以下各项的组中选择的至少一个限制的数据：

-允许的操作的类型，

-在其中操作被允许的时间段，

-在其中或从其中操作被允许的地理区域，

-在其中操作被允许的服务提供商，以及

-与操作的实现相关联的价格。

12.根据权利要求11所述的用于保护操作的方法，其特征在于，所述方法还包括由所述用户参数化由所述验证数据定义的限制的步骤。

13.根据权利要求9至12中任一项所述的用于保护操作的计算机化方法，其特征在于，所述方法包括：如果所述动态代码的所述第一版本(CC1)和所述第二版本(CC2)不对应于所述认证装置(30)，则实施包括以下操作的迭代过程的步骤：获取所述动态代码的新版本，将所述新版本与所述动态代码的所述第一版本(CC1)进行比较，以及只要所述比较的结果是否定的并且直到已经获取了所述代码的n个版本并且将其与所述代码的所述第一版本进行比较，重复所述迭代过程的所述步骤。

14.根据权利要求9至13中任一项所述的用于保护操作的方法，其特征在于，由所述认证装置(30)发出对于动态代码的请求的步骤(F60)包括：向所述用户的站发送对补充信息的请求，并且由所述认证装置(30)对所述操作的证实以由所述用户站提供的所述补充信息为条件。

15.根据权利要求10所述的用于保护操作的方法，其特征在于：

-实施操作的所述请求(REQ_OP)由所述服务提供商装置制定，并且包括向与所述密钥(CL)相关联的所述用户发送消息的请求；

-由所述认证装置(30)检索与所述密钥(CL)相关联的所述用户的数据的步骤(F50b)包括检索指示所述用户的反垃圾邮件参数的检查数据并检索所述用户的细节；

-省略发出对于动态代码的请求和生成动态代码的所述第一版本和所述第二版本的步骤；以及

-发送指示对所请求的操作的证实的信号的步骤(F100b)包括：当所述认证装置发现所述消息的发送与所述用户的反垃圾邮件参数兼容时，根据由所述认证装置检索的所述细节将所述消息(TX_MES)发送给所述用户。

Images