Method and system for autonomous triggering operations

Abstract

The present invention relates to a method comprising: detecting, based on contextual data relating to an interaction between a user and a software application, an implicit intent of a user to trigger an action related to a product or service; based on the detection, making a decision on behalf of the user to autonomously trigger the action without prior request for explicit consent from the user; sending a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including contextual data and information about the detected action; receiving from the risk analysis module an indicator indicating a risk level that the user's intent is not to trigger the detected action; and making a decision, at least based on the indicator, to determine whether the action is authorized.

Description

Technical Field

[0001] This specification relates to a method and system for autonomously triggering at least one operation, as well as a risk analysis method. Background Technology

[0002] When a user interacts with a software application (e.g., a web application or a mobile application), different types of virtual assistants can be used to assist the user in performing actions that may correspond to their needs and / or automatically suggest actions that may correspond to their needs or desires.

[0003] These virtual assistants are based on machine learning systems and can interact with users to, for example, facilitate and simplify the use of software applications or automate tasks.

[0004] However, these virtual assistants may have limited decision-making capabilities, such as the inability to respond to users' ever-changing needs in real time.

[0005] In addition, these virtual assistants may be designed with goals that may conflict with the user’s actual needs or intentions (e.g., business objectives).

[0006] Furthermore, these limitations or drawbacks may lead to trust and / or security issues with the actions performed by these assistants.

[0007] There is a need to improve the user experience when interacting with software applications associated with virtual assistant functionality, while providing a high level of security for triggering actions. Summary of the Invention

[0008] The scope of protection claimed is defined by the claims.

[0009] According to a first aspect, this specification relates to a method comprising: detecting, based on contextual data relating to an interaction between a user and a software application, an implicit intent of a user to trigger an action related to a product or service; based on the detection, making a decision on behalf of the user to autonomously trigger the action without prior request for explicit consent from the user; sending a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including contextual data and information about the detected action; receiving from the risk analysis module an indicator indicating a risk level that the user's intent is not to trigger the detected action; and making a decision, at least based on the indicator, to determine whether the action is authorized.

[0010] In one or more embodiments, detection includes identifying an action to be triggered, for example by identifying the product and / or service involved in the action to be triggered.

[0011] In one or more implementations, detection includes identifying the product and / or service to which the implicit intent of the user to trigger an action has been detected.

[0012] In one or more implementations, risk level quantification addresses the risk of errors when identifying actions to be triggered and when the user consents to (or intends to) trigger an action.

[0013] In one or more embodiments, the operation is a payment transaction for purchasing at least one product and / or at least one service.

[0014] In one or more implementations, the risk level considers whether the purchase appears to meet the user's needs (or expectations) and whether the user's intention is to continue making payments.

[0015] In one or more embodiments, the calculation of risk level and risk level take into account, on the one hand, consent to the identified demand (e.g., by identifying the operations to be performed and the products and / or services involved) and on the other hand, consent to payment.

[0016] In one or more implementations, the risk level takes into account the user’s consent to the demand identified by identifying the product or service to be purchased and the user’s consent to trigger payment.

[0017] In one or more implementations, detection includes identifying a user’s needs (or expectations) by identifying the action to be triggered and / or identifying the product and / or service involved.

[0018] In one or more implementations, when an operation is authorized, a notification is sent to the computer system to trigger the execution of the operation.

[0019] In one or more implementations, when an operation is not authorized, a notification is sent to the computer system to trigger the execution of the operation.

[0020] In one or more implementations, when the indicator is below a first threshold and above a second non-zero threshold, an explicit verification request is sent to the user to trigger an operation; When the indicator is higher than the first threshold, a notification is sent to reject the operation; When the indicator falls below the second threshold, a notification is sent to the computer system to trigger the execution of the operation.

[0021] In one or more embodiments, the method includes: obtaining at least one configuration parameter, the at least one configuration parameter defining a permission granted by a user to a software application to trigger an operation on behalf of the user; and configuring the software application based on the configuration parameter.

[0022] In one or more embodiments, the software application is or includes a virtual assistant, and the context data includes the content of the interaction with the virtual assistant.

[0023] In one or more implementations, risk levels are determined based on transcribed excerpts of text content from conversations and / or interactions with the virtual assistant, and scores assessed on those excerpts.

[0024] In one or more implementations, the analysis request includes at least one of the following: information about the user profile, information about user preferences, information about user usage, information about product or service recommendations, and information about the history of actions triggered by the user.

[0025] In one or more embodiments, the operation is a payment transaction for purchasing at least one product and / or at least one service, and the notification is a payment notification, which may include, for example, a payment token.

[0026] In one or more implementations, the risk level considers whether the purchase appears to meet the user's needs (or expectations) and whether the user's intention is to continue making payments.

[0027] According to another aspect, this specification relates to a system including a computing component for implementing the method according to the first aspect.

[0028] The computing component may include software and / or hardware components, such as electronic components. These electronic components may include, for example, one or more circuits configured to perform one or more or all of the steps in the method according to the first aspect. The electronic component may include, for example, at least one processor and at least one memory, the at least one memory including program instructions configured to, when executed by the processor, cause the device to perform one or more or all of the steps in the method according to the first aspect.

[0029] According to another aspect, this specification relates to a storage medium readable by a data processor, the storage medium storing a program including program instructions configured to cause the data processor to perform one or more or all of the steps of the method described according to the first aspect.

[0030] According to another aspect, this specification relates to a computer program comprising program instructions configured to cause a data processor to perform one or more steps or all of the steps described in accordance with the first aspect.

[0031] According to the second aspect, this specification relates to a method comprising: receiving, by a machine learning-based risk analysis module, contextual data relating to an interaction between a user and a software application, and information about an action related to a product or service intended to be performed, which has been identified based on the contextual data, from a verification entity; generating, by the risk analysis module, an indicator representing a risk level indicating that the user's intent is not to trigger the identified action; and sending the indicator to the verification entity.

[0032] According to another aspect, this specification relates to an apparatus including a computing component for implementing the method according to the second aspect.

[0033] The computing component may include software and / or hardware components, such as electronic components. The electronic components may include, for example, one or more circuits configured to perform one or more or all of the steps in the method according to the second aspect. The electronic components may include, for example, at least one processor and at least one memory, the at least one memory including program instructions configured to, when executed by the processor, cause the device to perform one or more or all of the steps in the method according to the second aspect.

