Method and system for autonomously triggering an operation

Abstract

A process includes: detecting, based on contextual data related to a user's interaction with a software application, an implied intention by the user to initiate an operation related to a product or service; based on the detection, autonomously deciding to initiate the operation on behalf of the user without requiring the user's prior explicit consent; transmitting a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including contextual data and information about the detected operation; receiving from the risk analysis module an indicator representing a level of risk that the user's intention is not to initiate the detected operation; and making a decision to determine, based at least on the indicator, whether the operation is permitted or not. Figure for the abstract: Fig. 6

Description

Title of the invention: Method and system for autonomously triggering an operation technical field

[0001] This description relates to a method and autonomous triggering system for at least one operation and a risk analysis method. Technical background

[0002] Different types of virtual assistants can be used when a user interacts with a software application (for example, a web application or a mobile application) in order to assist the user with respect to operations that may correspond to his needs and / or to automatically suggest operations that may correspond to his needs or wishes.

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

[0004] These virtual assistants may, however, have limited decision-making capabilities, for example, not be able to respond to a user's changing needs in real time.

[0005] In addition, these virtual assistants may be designed with objectives (for example, commercial objectives) that may conflict with the actual needs or intention of the user.

[0006] Moreover, these limitations or defects may lead to problems of trust and / or security for the actions performed by these assistants.

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

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

[0009] According to a first aspect, the present description relates to a method comprising: detecting, based on contextual data of a user's interaction with a software application, an implicit intention on the part of the user to trigger an operation relating to a product or service; based on the detection, an autonomous decision to trigger the operation on behalf of the user without requiring prior explicit consent from the user; transmitting a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including the data contextual and information about the detected operation; a receipt from the risk analysis module of an indicator representative of a risk level that the user's intention is not to trigger the detected operation; a decision to determine, based at least on the indicator, whether the operation is authorized or not.

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

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

[0012] In one or more embodiments, when the indicator is less than a first threshold value and greater than a second non-zero threshold value, an explicit validation request for the triggering of the operation is sent to the user; When the indicator is above the first threshold value, a notification of refusal of the operation is sent; when the indicator is below the second threshold value, a notification is sent to a computer system to trigger the execution of the operation.

[0013] In one or more embodiments, the method comprises: obtaining at least one configuration parameter defining rights granted to the software application by the user for the autonomous triggering of operations on behalf of the user; configuring the software application based on the configuration parameter.

[0014] In one or more embodiments, wherein the software application is or includes a virtual assistant and the contextual data includes content of an interaction with the virtual assistant.

[0015] In one or more embodiments, the level of risk is determined on the basis of salient points of a transcription of text content of a conversation and / or interaction with the virtual assistant and of scores evaluated for these salient points.

[0016] In one or more embodiments, wherein the analysis query includes at least one piece of information from among: information on a user profile, information on user preferences, information on user usage, information on a recommendation of a product or service, information on a history of operations triggered for the user.

[0017] In one or more embodiments, wherein the operation is a payment transaction for the purchase of at least one product and / or at least one service, and wherein the notification is a payment notification including, for example, a token payment.

[0018] In one or more embodiments, the level of risk takes into account, on the one hand, the fact that the purchase appears to meet the user's need and, on the other hand, that the user's intention is indeed to proceed with the payment.

[0019] According to another aspect, the present description relates to a system comprising computer means for implementing a process according to the first aspect.

[0020] The computing means may include software means and / or hardware means, for example, electronic means. The electronic means may include, for example, one or more circuits configured to execute one or more or all of the steps of the process according to the first aspect. The electronic means may include, for example, at least one processor and at least one memory comprising program instructions configured to, when executed by the processor, cause the device to execute one or more or all of the steps of the process according to the first aspect.

[0021] According to another aspect, the present description relates to a data processor readable recording medium on which is recorded a program comprising program instructions configured to cause the data processor to execute one or more or all of the steps of the process according to the first aspect.

[0022] According to another aspect, the present description relates to a computer program comprising program instructions configured to cause a data processor to execute one or more or all of the steps of the process according to the first aspect.

[0023] According to a second aspect, the present description relates to a process comprising: receiving from a verification entity by a machine learning-based risk analysis module contextual data relating to a user interaction with a software application and information on an operation relating to a product or service intended to be executed, the operation having been identified on the basis of the contextual data; generating by the risk analysis module an indicator representing a level of risk that the user's intention is not to trigger the identified operation; transmitting the indicator to the verification entity.

[0024] According to another aspect, the present description relates to a device comprising computer means for implementing a process according to the second aspect.

[0025] The computer means may include software means and / or hardware means, for example, electronic means. The electronic means may include, for example, one or more circuits configured to perform one or more or all of the steps of the process according to the second aspect. The means electronic devices may include, for example, at least one processor and at least one memory comprising program instructions configured to, when executed by the processor, cause the device to execute one or more or all of the steps of the process according to the second aspect.

[0026] According to another aspect, the present description relates to a data processor readable recording medium on which is recorded a program comprising program instructions configured to cause the data processor to execute one or more or all of the steps of the process according to the second aspect.

[0027] According to another aspect, the present description relates to a computer program comprising program instructions configured to cause a data processor to execute one or more or all of the steps of the process according to the second aspect. Brief description of the figures

[0028] Other features and advantages will result from the detailed description that follows, carried out on the basis of embodiments and examples given by way of illustration and not limitation, with reference to the attached figures.

[0029] [Fig.l] schematically represents an operation triggering system according to an example embodiment.

[0030] [Fig.2] is an organizational chart illustrating a system and method for triggering an operation according to an example of an embodiment.

[0031] [Fig.3] is a diagram illustrating a system and method for triggering an operation according to an example embodiment

[0032] [Fig.4] is a diagram illustrating a system and method for triggering an operation according to an example embodiment.

[0033] [Fig.5] is a diagram illustrating a system and method for triggering an operation according to an example embodiment.

[0034] [Fig.6] is a flowchart of a process for triggering an operation according to an example embodiment.

[0035] [Fig.7] is a flowchart of a risk analysis process according to an example of embodiment.

[0036] [Fig.8] is a flowchart of a risk analysis process according to an example of implementation.

[0037] [Fig.9] is a flowchart of a risk analysis process according to an example of implementation. Detailed description

[0038] Various examples of implementation will now be described in more detail in Reference is made to the drawings. Specific structural and / or functional details disclosed herein are used to facilitate understanding of the various possible embodiments. However, a person skilled in the art will understand that the embodiment examples may be subject to various modifications and can be implemented without all of these details.

[0039] This description relates to methods and systems for automatically triggering the execution of one or more operations based on contextual data related to a user interaction with a software application, without requiring explicit user validation prior to this triggering. In the context of this document, this will be referred to as "autonomous triggering" of the execution of an operation.

[0040] The operation to be performed can be any operation, simple or complex. The operation to be performed is, for example, a transaction (e.g., a bank transaction, a payment transaction, etc.), a purchase of products or services, a transmission of messages and / or data or documents, access to one or more multimedia content items, a transfer of one or more multimedia content items, access to a user account, the generation of a signed document, etc.

[0041] The operation to be performed may be an operation proposed by a service provider with whom the user interacts by means of the software application.

[0042] The software application may itself be a virtual assistant or include functions of a virtual assistant or be associated with a virtual assistant.

[0043] In one or more embodiments, the operation to be executed is triggered without explicit validation action on the part of the user: the user's intention regarding the execution of the operation is detected on the basis of the contextual interaction data, but no explicit action is required on the part of the user to formulate their agreement or confirm their intention: the user's consent is considered here to be implicit.

[0044] In one or more embodiments, the detection and / or identification of the operation to be performed can be carried out by a virtual assistant based on machine learning (ML) 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 be independent of this software application with which the user also interacts.

[0045] In the context of this document, the term "virtual assistant" will refer to any software component configured to assist a user during interaction with a software application or system. Such a virtual assistant or digital assistant may be a personal digital assistant, or any software component (for example, in a connected object) with user assistance functions and capable of offering user operations.

[0046] In one or more embodiments, to secure this autonomous triggering method, a confidence level that the user's intention is indeed to trigger the operation is calculated in order to quantitatively assess the risk of error regarding the user's intention. This confidence level also represents a risk level that the user's intention is not to trigger the operation. The risk assessed here relates both to the identification of the operation desired by the user and to the existence of consent. This risk is a technical risk linked to the technical limitations of the AI ​​and machine learning-based software solution (particularly the virtual assistant) with regard to identifying the operation to be triggered and obtaining consent.It is understood that other types of risks, for example of a legal nature, may arise from this autonomous triggering of an operation, but these risks are not assessed by the risk analysis module.

[0047] The potential applications are numerous. This solution can be used, for example, for all digital markets for the execution of operations consisting of a purchase and / or payment transaction: in these digital markets, ease of use, speed and security of interactions and payments are essential.

[0048] This solution can also be used in all sectors where tasks and processes require significant digital automation, such as the manufacture of manufactured or other products, as well as logistics.

[0049] In addition, the virtual assistant can be designed to help consumers in their daily lives, for example by helping them keep track of their tasks, make purchases and manage their schedules using a few simple natural interactions.

[0050] This solution is thus suitable for a variety of applications which require frictionless, efficient, or even personalized digital services, based on decisions to trigger operation(s) taken autonomously on the basis of contextual interaction data and without explicit consent from the user.

[0051] In one or more embodiments, the system allows for taking into account, for the autonomous triggering decision, various contextual data relating to the interaction context.

[0052] For example, contextual data may include the conversation (including text, image(s) or audio of the conversation) with the virtual assistant and / or information relating to an interaction made with the virtual assistant and / or the software application.

[0053] For example, contextual data may include the user profile (preferences, name, place of residence, etc.) and / or information relating to the user's usage (habits, history of operations performed by the user, etc.). The A user profile can be the profile registered with a service provider with whom the user interacts through the software application.

[0054] For example, contextual data may include data about the user's environment (e.g. geolocation, country, temperature, weather, etc.) during the interaction.

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

[0056] Thus the system allows a transparent triggering of the execution of the operation with consideration of the user's needs and habits, hyper automation and interaction with a natural and intuitive user interface via the virtual assistant.

[0057] The system provides end users with an interaction system offering a seamless experience through the transparent execution of operations.

[0058] The system reduces friction associated with operations, such as payments, which often require a series of data entries. In the specific case of a payment, the system can assess the interaction context to determine the legitimacy of initiating a payment and avoid the need for explicit user consent when the risk of error is sufficiently low (for example, below a given threshold).

[0059] In one or more embodiments, the risk assessment associated with the autonomous triggering decision is carried out by a machine learning-based risk analysis module (“Machine Learning”, ML) configured to perform an analysis of the interaction context in order to quantify the risk associated with the autonomous triggering of the operation to be executed and to calculate a risk level.

[0060] Based on the level of risk, it is possible to determine whether it is possible to override the explicit consent of the user or, failing that, in the event of refusal to execute the operation when the risk is beyond a threshold, to use a traditional method to obtain explicit consent and / or require authentication (or re-authentication) of the user before authorizing the execution of the operation.