[0034] According to another aspect, this specification relates to a storage medium readable by a data processor, the storage medium storing a program including program instructions configured to cause the data processor to perform one or more or all of the steps of the method according to the second aspect.

[0035] According to another aspect, this specification relates to a computer program comprising program instructions configured to cause a data processor to perform one or more or all of the steps of the method according to the second aspect. Attached Figure Description

[0036] Referring to the accompanying drawings, further features and advantages will become apparent from the following detailed description based on illustrative and non-limiting embodiments and examples.

[0037] Figure 1 A system for triggering operations according to an example implementation is illustrated schematically.

[0038] Figure 2 This is a flowchart illustrating a system and method for triggering operations according to an example implementation.

[0039] Figure 3 This is a schematic diagram illustrating a system and method for triggering operations according to an example implementation.

[0040] Figure 4This is a schematic diagram illustrating a system and method for triggering operations according to an example implementation.

[0041] Figure 5 This is a diagram illustrating the system and method for triggering operations according to an example implementation.

[0042] Figure 6 This is a flowchart of a method for triggering an operation based on an example implementation.

[0043] Figure 7 This is a flowchart of the risk analysis method based on the example implementation plan.

[0044] Figure 8 This is a flowchart of the risk analysis method based on the example implementation plan.

[0045] Figure 9 This is a flowchart of the risk analysis method based on the example implementation plan. Detailed Implementation

[0046] Various embodiments will now be described in more detail with reference to the accompanying drawings. The specific structural and / or functional details disclosed herein are intended to provide an understanding of the various possible embodiments. However, those skilled in the art will understand that the exemplary embodiments are subject to various modifications and can be implemented without all of these details.

[0047] This specification relates to methods and systems that allow the automatic triggering of one or more actions based on contextual data during user and software application interaction without any explicit verification action from the user prior to the triggering. More specifically, in the context of this document, the execution of "autonomously triggered" actions will be referred to.

[0048] The operation to be performed can be any operation, whether simple or complex. Examples of operations include transactions (e.g., bank transactions, payment transactions), product or service purchases, message and / or data or document sending, access to one or more multimedia content items, transmission of one or more multimedia content items, access to user accounts, generation of signed documents, etc.

[0049] The operation to be performed can be provided by the user through the software application and the service provider with whom they interact.

[0050] The software application itself can be a virtual assistant, or include virtual assistant functionality, or be associated with a virtual assistant.

[0051] In one or more implementations, the action to be performed is triggered without any explicit verification action from the user: the user's intent to perform the action is detected based on contextual interaction data, but no explicit action from the user is required to precisely express his consent or confirm his intent: here the user's consent is considered implicit.

[0052] In one or more implementations, the detection and / or identification of the operation to be performed can be performed by a machine learning (ML)-based virtual assistant with which the user interacts. The virtual assistant can be included in or associated with a software application with which the user also interacts, or can be independent of the software application with which the user also interacts.

[0053] In the context of this document, a “virtual assistant” is any software component configured to assist a user when interacting with a software application or system. Such a virtual or digital assistant can be a personal digital assistant or any software component with user-assistive capabilities that can make requests to the user (e.g., in a connected object).

[0054] In one or more implementations, to ensure this autonomous triggering mode, a confidence level is calculated regarding whether the user's intent is actually to trigger an action, in order to quantitatively assess the risk of error regarding the user's intent. This confidence level is also the risk level of the user's intent not being to trigger an action.

[0055] The risks assessed here involve the identification of the user's desired action and the fact that consent has been given. This risk is technical in nature and relates to the technological limitations of AI and machine learning-based software solutions (particularly virtual assistants) in identifying the action to be triggered and obtaining consent. It should be understood that this self-triggered nature of the transaction may give rise to other types of risks, such as legal risks, but these were not assessed by the risk analysis module.

[0056] There are many potential applications. This solution can be used, for example, in all digital marketplaces to perform operations including purchases and / or payments: in these digital marketplaces, ease of use, speed, and security of interaction and payments are of paramount importance.

[0057] This solution can also be used in all industries where tasks and processes require a high degree of digital automation, such as manufacturing or other products and logistics.

[0058] In addition, virtual assistants can be designed to help consumers in their daily lives, for example by helping them track their tasks, make purchases, and manage their schedules using simple, natural interactions.

[0059] Therefore, this solution is suitable for a wide range of applications that require frictionless, efficient, and even personalized digital services that are based on autonomous decision-making to trigger actions based on contextual interaction data without requiring explicit consent from the user.

[0060] In one or more implementations, the system allows for consideration of various contextual data related to the interaction context for autonomously triggering decisions.

[0061] For example, contextual data may include conversations with the virtual assistant (including text, images, or audio of the conversations) and / or information about interactions with the virtual assistant and / or software applications.

[0062] For example, contextual data may include a user profile (preferences, name, place of residence, etc.) and / or information related to the user's usage (habits, history of actions performed by the user, etc.). A user profile may be a profile registered with the service provider where the user uses the software application and interacts with it.

[0063] For example, contextual data may include data about the user's environment at the time of interaction (e.g., geographic location, country, temperature, weather, etc.).

[0064] For example, contextual data can include information about the general context of the interaction, such as date, time, day of the week, month, season, etc.

[0065] In this way, the system allows for transparent triggering of operations, taking into account user needs and habits, hyper-automation, and interaction via virtual assistants and natural, intuitive user interfaces.

[0066] The system provides end users with an interactive system that delivers a smooth experience through seamless execution of operations.

[0067] The system reduces friction associated with operations such as payments, which typically require continuous data input. In the specific case of a payment, the system can evaluate the interaction context to determine the legitimacy of triggering the payment and avoid requiring explicit user consent when the risk of error is sufficiently low (e.g., below a given threshold). This risk analysis thus provides additional security. It avoids requesting explicit user consent when the risk of error is sufficiently low and avoids triggering the operation when the risk is too high.

[0068] In one or more implementations, the risk assessment associated with the autonomous triggering decision is performed by a machine learning (ML)-based risk analysis module configured to perform analysis of the interaction context in order to quantify the risk associated with the action to be performed by the autonomous triggering and to calculate the risk level.