[0061] This solution simplifies and streamlines the user experience since the user does not need to perform any authentication action when the assistant autonomously carries out a payment except when the risk is assessed as being too high and results in a refusal to execute the operation, in which case strong authentication and / or explicit validation of the user may be required.

[0062] Strong authentication means authentication based on verification at least two authentication factors of different types. 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 factors (based on the use of a user-specific hardware device).

[0063] In one or more embodiments, the software application and / or virtual assistant is configurable so that the user can grant rights to the software application and / or virtual assistant for the autonomous triggering of operations on behalf of the user and configure these rights.

[0064] For example, the user may or may not authorize this autonomous virtual assistant to make autonomous triggering decisions and configure parameters of the autonomous virtual assistant according to their requirements and / or preferences regarding the autonomous triggering of operations. These parameters include, for example: one or more authorized (or respectively prohibited) service providers, the nature of the products or services that may be subject to autonomous triggering, a maximum number of transactions allowed per time period, a maximum amount to be paid if the operations are subject to a fee, etc.

[0065] Fig. 1 schematically represents a system 100 for triggering an operation according to an example embodiment.

[0066] The system includes a software application 110 associated with or including a virtual assistant 120. The software application 110 (and / or the virtual assistant 120) is in operational communication with a computer system 130 of a provider offering, for example via a catalogue, operations relating to one or more products and / or one or more services.

[0067] The software application 110 (or more specifically the virtual assistant 120) is configured to detect, on the basis of contextual data to a user's interaction with the software application, an implicit intention of the user to trigger an operation relating to a product or service.

[0068] The software application 110 (or more specifically the virtual assistant 120) is configured to, based on detection, decide and request, on behalf of the user, the triggering of the detected operation without first requiring the user's explicit consent. The triggering request can be sent to the provider's computer system 130,

[0069] A verification entity 150 is configured to receive, from the provider's computer system 130 (or directly from the virtual assistant 120), a request to validate an autonomous trigger decision for an operation and to determine whether the operation is authorized or refused. In the example cases where the virtual assistant is a service of the provider or in the case the verification entity also provides the virtual assistant, the validation request can be received directly from the virtual assistant 120, without going through the provider's computer system 130.

[0070] The verification entity 150 is configured to transmit a risk analysis request to a 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 operation.

[0071] The computer system 180 is configured to perform one or more operations. The computer system 180 may be part of the service provider's computer system 130, be linked to the computer system 130, or be a third-party computer system involved in performing the operation to be executed. If the operation to be executed is a payment transaction, the computer system 180 may include a payment gateway configured to make a decision and process a payment transaction.

[0072] When the verification entity 150 determines, based on the level of risk, that an operation is authorized, the verification entity 150 transmits a notification to the computer system 180 so that the computer system 180 executes the authorized operation.

[0073] To make the system's operation more concrete and to illustrate its capabilities, embodiments will be described in detail with reference to Figures 3 to 5 in the example case where the operation is a payment transaction: such transactions require a high degree of security. These embodiments of Figures 3 to 5 can be generalized to any other operation.

[0074] Fig. 2 schematically represents a system 200 for triggering operations allowing payment transactions to be carried out according to an example of implementation.

[0075] The system 200 enables a software application 210 with an intelligent user interface (for example, a virtual assistant) based on Artificial Intelligence (AI) to perform actions that ultimately trigger a payment transaction on behalf of the user. This payment does not require the user's explicit consent to be processed. The triggering of the payment transaction can be decided and requested autonomously following the detection, based on contextual data relating to a user interaction with the software application 210 (or more specifically with the virtual assistant), of an implicit intention on the part of the user to initiate an operation related to a product or service.

[0076] The intelligent user interface includes interaction interfaces via a data input system for entering information and an output system for extracting information related to the transactions to be triggered. The system of output may include a module responsible for storing and extracting contextual data related to interactions with the user.

[0077] The intelligent user interface and / or the provider's computer system 220 may include a contextual data formatting module which collects, analyzes, or even filters relevant user data, including habits, personal information and requests, in order to formulate one or more recommendations of personalized product(s) and / or service(s) for the user with a view to identifying an operation to be triggered (here, a payment transaction for an order).

[0078] The provider's computer system 220 can receive contextual data from the software application 210 and enrich it with additional data such as user habits, user preferences, and services and / or products in the provider's catalog. The provider's computer system 220 can enrich contextual data with information on the recommendation(s) made.

[0079] A payment verification entity 250 relies on or includes a risk analysis module to determine a level of risk (and therefore a level of confidence) related to the autonomous triggering decision of the execution of the payment transaction.

[0080] The risk analysis module relies on contextual data characterizing the context of interaction between the user and the intelligent user interface, optionally enriched by the provider's computer system 220 to generate a risk level used to make a decision regarding the validation or rejection of the transaction.

[0081] For example, if the risk level generated by the risk analysis module is low (below a non-zero SI threshold), then the transaction is authorized (i.e., validated). If the risk level is high (above a non-zero S2 threshold), then the transaction is refused. If the risk level is between the SI and S2 thresholds, then doubt exists and the transaction may be refused, or a process with "manual" consent (i.e., non-automatic and explicit consent from the end user) may be initiated to obtain the user's consent.

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

[0083] A conventional transaction verification can be performed on the basis of transactional information such as the transaction amount, the name of the customer, merchant category code, beneficiary, payment method, etc.

[0084] A further check is performed here based on contextual data, including, where applicable, the customer's habits with respect to the merchant, purchase history, logs / transcripts of exchanges between the autonomous assistant and the customer, among other things. Based on this contextual data, a risk level is calculated and a decision is made based on the risk level (and possibly on the basis of at least one threshold applied to this risk level) in order to validate (approve) or reject (refuse) the transaction.

[0085] The threshold can evolve dynamically thanks to a feedback mechanism aimed at reducing disputes related to autonomous decision-making.

[0086] In one or more specific embodiments, when the intelligent user interface detects a purchase intent, the purchase transaction and associated payment are not immediately triggered. Instead, the intelligent user interface may wait for a defined period before executing, in order to give the user the opportunity to modify their request or even change their mind and explicitly cancel the payment / request. Once this period has elapsed, the user can no longer modify their request or cancel the payment, and only the risk level generated by the analytics module determines whether to accept, reject the payment transaction, or request the user's explicit consent.

[0087] The system addresses technical issues such as providing a secure payment experience, interpreting user contextual data to understand their needs, and inferring user implied consent for payment decisions.

[0088] The system offers a frictionless, efficient and personalized digital service based on autonomously made decisions.

[0089] The system interprets contextual data relating to the interaction context via the intelligent user interface to understand the user's needs, to infer the user's implied consent, and uses this information to make payment decisions. The system thus enables payments to be processed without the user's explicit consent.

[0090] The risk analysis module can, in the case where the operation to be executed is a payment transaction associated with a purchase, distinguish between consent for the needs identified by the assistant (by identifying the object of the purchase, i.e. identifying a product or service to be purchased) and consent for the payment, validating payments without the direct consent of the user.

[0091] For example, during a conversation with the virtual assistant there may be information relating to the choice that the user wants to make on the products / services but also on our willingness to go through with the purchase / payment procedure.

[0092] During context analysis, the risk analysis module may determine that the purchase suggestion generated by the assistant does not appear to meet the user's need. If the purchase suggestion does not meet the need, then the payment should not be made, and therefore the risk is high. Furthermore, if the purchase suggestion from the assistant does meet the user's need, the risk analysis module also evaluates the interaction that led to this suggestion. If the context does not indicate, at least implicitly, the user's intention to proceed with the proposed purchase, and therefore the associated payment, then the associated risk is also considered high.

[0093] In the event that the risk analysis module detects a willingness on the part of the user to pay for the product or service resulting from the interaction he had with the assistant, then the associated risk is considered to be low.

[0094] In a case where the user explicitly confirms the payment to the assistant, the risk is considered low regardless of the relevance of the purchase suggestion from the assistant to the initial need. For example, in a restaurant, the user orders a dish, the server takes the order, then returns to the user immediately afterward to inform them that the chosen dish is no longer available and offers the user something else. The user can still confirm the order, even if it does not exactly correspond to their initial choice.

[0095] In addition, the system retrieves contextual data relating to payments, whether AI-based or not, in order to select a suitable risk analysis module to process this contextual data.

[0096] Finally, the system can provide justifications and / or explanatory information for operations triggered autonomously and offers a highly personalized and efficient digital payment service.

[0097] AI-initiated autonomous payment is an AI-powered system that interacts seamlessly with users, determines their needs and triggers payments autonomously without requiring explicit user consent.

[0098] Figure 3 presents an example of a payment transaction scenario that includes verification steps to assess the inherent risks associated with autonomously triggered payments.

[0099] The scenario involves a server (or more generally a computer system) of a service provider (here a merchant selling products and / or services).

[0100] The scenario further involves an autonomous virtual assistant: this autonomous virtual assistant is a virtual assistant adapted to make autonomous triggering decisions for payment transactions.

[0101] In some embodiments, this autonomous virtual assistant is configurable to This allows the user to delegate rights to this autonomous virtual assistant for the autonomous initiation of payment transactions and to configure these rights. For example, the user can choose whether or not to authorize this autonomous virtual assistant to make decisions regarding the autonomous initiation of payment transactions and configure the autonomous virtual assistant's settings according to their requirements and / or preferences for autonomous payment transaction initiation. These settings include, for example: a maximum payment amount, one or more authorized (or respectively prohibited) payment providers, the types of products or services that can be subject to autonomous payment transaction initiation, etc.

[0102] In the example scenario, the user does not communicate directly with the provider's platform. Instead, a self-contained virtual assistant serves as an interface between the user and the provider's platform and acts on the user's behalf.

[0103] In the first step (301), the autonomous virtual assistant detects, on the basis of contextual data to a user interaction via an intelligent user interface, an implicit intention of the user to trigger an order relating to a product or service.

[0104] Based on this detection, the autonomous virtual assistant decides to autonomously trigger, on the basis of contextual data, the order and the associated payment with the service provider (here a merchant) via an associated server (or more generally a computer system of the service provider) and a message including information on the order is sent to the computer system of the service provider.

[0105] During step (302), the data necessary for processing the payment transaction relating to the order are collected. In addition to the transactional information (amount, beneficiary, customer, payment method, etc.) usually used to place an order and make a payment, contextual data used for risk analysis is attached to or included in the data collected for processing the payment transaction.

[0106] Contextual data can be enriched in relation to that collected by the virtual assistant and relating to the interaction and content of exchanges with the virtual assistant. Contextual data can include, for example, one or more of the following: information on a user profile, information on user preferences, information on the user's interactions with the service provider, a history of previous purchases, information on a recommendation of a product or service, etc.

[0107] In addition, a label is attached to or included in the data collected for processing the payment transaction: this label serves to indicate the autonomous (AI-powered) nature of the decision to trigger the payment transaction to be carried out. This indication of the payment trigger method may be provided in a message according to the ISO 20022 standard which defines a flexible standard format for the exchange of messages relating to financial transactions.

[0108] During step (303), a validation request is sent from the provider's computer system to a verification entity so that the verification entity can process the payment transaction to determine whether or not to authorize the payment transaction.

[0109] The verification entity is, for example, an entity of a payment means provider or a payment service provider. This provider or service provider may be a provider implementing a "Wallet" application.