[0069] Based on the risk level, it can be determined whether explicit consent from the user can be disregarded, or if not, in cases where the transaction is refused to be executed when the risk exceeds a threshold, whether conventional methods can be used to obtain explicit consent and / or request the user's authentication (or re-authentication) before the execution of the authorized transaction.

[0070] This solution makes the user experience simpler and smoother because the user does not need to perform any authentication actions when the assistant makes the payment autonomously, unless the risk is assessed as too high and the transaction is rejected, in which case strong authentication and / or explicit user verification may be required.

[0071] Strong authentication means authentication based on verification using at least two different types of authentication factors. There are three types of authentication factors: - Biometric factors (based on biometric data); - Knowledge factors (based on secret information known only to the user); - Ownership factor (based on the use of user-owned hardware devices).

[0072] In one or more implementations, the software application and / or virtual assistant can be parameterized, allowing the user to grant the software application and / or virtual assistant permissions to trigger actions on behalf of the user, and to configure these permissions.

[0073] For example, users can authorize or deny the autonomous virtual assistant to make autonomous triggering decisions, and configure autonomous virtual assistant parameters based on their requirements and / or preferences for autonomous triggering operations. These parameters include, for example: one or more authorized (or correspondingly prohibited) service providers, the nature of the products or services that can be autonomously triggered, the maximum number of authorized transactions per time period, and the maximum amount to be paid if the operation is charged, etc.

[0074] Figure 1 A system 100 for triggering operations according to an example implementation is illustrated schematically.

[0075] The system includes a software application 110 associated with or comprising the virtual assistant 120. The software application 110 (and / or the virtual assistant 120) communicates operationally with a service provider's computer system 130, which provides operations related to one or more products and / or one or more services, for example, via a catalog.

[0076] Software application 110 (or more specifically, virtual assistant 120) is configured to detect implicit intent (not explicitly expressed by the user) of the user to trigger an action related to the product or service based on contextual data related to the interaction between the user and the software application.

[0077] Software application 110 (or more specifically, virtual assistant 120) is configured to make decisions on behalf of the user and request the triggering of detected actions based on detections, without prior explicit consent from the user. The trigger request can be transmitted to the service provider's computer system 130. Verification entity 150 is configured to receive a request for a decision on whether to authorize or deny an operation from service provider's computer system 130 (or directly from virtual assistant 120). In the example where the virtual assistant is a service provided by the service provider, or in the example where the verification entity also provides a virtual assistant, verification requests can be received directly from virtual assistant 120 without going through service provider's computer system 130.

[0078] Verification entity 150 is configured to send a risk analysis request to machine learning-based error risk analysis module 160. The risk analysis request may include contextual data collected by the virtual assistant and information about the detected action.

[0079] Computer system 180 is configured to perform one or more operations. Computer system 180 may be part of, linked to, or a third party's computer system 130 involved in performing the operations to be performed. In the case where the operation to be performed is a payment transaction, computer system 180 may include a payment gateway configured to make decisions and process the payment transaction.

[0080] When the verification entity 150 determines that a transaction is authorized based on the risk level, the verification entity 150 sends a notification to the computer system 180, causing the computer system 180 to execute the authorized transaction.

[0081] To provide a more concrete idea of ​​how the system works and to illustrate its possibilities, we will combine Figures 3 to 5 Several examples are described in detail, where the operation is a payment transaction: such transactions require a high degree of security. Figures 3 to 5 These implementation schemes can be extended to any other operation.

[0082] Figure 2 A system 200 for triggering operations for executing payment transactions, according to an example implementation, is illustrated schematically.

[0083] System 200 allows software application 210 with an intelligent user interface based on artificial intelligence (AI) (e.g., a virtual assistant) to perform actions on behalf of the user that ultimately trigger a payment transaction. This payment can be processed without the user's explicit consent. After detecting the user's implicit intent to trigger a transaction related to a product or service based on contextual data relating to the interaction between the user and software application 210 (or more specifically, the virtual assistant), the system can autonomously decide and request the triggering of the payment transaction.

[0084] The intelligent user interface includes an interactive interface via a data input system for inputting information and an output system for extracting information related to the transaction to be triggered. The output system may include modules for storing and retrieving contextual data related to the user's interaction.

[0085] The service provider’s intelligent user interface and / or computer system 220 may include a context data shaping module that collects, analyzes, and even filters relevant user data, including habits, personal information, and requests, in order to develop one or more personalized product and / or service recommendations for the user, with the aim of identifying the action to be triggered (in this case, a payment transaction for purchase).

[0086] The service provider's computer system 220 can receive contextual data from the software application 210 and enrich the contextual data with additional data such as user habits, user preferences, and services and / or products in the service provider's catalog. The service provider's computer system 220 can also enrich the contextual data with information about the recommendations made.

[0087] Payment verification entity 250 relies on or includes a risk analysis module to determine the level of risk (and therefore the level of confidence) associated with the decision to autonomously trigger the execution of a payment transaction.