[0110] The verification entity may also be an entity operated by the merchant.

[0111] The validation request includes the transactional information usually used to make a payment relating to an order and in addition the contextual data (possibly enriched) and the label indicating the autonomous nature of the decision to trigger the transaction.

[0112] During step (304), a risk analysis request is transmitted to a risk analysis module based on the validation request. The risk analysis request may include the same information as the validation request: the transactional information usually used to make a payment related to an order, and in addition, contextual data (possibly enriched) and the label.

[0113] During step (305), the risk analysis module can request an API (application program interface) to format the contextual data relating to the customer and the transaction. The contextual data can be contained in the risk analysis request or obtained from the provider's IT system.

[0114] The contextual data is formatted, preferably encrypted, and then sent in step (307) to the risk analysis module for risk assessment related to the payment transaction. The results of this analysis are then transmitted to the verification entity in step (308), in response to the risk analysis request.

[0115] The results of this analysis include a risk level.

[0116] The results of this analysis may include additional information At this risk level, for example, explanatory information about the risk level obtained. This explanatory information, serving as justification, can be in text form and indicate the contextual data on which the risk level is based. This explanatory information can be used so that a human (provider or user) can understand the risk level obtained.

[0117] After receiving the results of the analysis, the verification entity determines whether the transaction is authorized or not.

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

[0119] The service provider's IT system then transmits the payment notification (including a payment token) to the payment gateway (step 310) to trigger the payment. The data encrypted in the digital token includes transactional information associated with the payment (identification of the beneficiary, the debtor, the transaction amount, etc.). The data encrypted in the digital token may include the risk level. The encrypted data is transmitted, for example, as a payment token or in any other digital form that guarantees its authenticity and origin so that the result of the risk analysis cannot be falsified.

[0120] The payment gateway determines, based on the encrypted data received, whether the transaction is approved or not. Payment checks may be performed by the payment gateway prior to the execution of the payment transaction. The checks performed by the payment gateway include, for example, standard checks relating to fraud detection, the validity of payment methods, etc. If the transaction is approved by the payment gateway, the payment transaction is executed, and information about the completed transaction is sent to the service provider's bank in step (311). Confirmation of the order and payment is also provided to the service provider's IT system (step 312).

[0121] If, based on the analysis results received in step 308, the payment transaction is considered by the verifying entity to be valid but too risky (i.e., the risk level is above a non-zero threshold SI), two options are possible. In the first option, the transaction is refused, which terminates the process: this first option can be chosen, for example, when the risk level is above a non-zero threshold S2, with S2 > SL. In the second option, an explicit validation step (315) with possible strong user authentication can be performed before executing the transaction: this second option can be chosen, for example, when the risk level is below the upper threshold S2, but nevertheless above the lower threshold SL.

[0122] The [Fig.4] is a diagram illustrating a system and method for triggering an operation according to an example embodiment.

[0123] Figure 4 corresponds to the same scenario as Figure 3 and provides additional implementation details compared to Figure 3. The aspects and features described with respect to Figure 3 are applicable and combinable with those described with respect to Figure 4.

[0124] During step 401, the user delegates rights to an autonomous virtual assistant for autonomous decision-making to trigger payment transactions on behalf of the user.

[0125] During step 402, the autonomous virtual assistant detects, on the basis of contextual data of a user's interaction with a software application, an implicit intention of the user to trigger an order relating to a product or service.

[0126] Based on this detection, the autonomous virtual assistant makes an autonomous decision to initiate a payment transaction on behalf of the user and sends a transaction trigger request to the service provider's computer system on behalf of the user. Autonomous decision or autonomous triggering means that the user's explicit consent is not required for this triggering and decision.

[0127] During step 403, the service provider's IT system requests the verification entity to validate the payment transaction and provides it with transactional information on the payment transaction related to the order. In addition to the transactional information usually used to place an order and make a payment, contextual data used for risk analysis is transmitted.

[0128] During step 404, the provider's computer system may ask the verifying entity whether that verifying entity has the ability to process a self-triggered payment transaction and the ability to obtain and / or process contextual data associated with such a transaction.

[0129] During step 405, following step 404, according to a first embodiment, the verifying entity may respond that it does not have the capacity to process a payment transaction with autonomous triggering or that it does not have the capacity to obtain and / or process contextual data associated with such a transaction.

[0130] During step 406, following step 405 according to the first embodiment, the provider's computer system responds to the autonomous triggering request for a payment transaction in step 402 by indicating to the virtual assistant that processing the transaction is not possible.

[0131] During step 407, following step 406 according to the first embodiment, the virtual assistant may decide to request user validation for the payment transaction. This validation may include user authentication (preferably strong authentication), through the entry of authentication data to verify the identity of the user performing the validation.

[0132] During step 410, following step 404, according to a second embodiment, the verifying entity may respond that it has the capacity to process a transaction of payment with autonomous triggering and that it does not have the ability to obtain and / or process contextual data associated with such a transaction.

[0133] During step 411, following receipt of the response in step 410, the provider's computer system may request the virtual assistant to transmit the contextual data on the basis of which the autonomous triggering decision for the transaction is based.

[0134] During step 412, in response to step 411, the virtual assistant transmits to the provider's computer system the contextual data on the basis of which the autonomous triggering decision for the transaction is based.

[0135] During step 413, following step 412, the provider's computer system sends a transaction validation request by transmitting to the verification entity the contextual data on the basis of which the autonomous triggering decision for the transaction is based, as well as the information relating to the payment to be made.

[0136] During step 420, a fraud detection procedure may be performed by the verifying entity. Such a fraud detection procedure may be carried out in any known manner and will not be described in detail, as it is not the subject of this description. Step 420 may be performed before, after, or in parallel with step 430.

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

[0138] The verification entity makes a decision to validate or not the payment transaction based on the risk obtained.

[0139] Depending on the risk level obtained, one of steps 440, 450, or 460 is executed after step 430. If the risk level is low (below a non-zero SI threshold), then step 440 is executed. If the risk level is high (above a non-zero S2 threshold), then step 450 is executed. If the risk level is between SI and S2, then step 460 is executed.

[0140] During step 440, the verification entity responds to the service provider's IT system by sending a notification indicating its decision to validate the payment transaction. This notification may include the risk level and / or information related to the risk level. The execution of the transaction may be triggered by the service provider's IT system.

[0141] During step 441, following step 440, the provider's computer system responds to the autonomous virtual assistant by indicating that the payment transaction is executed.

[0142] During step 442, following step 441, the autonomous virtual assistant informs the user of the order and execution of the payment transaction.

[0143] During step 450, the verification entity responds to the service provider's computer system by sending a notification indicating its decision regarding the doubt about the validity of the payment transaction. This notification may include the risk level or explanatory information relating to the risk level.

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

[0145] During step 452, following step 451, the autonomous virtual assistant requests explicit consent from the user. Depending on whether the user consents or not, a "classic" process for triggering the execution of the transaction may or may not be initiated.

[0146] During step 460, the verification entity responds to the service provider's computer system by sending a notification indicating its decision to refuse execution of the payment transaction. This notification may include the risk level or information relating to the risk level.

[0147] During step 461, following step 460, the service provider's computer system responds to the autonomous virtual assistant by indicating that the payment transaction is declined. The process can stop there. Alternatively, the autonomous virtual assistant may request explicit consent from the user. Depending on whether the user consents or not, a "classic" process for initiating the transaction may or may not be triggered.

[0148] Fig. 5 is a diagram illustrating a system and method for triggering an operation according to an example embodiment.

[0149] The aspects and characteristics described with respect to [Fig.3] and [Fig.4] are applicable and combinable with those described with respect to [Fig.5].

[0150] Fig. 5 corresponds to an example scenario in the case of a payment transaction for a purchase of product and / or service(s).

[0151] During step 511, the user delegates rights to an autonomous virtual assistant for autonomous decision-making to trigger payment transactions on behalf of the user.

[0152] During step 512, the autonomous virtual assistant detects, on the basis of contextual data of a user interaction with a software application, an implicit intention of the user to trigger an order relating to a product or service.

[0153] During step 513, the autonomous virtual assistant makes a decision to de- Autonomous triggering of a payment transaction on behalf of the user and sending a transaction trigger request to the service provider's IT system on behalf of the user. Autonomous decision or autonomous triggering means that the user's explicit consent is not required for this triggering or decision.

[0154] During step 514, the autonomous virtual assistant transmits to the provider's computer system the contextual data on which the autonomous triggering decision is based. Alternatively, the transmission of contextual data takes place in step 512 and step 513 is not executed.

[0155] During step 515, the service provider's IT system requests the verification entity to validate the payment transaction and provides it with the transactional information for the payment transaction related to the order. In addition to the usual transactional information relating to the payment to be made (amount, beneficiary, debtor, payment method, etc.), the service provider's IT system sends the contextual data on which the autonomous decision to initiate the transaction is based.

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

[0157] During step 526, the verification entity responds to the provider's computer system by sending the risk level and / or, for example, explanatory information on the risk level obtained.

[0158] During step 530, the verification entity makes a decision to authorize (i.e. validate) or not the payment transaction based on the risk obtained.

[0159] If the transaction is authorized (i.e., validated), step 531 is executed following step 530: the payment gateway receives a notification with the transactional information relating to the payment transaction to be executed. The payment gateway may perform further checks on the payment transaction to be executed (for example, fraud detection) before executing the payment transaction.