[0088] The risk analysis module relies on contextual data (optionally enriched by the provider's computer system 220) that characterizes the interaction context between the user and the intelligent user interface to generate risk levels for making decisions about verifying or rejecting transactions.

[0089] For example, if the risk level generated by the risk analysis module is low (below the non-zero threshold S1), the transaction is authorized (that is, verified). If v is high (above the non-zero threshold S2), the transaction is rejected. If the risk level is between thresholds S1 and S2, there is doubt and the transaction may be rejected, or a "manual" consent process (that is, not automatic and explicit consent from the end user) may be triggered to obtain the user's consent.

[0090] The risk analysis module enhances the value of traditional payment transaction management systems. This module processes contextual data collected by the intelligent user interface and / or by the computer system 220 to estimate the risks associated with autonomous decisions made by the intelligent user interface, with the assistance of AI.

[0091] Standard transaction verification can be performed based on transaction information such as transaction amount, customer name, merchant category code, payee, and payment method.

[0092] Additional validation is performed here based on contextual data, which may include customer's merchant habits, purchase history, logs / transcriptions of exchanges between the self-service assistant and the customer, etc. Based on this contextual data, a risk level is calculated, and a decision is made to validate (approve) or reject (deny) the transaction based on the risk level (and possibly based on at least one threshold applied to that risk level).

[0093] The threshold can evolve dynamically through feedback mechanisms designed to reduce controversy associated with autonomous decision-making.

[0094] In one or more specific implementations, when the intelligent user interface detects a purchase intent, it does not immediately trigger a purchase transaction and associated payment. Instead, the intelligent user interface may wait for a defined period of time before execution to give the user an opportunity to modify their request or even change their mind and explicitly cancel the payment / request. Once this time has passed, the user can no longer modify their request or cancel the payment, and the decision to accept, reject the payment transaction, or request the user's explicit consent is determined solely by the risk level generated by the analytics module.

[0095] This system addresses technical challenges such as providing a secure payment experience, interpreting user contextual data to understand user needs, and inferring implicit user consent to make payment decisions.

[0096] The system provides frictionless, efficient, and personalized digital services based on autonomous decision-making.

[0097] The system interprets contextual data related to interactions via a smart user interface to understand the user's needs and infer their implicit consent, using this information to make payment decisions. Therefore, the system allows payments to be processed without the user's explicit consent.

[0098] When the operation to be performed is a payment transaction associated with a purchase, the risk analysis module can distinguish between consent to the demand identified by the assistant (by identifying the object of the purchase, that is, identifying the product or service to be purchased) and consent to the payment, verifying the payment without direct consent from the user. In this way, the obtained risk level takes into account both consent to the identified product and / or service and consent to the transaction that triggers it.

[0099] For example, during a conversation with a virtual assistant, there may be information related to the user's desired choice of products / services, but there may also be information about their willingness to complete the purchase / payment process.

[0100] When analyzing the context, the risk analysis module can determine that a purchase proposal generated by the assistant does not appear to meet the user's needs. If a purchase proposal does not meet needs, payment should not be made, and therefore the risk is high. Furthermore, if the assistant's purchase proposal corresponds to the user's needs, the risk analysis module also evaluates the interaction that generated the proposal. If the context does not reveal (at least implicitly) the user's willingness to proceed with the proposed purchase and thus continue with the associated payment, the associated risk is also considered high.

[0101] If the risk analysis module detects that a user's willingness to pay for a product or service arises from their interaction with their assistant, it considers the associated risk to be low.

[0102] When payment is explicitly verified between the user and the assistant, the risk is considered low regardless of the relevance of the assistant's purchase proposal to the initial demand. For example, in a restaurant setting, a user orders food, the waiter accepts the order, and then immediately informs the user that the selected dish is no longer available and offers alternatives. The user can still verify the order, even if it doesn't perfectly correspond to their initial selection.

[0103] In addition, the system retrieves contextual payment data, whether or not it is AI-based, in order to select the appropriate risk analysis module to process the contextual data.

[0104] Finally, the system can provide evidence and / or explanatory information for autonomously triggered transactions, thereby providing highly personalized and efficient digital payment services.

[0105] AI-triggered autonomous payment is an AI-driven system that interacts seamlessly with users, identifies their needs, and autonomously triggers payments without requiring explicit user consent.

[0106] Figure 3 An example scenario with a payment transaction is shown, which includes verification steps for assessing the inherent risks associated with the self-triggered payment.

[0107] This scenario involves a server (or more generally, a computer system) belonging to a service provider (in this case, a merchant selling products and / or services).

[0108] This scenario also involves autonomous virtual assistants: these are virtual assistants that are suitable for making autonomously triggered decisions for payment transactions.

[0109] In some implementations, the autonomous virtual assistant is parameterizable, allowing users to delegate permissions to it for autonomously triggering payment transactions and to configure these permissions. For example, users can authorize or deny the autonomous virtual assistant to make autonomous triggering decisions for payment transactions and configure its parameters based on their requirements and / or preferences for autonomously triggering payment transactions. These parameters include, for example, maximum payment amount, one or more authorized (or correspondingly prohibited) service providers, and the nature of the products or services that can be autonomously triggered.

[0110] In this example scenario, the user does not communicate directly with the service provider's platform. Instead, the autonomous virtual assistant acts as the interface between the user and the service provider's platform, representing the user's actions.

[0111] In the first step (301), the autonomous virtual assistant detects the user’s implicit intention to trigger an order for a product or service based on contextual data related to user interaction via the intelligent user interface.

[0112] Based on this detection, the autonomous virtual assistant makes decisions based on contextual data to autonomously trigger an order and associated payment to the service provider (in this case, the merchant) via the associated server (or more generally, the service provider's computer system), and a message including the order information is transmitted to the service provider's computer system.

[0113] In step (302), data required to process payment transactions related to the order is collected. In addition to transaction information (amount, payee, customer, payment method, etc.) typically used for placing orders and making payments, contextual data for risk analysis is attached to or included in the collected data to process payment transactions.

[0114] Contextual data can be enriched by data collected by the virtual assistant related to interactions and exchanges with the virtual assistant. Contextual data may include one or more of the following elements: information about the user profile, information about user preferences, information about the user's use of the service provider, previous purchase history, information about product or service recommendations, etc.

[0115] Furthermore, a tag is attached to or included in the data collected for processing payment transactions: this tag indicates the autonomous nature (feeded by AI) of the decision that triggers the execution of the payment transaction. This indication of the payment triggering pattern can be provided in a message in accordance with the ISO 20022 standard, which defines a flexible standard format for the exchange of messages related to financial transactions.

[0116] In step (303), a verification request is transmitted from the service provider's computer system to the verification entity, enabling the verification entity to process the payment transaction to determine whether to authorize the payment transaction.

[0117] The verification entity is, for example, a payment method provider or a payment service provider. This provider could be the entity that implements the "wallet" application.

[0118] Verified entities can also be entities operated by merchants.

[0119] The verification request includes transaction information typically used to execute payments associated with an order, as well as contextual data (optionally enhanced) and labels indicating the autonomous nature of the decision that triggered the transaction.

[0120] In step (304), a risk analysis request is sent to the risk analysis module based on the verification request. The risk analysis request may include the same information as the verification request: transaction information typically used for making payments related to the order, as well as contextual data (optionally enhanced) and tags.

[0121] In step (305), the risk analysis module may request the API (Application Programming Interface) to format contextual data related to the customer and the transaction. This contextual data may be included in the risk analysis request or obtained from the service provider's computer system.

[0122] The context data is formatted, preferably encrypted, and then transmitted to the risk analysis module in step (307) for assessing the risk associated with the payment transaction. The results of the analysis are then sent to the verification entity in step (308) in response to the risk analysis request.

[0123] The results of this analysis include risk levels.

[0124] The results of this analysis can include additional information about the risk level, such as explanatory information about the obtained risk level. This explanatory information can be in text form, indicating the contextual data on which the risk level is based. This explanatory information can be used to make the obtained risk level understandable to humans (on the service provider's or user's side).

[0125] After receiving the results of the analysis, the verification entity determines whether the transaction has been authorized.

[0126] If the payment transaction is authorized based on the analysis results, then in step 309, the verification entity transmits the results of the transaction analysis to the service provider's computer system.

[0127] The service provider's computer system then sends a payment notification (including a payment token) to the payment gateway (step 310) to trigger the payment. The information encrypted in the digital token includes transaction information associated with the payment (identification of the payee, debtor, transaction amount, etc.). The encrypted data in the digital token may include a risk level. The encrypted data is sent, for example, in the form of a payment token or in any other digital form that guarantees its authenticity and origin, ensuring that the results of the risk analysis cannot be forged.

[0128] Based on the received encrypted data, the payment gateway determines whether the transaction has been approved. Payment verification can be performed by the payment gateway before executing the payment transaction. Verifications performed by the payment gateway include general verifications such as fraud detection and validity of the means of payment. If the transaction is approved by the payment gateway, the payment transaction is executed in step (311), and information about the completed transaction is sent to the service provider's bank. Confirmation of the order and payment is also transmitted to the service provider's computer system (step 312).

[0129] If, based on the analysis results received in step 308, the verification entity deems the payment transaction valid but too risky (i.e., the risk level is greater than the non-zero threshold S1), then both options are possible. In the first option, the transaction is rejected, which ends the process: for example, this first option can be selected when the risk level is higher than the non-zero threshold S2 (where S2>S1). In the second option, an explicit verification step (315) utilizing the user's potentially strong authentication can be performed before the transaction is executed: for example, this second option can be selected when the risk level is lower than the high threshold S2 but higher than the low threshold S1.

[0130] Figure 4 This is a diagram illustrating the system and method for triggering operations according to an example implementation.

[0131] Figure 4 Corresponding to Figure 3 The same scenario, and provided information about Figure 3 Additional implementation details. Regarding Figure 3 The described aspects and characteristics apply to the discussion of... Figure 4 The aspects and characteristics described and those that can be combined with them.

[0132] In step 401, the user delegates authority to the autonomous virtual assistant to make autonomous decisions on behalf of the user regarding triggering payment transactions.

[0133] In step 402, the autonomous virtual assistant detects the user's implicit intent to trigger an order for a product or service based on contextual data related to the user's interaction with the software application.

[0134] Based on this detection, the autonomous virtual assistant makes autonomous payment transaction triggering decisions on behalf of the user and transmits transaction triggering requests to the service provider's computer system on behalf of the user. Autonomous decision-making or autonomous triggering is understood to mean that the triggering and decision-making do not seek the user's explicit consent.

[0135] In step 403, the service provider's computer system requests the verification entity to verify the payment transaction and provides it with transaction information regarding the payment transaction related to the order. In addition to the transaction information typically used for placing an order and making a payment, contextual data for risk analysis is also sent.

[0136] In step 404, the service provider's computer system may query the verification entity to determine whether the verification entity is capable of processing autonomously triggered payment transactions and has the ability to obtain and / or process contextual data associated with such transactions.

[0137] In step 405, following step 404, according to the first embodiment, the verification entity may respond that it is not capable of processing autonomously triggered payment transactions or that it is not capable of obtaining and / or processing the contextual data associated with such transactions.

[0138] In step 406, following step 405 according to the first embodiment, the service provider's computer system responds to the autonomous payment transaction triggering request in step 402 by instructing the virtual assistant that transaction processing is impossible.

[0139] In step 407, following step 406 according to the first embodiment, the virtual assistant may decide to request verification of the payment transaction from the user. This verification may involve authenticating the user (preferably strong authentication) by inputting authentication data to verify the identity of the user being verified.

[0140] In step 410, following step 404, according to the second embodiment, the verification entity may respond that it has the capability to process autonomously triggered payment transactions and that it does not have the capability to obtain and / or process the contextual data associated with such transactions.

[0141] In step 411, after receiving a response to step 410, the service provider's computer system may request the virtual assistant to send the context data on which the decision to autonomously trigger the transaction is based.

[0142] In step 412, in response to step 411, the virtual assistant sends the context data on which the decision to autonomously trigger the transaction is based to the service provider's computer system.

[0143] In step 413, following step 412, the service provider's computer system transmits a transaction verification request, sends the context data on which the decision to initiate the transaction is based, and information related to the payment to be made to the verification entity.

[0144] In step 420, a fraud detection process may be performed by the verification entity. This fraud detection process can be performed in any known manner and will not be described in detail, as it is not for the purpose of this specification. Step 420 may be performed before, after, or in parallel with step 430.

[0145] In step 430, a risk analysis is performed at the request of the verification entity, based on the contextual data upon which the autonomous transaction trigger decision is based. This risk analysis can be performed by the risk analysis module according to any implementation described in this document. As a result of the analysis, the risk level (i.e., the confidence level) is obtained.

[0146] The verification entity makes a decision about whether to verify a payment transaction based on the risk it receives.

[0147] Based on the obtained risk level, one of steps 440, 450, and 460 is executed after step 430. If the risk level is low (below the non-zero threshold S1), step 440 is executed. If the risk level is high (above the non-zero threshold S2), step 450 is executed. If the risk level is between S1 and S2, step 460 is executed.

[0148] In step 440, the verification entity responds to the service provider's computer system by transmitting a notification instructing it to verify the payment transaction. This notification may include risk level and / or information related to that risk level. The execution of the transaction may be triggered by the service provider's computer system.

[0149] In step 441, following step 440, the service provider's computer system responds to the autonomous virtual assistant, indicating that a payment transaction has been executed.

[0150] In step 442, following step 441, the autonomous virtual assistant notifies the user of the execution of the order and payment transaction.

[0151] In step 450, the verification entity responds to the service provider's computer system by transmitting a notification indicating its decision regarding whether there is any doubt about the validity of the payment transaction. This notification may include a risk level or explanatory information related to that risk level.

[0152] In step 451, following step 450, the service provider's computer system responds to the autonomous virtual assistant by requesting explicit consent from the user.

[0153] In step 452, following step 451, the autonomous virtual assistant requests explicit consent from the user. Depending on whether the user consents, the "regular" process for triggering transaction execution may or may not be triggered.

[0154] In step 460, the verification entity responds to the service provider's computer system by transmitting a notification instructing it to refuse the execution of the payment transaction. This notification may include information about the risk level and / or related to that risk level.

[0155] In step 461, following step 460, the service provider's computer system responds to the autonomous virtual assistant, indicating that the payment transaction has been rejected. The process may stop here. Alternatively, the autonomous virtual assistant may seek explicit consent from the user. Depending on whether the user consents, the "regular" process for triggering transaction execution may or may not be triggered.

[0156] Figure 5 This is a diagram illustrating the system and method for triggering operations according to an example implementation.

[0157] about Figure 3 and Figure 4 The described aspects and characteristics apply to the discussion of... Figure 5 The aspects and characteristics described and those that can be combined with them.

[0158] Figure 5 An example scenario of a payment transaction for purchasing products and / or services is shown.

[0159] In step 511, the user delegates authority to the autonomous virtual assistant to make autonomous decisions on behalf of the user regarding triggering payment transactions.

[0160] In step 512, the autonomous virtual assistant detects the user's implicit intent to trigger an order for a product or service based on contextual data related to the user's interaction with the software application.

[0161] In step 513, the autonomous virtual assistant makes an autonomous payment transaction triggering decision on behalf of the user and transmits a transaction triggering request to the service provider's computer system on behalf of the user. Autonomous decision-making or autonomous triggering is understood to mean that the triggering or decision does not require the user's explicit consent.

[0162] In step 514, the autonomous virtual assistant sends the context data upon which the autonomous triggering decision is based to the service provider's computer system. Alternatively, the context data is sent in step 512, and step 513 is not performed.

[0163] In step 515, the service provider's computer system requests the verification entity to verify the payment transaction and provides it with transaction information related to the payment transaction in connection with the order. In addition to the usual transaction information related to the payment to be made (amount, payee, debtor, payment method, etc.), the service provider's computer system also transmits contextual data on which the decision to autonomously trigger the transaction is based.

[0164] In step 525, risk analysis is performed at the request of the verification entity, based on the contextual data upon which the autonomous transaction trigger decision is based. This risk analysis can be performed by the risk analysis module according to any implementation described in this document. As a result of the analysis, the risk level is obtained.

[0165] In step 526, the verification entity's response service provider's computer system transmits the risk level and / or, for example, explanatory information about the obtained risk level.

[0166] In step 530, the verification entity makes a decision about whether to authorize (that is, verify) the payment transaction based on the risk obtained.

[0167] If the transaction is authorized (that is, verified), then step 531 is executed after step 530: the payment gateway receives a notification with transaction information related to the payment transaction to be executed. The payment gateway may perform further verifications (e.g., fraud detection) on the payment transaction to be executed before execution.

[0168] Otherwise, step 535 is executed after step 530, the transaction is rejected, and the process ends. Alternatively or in combination, the verification entity (or the service provider's computer system) requests explicit consent from the user via a virtual assistant. Depending on whether the user consents, the "regular" process for triggering transaction execution may or may not be triggered.

[0169] Figure 6 This is a flowchart of a method for triggering an operation based on an example implementation.

[0170] In step 610, the implicit intent of the user to trigger an action related to the product or service is detected. This detection is performed based on contextual data related to the user's interaction with the software application.

[0171] Detection may include identifying the action to be triggered and / or identifying the product and / or service.

[0172] The identified products and / or services correspond to the products and / or services targeted by the implicit intent of the user to trigger an action (e.g., a payment action for a purchase).

[0173] In one or more embodiments, detection includes identifying a user’s needs (or expectations) by identifying operations and / or identifying the products and / or services involved.

[0174] In one or more embodiments, the operation is a payment transaction for purchasing at least one product and / or at least one service.

[0175] In one or more implementations, the risk level considers whether the purchase appears to meet the user's needs (or expectations) and whether the user's intention is to continue making payments.

[0176] In step 620, based on the detection, a decision is made on behalf of the user to trigger an action autonomously without prior request for explicit consent from the user.

[0177] In step 630, a risk analysis request is sent to the machine learning-based risk analysis module. The risk analysis request includes contextual data on which the autonomous triggering decision is based and information about the detected operation.

[0178] In step 640, in response, an indicator indicating the risk level, representing that the user's intent is not to trigger the detected operation, is received from the risk analysis module.

[0179] The risk level is also the confidence level that the user's intent is indeed to trigger the detected action.

[0180] Risk level quantification involves identifying the risk of errors in the process of determining the action to be triggered and in obtaining user consent for the triggered action.

[0181] Correct identification of the action to be triggered may include correct identification of the relevant product and / or service: therefore, the risk of error may be associated with (i) incorrect identification of the product and / or service involved, or (ii) the fact that the user's intent is not to trigger the identified action, or both.

[0182] The risk level takes into account, on the one hand, the fact that the purchase seems to meet the user's needs (or desires) (the product and / or service is correctly identified, and the action to be triggered is also correctly identified), and on the other hand, the user's implicit intention is indeed to trigger the identified action for the identified product and / or service.

[0183] In step 650, a decision is made based at least on an indicator to determine whether the operation is authorized.

[0184] Each of steps 610 and 620 may be performed by a software application and / or an autonomous virtual assistant and according to any of the implementation schemes described herein.

[0185] Each of steps 630, 640, and 650 may be performed by the verification entity and according to any of the implementation schemes described herein.

[0186] Figure 7 This is a flowchart of the risk analysis method based on the example implementation plan.

[0187] The steps of this method can be implemented by a machine learning-based risk analysis module according to any of the implementation schemes described in this document.

[0188] In step 710, contextual data related to the interaction between the user and the software application, as well as information about the product or service-related operation to be performed, are received from the verification entity, and the operation has been identified based on the contextual data.

[0189] In step 720, an indicator is generated: this indicator represents the risk level of the user's intent not to trigger the identified operation.

[0190] The risk level is also the confidence level that the user's intent is indeed to trigger the identified action. This action is the object of a self-triggered decision based on contextual data.

[0191] Risk level quantification involves identifying the risk of errors in the process of determining the action to be triggered and in obtaining user consent for the triggered action.

[0192] In one or more implementations, risk level calculation can distinguish between consent to identified needs (e.g., by identifying both the operation to be performed and the products and / or services involved) and consent to payment.

[0193] In step 730, an indicator is sent to the verification entity.

[0194] The verification entity is configured to make a decision about whether to perform a verification operation based on the obtained risk level.

[0195] The risk analysis module can be implemented using large language models (LLM) and hint engineering.

[0196] The analysis process is based, for example, on automated LLM, which breaks down the conversation between the user and the virtual assistant into sequential steps in order to extract meta-information such as thoughts, reactions, ideas, and priorities, thereby allowing it to understand the customer’s implicit intention to trigger a payment transaction.

[0197] In addition, dedicated hints allow LLM to focus on various intermediate goals in each iteration.

[0198] The use of "cues" in risk analysis of text-dialogue-specific examples allows models to be trained to focus on specific tasks, such as... Figure 9The implementation scheme is shown below. This training affects the results returned by the LLM model, as well as the methods used to achieve those results.

[0199] exist Figure 9 The example shown generates a dialogue highlight, a reflection, and the final risk level and the basis for that risk level (explanatory information).

[0200] Figure 8 This is a flowchart of a risk analysis method based on an example implementation plan. The diagram illustrates a general risk analysis algorithm.

[0201] This algorithm is applicable to the topics discussed in this document, especially regarding... Figures 1 to 7 All implementation schemes described.

[0202] In step 810, the context of the interaction is retrieved. The context may include different types of context data as described in various embodiments of this document.

[0203] In step 815, multimodal formatting of the context in the vector representation is performed.

[0204] In step 820, the vector representation of the interpretation context is repeated in a continuous loop to estimate the risk associated with the payment transaction until the interpretation-based integration stopping criterion is validated (step 830).

[0205] Following step 830, and upon verification of the stopping criteria, the risk level is calculated in step 840 based on the obtained interpretation. Furthermore, in step 845, a transcript of the natural interaction interpretation is generated: interpretive information about the risk level is produced.

[0206] This explanatory information allows, for example, the highlighting of contextual data that has the greatest impact on risk assessment. Furthermore, it can generate transformations (meta-concepts) to reflect the content (ideas). For example, this explanatory information can indicate which parts of the content of a conversation with a virtual assistant are important in the interpretation and / or generate new entries that allow for interpretation of the content.

[0207] In step 850, a decision is then made regarding whether to verify the operation (e.g., a payment transaction) using the risk level. Furthermore, associated explanatory information can be used as a basis for making a retrospective decision.

[0208] Figure 9 This is a flowchart of a risk analysis method based on an example implementation. It illustrates a risk analysis algorithm suitable for analyzing conversations in text mode and with virtual assistants.

[0209] This algorithm is applicable to the topics discussed in this document, especially regarding... Figures 1 to 8 All implementation schemes described.

[0210] Risk levels are determined based on key excerpts from transcripts of conversations with the virtual assistant and scores assigned to these excerpts.

[0211] In step 910, the context of the interaction is retrieved. The context may include different types of context data as described in various embodiments of this document. In this example, the context data includes the text content of the conversation with the virtual assistant.

[0212] In step 915, a transcription of the text content of the dialogue is generated.

[0213] In step 920, transcribed highlights are generated, which correspond to the text content.

[0214] In step 921, an evaluation (i.e., a score) of the highlight segment is generated.

[0215] In step 922, the best highlights generated in step 920 are retained based on their corresponding evaluation in step 921.

[0216] For example, regarding the following generations, highlights, and scores: - GenA: ABC content, score 5 / 10 - GenB: DFE content, score 7 / 10 - GenC: GHI content, score 8 / 10 The "DFE" and "GHI" content will be selected because they have the highest scores.

[0217] In step 930, responses are generated based on dialogue transcription and the best segments with the highest scores. In this step 930, the best segments are used to train the model to generate responses, although dialogue transcription is also provided to refine the responses.

[0218] In step 940, a reflective evaluation is generated.

[0219] In step 950, the optimal response is selected.

[0220] In step 960, an overall assessment is performed based on the best response to generate a risk level and an interpretation associated with that risk.

[0221] In addition, virtual assistants themselves can rely on LLMs that interact with users to provide services, such as by accessing necessary information through a database of information on the service provider’s product and service catalog, which is authorized for access via an application programming interface (API).

[0222] The various systems described in this document may include different functions or benefits, including: - Provide a secure, reliable, user-friendly, and transparent payment experience; - Interpret the data exchanged in the context of the interaction to understand the user's needs; - Use the data exchanged in the interaction context to make payment decisions; - Analyze the interaction context to infer implicit consent from the user; - Distinguish between consent to the demand and consent to the payment; - Verifying payments without explicit consent from the user; - Recover payment information (regardless of whether it is based on automated transaction identification) to calculate the risks associated with payment legitimacy; - Allows for self-service payment processes that comply with current payment standards.

[0223] The system includes intelligent modules for analyzing autonomous trade triggering and the associated risks of such trades. It effectively assesses trading risk in real time, enabling smooth, safe trading without human intervention. These modules handle the complexity and dynamic nature of AI-driven trading, ensuring users' trading is safe and efficient.

[0224] In the description of each stage and method, although the steps are described sequentially, some steps may be omitted, combined, executed in a different order, and / or executed in parallel.

[0225] One or more steps of one or more of the methods described in this document may be implemented by software or computer programs and / or hardware, such as by circuits, whether or not they are programmable or specific.

[0226] The functions, steps, and methods described herein may be implemented by software (e.g., via software on one or more processors to be executed on a general-purpose or special-purpose computer) and / or by hardware (e.g., one or more circuits and / or any other hardware components).

[0227] Therefore, this specification relates to a computer program or software executable by a host device, and correspondingly a host system (such as a system for triggering operations, a computer system) via one or more data processors, the program / software including instructions for causing the host device (and correspondingly the host system) to perform all or part of the steps of one or more methods described in this document. These instructions are intended to be stored in the memory of the host device (and host system, respectively), loaded by one or more processors of the host device (and host system, respectively), and then executed to cause the host device (and host system, respectively) to perform the methods under consideration.

[0228] The software / program can be coded in any programming language and can be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desired form.

[0229] A host device (host system, respectively) can be implemented by one or more physically independent machines. A host device (host system, respectively) can have a computer architecture, including one or more components of such an architecture: data storage, processor, communication bus, hardware interface for connecting the host device (host system, respectively) to a network or other device, user interface, etc.

[0230] In one implementation, some or all of the steps of the method for triggering the operation or other methods described in this document are implemented by a device or system equipped with components for implementing those steps of the method.

[0231] These components may include software components (such as instructions for one or more program components) and / or hardware components (such as circuits, data storage, processors, communication buses, hardware interfaces, etc.).

[0232] These components may include, for example, one or more circuits configured to perform one or more or all of the steps of a method described herein. These components may include, for example, at least one processor and at least one memory, the at least one memory including program instructions configured to, when executed by the processor, cause the device to perform one or more or all of the steps of a method described herein.

[0233] In this document, a component that implements a function or a set of functions may also refer to a software component, hardware component, or set of hardware and / or software components that can implement that function or set of functions, as described below for the relevant components.

[0234] This specification also relates to an information medium that can be read by a data processor and has the program instructions described above.

[0235] The information medium can be any hardware component, entity, or device capable of storing the aforementioned program instructions. Available program storage media include ROM or RAM memory, magnetic storage media such as disks and magnetic tapes, hard disk drives or optically readable digital data storage media, or any combination of these media.

[0236] In some cases, computer-readable storage media are not transient. In other cases, the information medium can be a transient medium (e.g., a carrier wave) used to transmit signals (electromagnetic, electrical, radio, or optical signals) carrying program instructions. This signal can be transmitted via a suitable transmission medium (wired or wireless): cable or fiber optic cable, radio or infrared link, or otherwise.

[0237] One embodiment also relates to a computer program product including a computer-readable storage medium having program instructions stored thereon, the program instructions being configured to cause the host device (host system, respectively) (e.g., a computer) to perform some or all of the steps of one or more methods described herein when executed by one or more processors and / or one or more programmable hardware components of a host device (host system, respectively).

Claims

1. A method for autonomously triggering at least one operation, the method comprising: Based on contextual data related to the interaction between the user and the software application, detect (610) the user's implicit intention to trigger an operation related to the product or service; Based on the detection, a decision is made on behalf of the user (620) to trigger the operation autonomously without prior request for explicit consent from the user; Send a (630) risk analysis request to the machine learning-based risk analysis module, the risk analysis request including the context data and information about the detected operation; The risk analysis module receives (640) an indicator of the risk level indicating that the user's intent is not to trigger the detected operation; A decision (650) is made based at least on the indicator to determine whether the operation is authorized.

2. The method according to claim 1, wherein, The risk level quantification considers the risk of errors in identifying the action to be triggered and in obtaining the user's consent to trigger the action.

3. The method according to any one of the preceding claims, wherein, The detection includes identifying the product and / or service to which the implicit intent of the user to trigger the operation has been detected.

4. The method according to any one of the preceding claims, the method comprising: When the operation is authorized, a notification is sent to the computer system to trigger the execution of the operation.

5. The method according to claim 4, wherein, The notification is a payment notification that includes a payment token.

6. The method according to any one of the preceding claims, the method comprising: When the operation is not authorized, it is used to obtain explicit consent from the user and / or to request authentication of the user.

7. The method according to any one of the preceding claims, the method comprising: When the indicator is below a first threshold and above a second non-zero threshold, an explicit verification request is sent to the user to trigger the operation. When the indicator is higher than the first threshold, a notification is sent to reject the operation; When the indicator falls below the second threshold, a notification is sent to the computer system to trigger the execution of the operation.

8. The method according to any one of the preceding claims, the method comprising: Obtain at least one configuration parameter, wherein the at least one configuration parameter defines the permission granted by the user to the software application to trigger an operation on behalf of the user; Configure the software application based on the configuration parameters.

9. The method according to any one of the preceding claims, wherein, The software application is a virtual assistant or includes a virtual assistant, and the context data includes the content of the interaction with the virtual assistant.

10. The method according to any one of the preceding claims, wherein, The analysis request includes at least one of the following: information about the user profile, information about user preferences, information about user usage, information about product or service recommendations, and information about the history of actions triggered by the user.

11. The method according to any one of the preceding claims, wherein, The operation is a payment transaction used to purchase the product and / or service.

12. The method according to claim 11, wherein, The risk level takes into account whether the purchase appears to meet the user's needs and whether the user's intention is to proceed with the payment.

13. The method according to claim 11 or 12, wherein, The risk level takes into account the user's consent to the demand identified by identifying the product or service to be purchased, and the user's consent to triggering payment.

14. A system including a computer component, the computer component being configured to implement a method for autonomously triggering at least one operation, the method comprising: Based on contextual data related to the user's interaction with the software application, detect the user's implicit intention to trigger an operation related to the product or service. Based on the detection, a decision is made on behalf of the user to trigger the operation autonomously without prior request for explicit consent from the user. A risk analysis request is sent to a machine learning-based risk analysis module, the risk analysis request including the context data and information about the detected operation; Receive from the risk analysis module an indicator indicating that the user's intent is not to trigger the risk level of the detected operation; The decision to determine whether the operation is authorized is based at least on the indicator.

15. A risk analysis method, the risk analysis method comprising: The machine learning-based risk analysis module receives (710) contextual data related to the interaction with the user and the software application, as well as information about the product or service-related actions to be performed, from the verification entity, and the actions have been identified based on the contextual data; The risk analysis module generates (720) an indicator of the risk level indicating that the user's intent is not to trigger the risk of the identified operation; Send the indicator (730) to the verification entity.

Images