[0160] If step 535 is not executed following step 530, the transaction is declined and the process terminates. Alternatively, or in combination, the verifying entity (or the service provider's IT system) requests explicit consent from the user via the virtual assistant. Depending on whether the user consents or not, a "classic" process for triggering the execution of the transaction may or may not be initiated.

[0161] Figure 6 is a flowchart of a method for triggering an operation according to a example of a project.

[0162] In step 610, a detection of an implicit user intention to trigger an operation related to a product or service is performed. This detection is carried out based on contextual data relating to a user's interaction with a software application.

[0163] At step 620, based on the detection, an autonomous decision to trigger the operation on behalf of the user is taken without prior explicit consent from the user.

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

[0165] At step 640, a representative indicator of the risk level that the user's intention is not to trigger the detected operation is received in response from the risk analysis module. The risk level is also a confidence level that the user's intention is indeed to trigger the detected operation.

[0166] At step 650, a decision is taken to determine, on the basis at least of the indicator, whether the operation is authorized or not.

[0167] Each of steps 610, 620 can be carried out by the software application and / or an autonomous virtual assistant and according to any of the embodiments described in this document.

[0168] Each of steps 630, 640, 650 can be carried out by a verification entity and according to any of the embodiments described in this document.

[0169] The [Fig.7] is a flowchart of a risk analysis process according to an example of implementation.

[0170] The steps of this process can be implemented by a machine learning-based risk analysis module and according to any of the embodiments described in this document.

[0171] In step 710, contextual data relating to a user interaction with a software application and information about an operation relating to a product or service intended to be performed are received from a verification entity, the operation having been identified on the basis of the contextual data.

[0172] In step 720, an indicator is generated: this indicator represents a risk level that the user's intention is not to trigger the identified operation. The risk level is also a confidence level that the user's intention is indeed to trigger the identified operation. The operation is an operation subject to an autonomous triggering decision based on contextual data.

[0173] At step 730, the indicator is transmitted to the verification entity.

[0174] The verification entity is configured to make a decision to validate or not the execution of the operation based on the level of risk obtained.

[0175] The risk analysis module can be implemented using Large Language Models (LLM) and Prompt Engineering.

[0176] The analysis process is for example based on an automatic LLM capable of breaking down a dialogue between the user and a virtual assistant into several successive steps in order to extract meta-information such as thoughts, reflections, ideas and salient points, which allows it to understand the implicit intention of the customer to trigger a payment transaction.

[0177] In addition, dedicated prompts allow the LLM to focus on the different intermediate objectives of each iteration.

[0178] The "prompts" used in the risk analysis specific to the example of a text conversation allow the model to be conditioned to focus on a particular task, as illustrated, for example, by the implementation method in [Fig. 9]. This conditioning influences the result returned by the LLM model, as well as the approach used to arrive at that result.

[0179] In the example of [Fig.9], we generate salient points of the conversation, a reflection, to finally arrive at a level of risk and a justification (explanatory information) of this level of risk.

[0180] Figure 8 is a flowchart of a risk analysis process according to an example embodiment. This figure illustrates a generic risk analysis algorithm.

[0181] This algorithm is applicable to all embodiments described in this document, in particular with respect to Figures 1 to 7.

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

[0183] In step 815, a multimodal formatting of the context into vector representation is performed.

[0184] In step 820, successive cycles of interpretation of the vector representation of the context for the purpose of estimating the risk associated with the payment transaction are repeated until a stopping criterion based on the convergence of the interpretation is verified (step 830).

[0185] Following step 830, when the stopping criterion is met, a risk level is calculated in step 840 based on the interpretation obtained. Furthermore, a transcript of the natural interaction interpretation is generated in step 845: explanatory information about the risk level is generated.

[0186] This explanatory information makes it possible, for example, to highlight the contextual data that had the greatest impact on the risk assessment. Furthermore, transformations (meta-concepts) of the content for the purpose of reflection (ideas) can be generated. For example, this explanatory information can indicate which parts of the conversation with the virtual assistant were significant in the interpretation and / or generate new inputs that allow for an explanation of the content.

[0187] In step 850, the risk level is then used to decide whether or not to validate an operation (in particular, a payment transaction). Furthermore, the associated explanatory information can be used to justify the decision-making process subsequently.

[0188] Figure 9 is a flowchart of a risk analysis process according to an example embodiment. It illustrates a risk analysis algorithm adapted to analyze a conversation with a virtual assistant in text mode.

[0189] This algorithm is applicable to all embodiments described in this document, in particular with respect to Figures 1 to 8.

[0190] The risk level is determined on the basis of salient points from a transcript of text content of the conversation with the virtual assistant and scores assessed for these salient points.

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

[0192] In step 915, a transcript of the text content of the conversation is generated.

[0193] In step 920, salient points of the transcription are generated, a salient point corresponding to a text content.

[0194] In step 921, evaluations (i.e. scores) of the salient points are generated.

[0195] In step 922, the best salient points generated in step 920 are retained based on their respective assessments carried out in step 921.

[0196] For example, with the following generations, highlights and scores:

[0197] GenA Generation: ABC content, score 5 / 10

[0198] GenB Generation: DFE content, score 7 / 10

[0199] GenC Generation: GHI content, score 8 / 10

[0200] we will select the "DFE" and "GHI" contents because their scores are the highest.

[0201] In step 930, reflections are generated based on the conversation transcript and the salient points with the highest ratings. In this step 930, the model is conditioned using the salient points to generate a reflection, However, a transcript of the conversation is also provided to refine the analysis.

[0202] In step 940, evaluations of reflections are generated.

[0203] In step 950, the best reflection is selected.

[0204] In step 960, an overall assessment is carried out on the basis of best thinking in order to generate a risk level and explanations related to that risk.

[0205] In addition, the virtual assistant itself can rely on an LLM which interacts with the user to provide a service, for example by accessing the necessary information through a database of information from the product and service catalogues of providers which it is authorized to access via an application programming interface (API).

[0206] The various systems described in this document may include different functions or advantages consisting of:

[0207] - To offer a safe, reliable, user-friendly and transparent payment experience;

[0208] - Interpret the data exchanged in an interaction context to understand the user's needs;

[0209] - Use the data exchanged in the context of interaction to make decisions payment decisions;

[0210] - Analyze the interaction context to infer implied consent the user;

[0211] - Distinguish between consent for needs and consent for the payment;

[0212] - Validate payments without the user's explicit consent;

[0213] - Retrieve payment information (whether or not it is based on the automatic identification of the transaction) in order to calculate the risk associated with the legitimacy of the payment;

[0214] - Enable autonomous payment processes that comply with the standards of current payments.

[0215] The systems incorporate intelligent modules that enable autonomous transaction triggering and transactional risk analysis associated with autonomously triggered transactions. The systems are capable of efficiently assessing transactional risks in real time and enabling smooth and secure transactions without requiring manual intervention. These modules can manage the complexity and dynamic nature of AI-driven transactions and provide users with assurance that their transactions are safe and efficient.

[0216] In the description of the different phases and processes, although the steps are described sequentially, some steps may be omitted, combined, carried out in a different order and / or in parallel.

[0217] One or more or all of the steps of one or more of the processes described in this document can be implemented by software or computer program and / or by hardware, for example by circuit, programmable or not, specific or not.

[0218] The functions, steps and processes described in this document can be implemented by software (for example, via software on one or more processors, for execution on a general-purpose or special-purpose computer) and / or can be implemented by hardware (for example, one or more circuits, and / or any other hardware component).

[0219] This description relates to a software or computer program capable of being executed by a host device or host system (such as an operation trigger system or computer system) by means of one or more data processors. This software / program comprises instructions to cause the execution by the host device (or system) of all or part of the steps of one or more of the processes described in this document. These instructions are intended to be stored in a memory of the host device (or system), loaded, and then executed by one or more processors of the host device (or system) so as to cause the execution by the host device (or system) of the process in question.

[0220] This software / program may be coded using any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0221] The host device (respectively, system) can be implemented by one or more physically distinct machines. The host device (respectively, system) can have the overall architecture of a computer, including one or more components of such an architecture: data memory, processor(s), communication bus, hardware interface(s) for connecting this host device (respectively, system) to a network or other equipment, user interface(s), etc.

[0222] In one embodiment, all or part of the steps of an operation triggering process or other process described in this document are implemented by a device or system equipped with means for implementing these steps of this process.

[0223] These means may include software means (for example, instructions from one or more components of a program) and / or hardware means (for example, circuit(s), data memory(ies), processor(s), communication bus, hardware interface(s), etc.).

[0224] These means may include, for example, one or more configured circuits to execute one or more or all of the steps of one of the processes described herein. These means may include, for example, at least one processor and at least one memory containing program instructions configured to, when executed by the processor, cause the device to execute one or more or all of the steps of one of the processes described herein.

[0225] Means implementing a function or a set of functions may correspond in this document to a software component, a hardware component or a combination of hardware and / or software components, capable of implementing the function or set of functions, as described below for the means concerned.

[0226] This description also relates to an information carrier readable by a data processor, and containing instructions of a program as mentioned above.

[0227] The information storage medium can be any physical means, entity, or device capable of storing the instructions of a program as mentioned above. Usable program storage media include ROM or RAM memories, magnetic storage media such as magnetic disks and tapes, hard drives, or optically readable digital data storage media, or any combination thereof.

[0228] In some cases, the computer-readable storage medium is not transient. In other cases, the information medium may be a transient medium (for example, a carrier wave) for the transmission of a signal (electromagnetic, electrical, radio, or optical) carrying program instructions. This signal may be transmitted via a suitable means of transmission, wired or wireless: electrical or optical cable, radio or infrared link, or by other means.

[0229] An embodiment also relates to a computer program product comprising a computer-readable storage medium on which program instructions are stored, the program instructions being configured to cause the host device (respectively system) (e.g., a computer) to implement all or part of the steps of one or more of the processes described herein when the program instructions are executed by one or more processors and / or one or more programmable hardware components of the host device (respectively system).

Claims

Demands

1. A method for autonomously initiating at least one operation, the method comprising: a detection (610), based on contextual data relating to a user's interaction with a software application, of an implied intention on the part of the user to initiate an operation relating to a product or service; based on the detection, a decision (620) to autonomously initiate the operation on behalf of the user without prior explicit consent from the user; a transmission (630) of a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including contextual data and information on the detected operation; a reception (640) from the risk analysis module of an indicator representative of a risk level that the user's intention is not to initiate the detected operation;a decision-making process (650) to determine, based at least on the indicator, whether the operation is authorized or not;

2. A method according to claim 1, comprising: when the operation is authorized, sending a notification to a computer system to trigger the execution of the operation.

3. A method according to claim 1 or 2, comprising: where the operation is not permitted, an operation aimed at obtaining explicit consent from the user and / or requiring authentication of the user.

4. A method according to claim 1, comprising: when the indicator is less than a first threshold value and greater than a second non-zero threshold value, sending the user an explicit request for validation of the triggering of the operation; when the indicator is greater than the first threshold value, sending a notification of refusal of the operation; when the indicator is less than the second threshold value, sending a notification to a computer system to trigger the execution of the operation.

5. A method according to any one of the preceding claims, including: obtaining at least one configuration parameter defining rights granted to the software application by the user for autonomously triggering operations on behalf of the user; configuring the software application based on the configuration parameter.

6. A method according to any one of the preceding claims, wherein the software application is or includes a virtual assistant and the contextual data includes content of an interaction with the virtual assistant.

7. A method according to any one of the preceding claims, wherein the analysis query includes at least one piece of information from among: information on a user profile, information on user preferences, information on user usage, information on a recommendation of a product or service, information on a history of operations triggered for the user.

8. A method according to any one of claims 2 to 7, wherein the operation is a payment transaction for the purchase of at least one product and / or at least one service, wherein the notification is a payment notification, the level of risk taking into account, on the one hand, the fact that the purchase appears to meet the user's need and, on the other hand, that the user's intention is indeed to proceed with the payment.

9. A system comprising computer means for implementing a method for autonomously triggering at least one operation, the method comprising: detecting, on the basis of contextual data relating to a user's interaction with a software application, an implicit intention on the part of the user to trigger an operation relating to a product or service; on the basis of the detection, a decision to autonomously trigger the operation on behalf of the user without requiring prior explicit consent from the user; transmitting a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including contextual data and information on the detected operation; a reception from the risk analysis module of an indicator representative of a risk level that the user does not intend to trigger the detected operation; a decision-making process to determine, based at least on the indicator, whether the operation is authorized or not.

10. Risk analysis method, comprising: a receipt (710), from a verification entity by a machine learning-based risk analysis module, of contextual data to a user interaction with a software application and information about a transaction relating to a product or service intended to be executed, the transaction having been identified on the basis of the contextual data; a generation (720) by the risk analysis module of an indicator representative of a risk level that the user's intention is not to trigger the identified operation; a transmission (730) of the indicator to the verification entity.

Images