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] The present description relates to a method and system for autonomously triggering at least one operation and a risk analysis method. Technical background

[0002] Different types of virtual assistants may be used when a user interacts with a software application (e.g., a web application or a mobile application) in order to assist the user with operations that may correspond to his or her needs and / or to automatically suggest operations that may correspond to his or her 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 being able to respond to a user's changing needs in real time.

[0005] Further, these virtual assistants may be designed with objectives (e.g., business objectives) that may conflict with the actual needs or intent of the user.

[0006] Furthermore, these limitations or defects can lead to problems of trust and / or security for the actions executed by these assistants.

[0007] There appears to be 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. Abstract

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

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

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

[0011] In one or more embodiments, when the operation is not authorized, sending a notification to a computer system to trigger 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, sending to the user an explicit validation request for triggering 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.

[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 autonomously triggering 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 risk level is determined based on highlights of a transcript of text content of a conversation and / or interaction with the virtual assistant and scores assessed for those highlights.

[0016] In one or more embodiments, wherein the analysis request includes at least one piece of information from: information on a user profile, information on the user's preferences, information on the user's usages, 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 payment token payment.

[0018] In one or more embodiments, the risk level 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 actually to proceed with the payment.

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

[0020] The computing means may comprise software means and / or hardware means, for example electronic means. The electronic means may comprise, for example, one or more circuits configured to execute one or more or all of the steps of the method according to the first aspect. The electronic means may comprise, 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 method according to the first aspect.

[0021] According to another aspect, the present disclosure relates to a data processor-readable recording medium having recorded thereon a program comprising program instructions configured to cause the data processor to execute one or more or all of the steps of the method according to the first aspect.

[0022] According to another aspect, the present disclosure 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 method according to the first aspect.

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

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

[0025] The computer means may comprise software means and / or hardware means, for example electronic means. The electronic means may comprise for example one or more circuits configured to execute one or more or all of the steps of the method according to the second aspect. The means electronics may comprise 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 method according to the second aspect.

[0026] According to another aspect, the present disclosure relates to a data processor-readable recording medium having recorded thereon a program comprising program instructions configured to cause the data processor to execute one or more or all of the steps of the method according to the second aspect.

[0027] According to another aspect, the present disclosure 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 method according to the second aspect. Brief description of the figures

[0028] Other characteristics and advantages will result from the detailed description which follows, carried out on the basis of embodiments and examples given for illustrative and non-limiting purposes, with reference to the appended figures.

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

[0030] [Fig.2] is a flowchart illustrating a system and method for triggering an operation according to an exemplary embodiment.

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

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

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

[0034] [Fig.6] is a flowchart of an operation triggering method according to an exemplary embodiment.

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

[0036] [Fig.8] is a flowchart of a risk analysis method according to an exemplary embodiment.

[0037] [Fig.9] is a flowchart of a risk analysis method according to an exemplary embodiment. Detailed description

[0038] Various exemplary embodiments will now be described in more detail in reference to the drawings. Specific structural and / or functional details disclosed herein are used to enable an understanding of the various possible embodiments. However, those skilled in the art will understand that the exemplary embodiments may undergo various modifications and may be implemented without all of these details.

[0039] The present description relates to methods and systems allowing automatic triggering of the execution of one or more operations on the basis of contextual data upon a user interaction with a software application without an explicit validation action by the user being required prior to this triggering. In the context of this document, we will speak more precisely of "autonomous triggering" of the execution of an operation.

[0040] The operation to be executed may be any operation, simple or complex. The operation to be executed is for example a transaction (for example a banking transaction, a payment transaction, etc.), a purchase of a product or services, a transmission of a message and / or data or documents, access to one or more multimedia contents, a transfer of one or more multimedia contents, 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 which 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 with respect to the execution of the operation is detected on the basis of the interaction contextual data but no explicit action is necessary on the part of the user to formulate his agreement or confirm his intention: the user's consent is here considered to be implicit.

[0044] In one or more embodiments, the detection and / or identification of the operation to be performed may be performed by a machine learning (ML) based virtual assistant with which the user interacts. The virtual assistant may 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 be used to refer to any software component configured to assist a user when interacting with a software application or a system. Such a virtual assistant or digital assistant may be a digital personal assistant, or any software component (for example in a connected object) with user assistance functions and capable of offering operations to the user.

[0046] In one or more embodiments, in order to secure this autonomous triggering mode, a confidence level that the user's intention is actually to trigger the operation is calculated in order to quantitatively assess the risk of error regarding the user's intention. This confidence level is also a risk level that the user's intention is not to trigger the operation. The risk assessed here concerns both the identification of the operation desired by the user and the fact that there is consent. This risk is a technical risk linked to the technical limitations of the software solution (in particular the virtual assistant) based on AI and machine learning regarding the identification of the operation to be triggered and the 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 manufacturing of manufactured goods or other products, as well as logistics.

[0049] Further, the virtual assistant may be designed to assist consumers in their daily lives, such as helping them track tasks, make purchases, and manage their schedules using a few simple natural interactions.

[0050] This solution is thus adapted to a varied range of applications which require frictionless, efficient, 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 makes it possible to take into account for the autonomous triggering decision various contextual data relating to the interaction context.

[0052] For example, the 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 carried out with the virtual assistant and / or the software application.

[0053] For example, the 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 carried out for the user, etc.). The user profile may be the profile registered with a service provider with which the user interacts by means of the software application.

[0054] For example, contextual data may include data about the environment (e.g. geolocation, country, temperature, weather, etc.) of the user 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 transparent triggering of the execution of the operation while taking into account the needs and habits of the user, 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 providing a smooth experience through seamless execution of operations.

[0058] The system makes it possible to reduce the friction linked to operations, such as payments, which often require a succession of data entries. In the particular case of a payment, the system can evaluate the interaction context to determine the legitimacy of triggering a payment and avoid the need for explicit consent from the user when the level of risk of error is sufficiently low (for example, below a given threshold).

[0059] In one or more embodiments, the assessment of the risk associated with the autonomous triggering decision is performed by a machine learning (ML)-based risk analysis module 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 risk level, 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 makes it possible to simplify and streamline the user experience since the user does not need to perform any authentication action when the assistant autonomously makes 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 of 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 the virtual assistant is configurable so that the user can grant rights to the software application and / or the virtual assistant for 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 his requirements and / or his preferences relating to the autonomous triggering of operations. These parameters include for example: one or more authorized (or respectively prohibited) providers, the nature of the products or services which may be the subject of autonomous triggering, a maximum number of transactions authorized per period of time, a maximum amount to be paid if the operations are chargeable, etc.

[0065] [Fig.l] schematically represents a system 100 for triggering an operation according to an exemplary 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 service provider offering, for example via a catalog, 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 relating to an interaction of a user with the software application, an implicit intention of the user to trigger an operation relating to a product or a service.

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

[0069] A verification entity 150 is configured to receive, from the service provider's computer system 130 (or directly from the virtual assistant 120) a request for validation of a decision to autonomously trigger an operation and 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 computer system 130 of the provider.

[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 the contextual data collected by the virtual assistant and information about the detected operation.

[0071] The computer system 180 is configured to execute one or more operations. The computer system 180 may be part of the service provider's computer system 130 or be linked to the computer system 130 or even be a computer system of a third party involved in the execution of the operation to be executed. In the case where 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 risk level, that an operation is authorized, the verification entity 150 transmits to the computer system 180 a notification so that the computer system 180 executes the authorized operation.

[0073] In order to make the operation of the system more concrete and to illustrate its possibilities, embodiments will be described in detail with regard to figures 3 to 5 in the example case where the operation is a payment transaction: such transactions in fact require a high degree of security. These embodiments of figures 3 to 5 are generalized to any other operation.

[0074] [Fig.2] schematically represents a system 200 for triggering an operation allowing payment transactions to be carried out according to an exemplary embodiment.

[0075] The system 200 allows a software application 210 with an intelligent user interface (e.g., a virtual assistant) based on Artificial Intelligence (AI) to carry out actions leading ultimately to triggering a payment transaction on behalf of the user. This payment does not need the explicit consent of the user to be processed. The triggering of the payment transaction can be decided and requested autonomously following the detection, on the basis of contextual data relating to an interaction of the user with the software application 210 (or more particularly with the virtual assistant), of an implicit intention of the user to trigger an operation relating to a product or a service.

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

[0077] The intelligent user interface and / or the computer system 220 of the service provider may comprise a contextual data formatting module which collects, analyses, or even filters, the relevant data of the user, including his habits, his personal information and his 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 payment transaction for an order).

[0078] The provider's computer system 220 can receive, from the software application 210, the contextual data and enrich them with additional data such as user habits, user preferences, services and / or products in the provider's catalog. The provider's computer system 220 can enrich the 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 risk level (and therefore a confidence level) relating to the decision to autonomously trigger 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 service provider's computer system 220 to generate a risk level used to make a decision concerning the validation or refusal of the transaction.

[0081] For example, if the risk level generated by the risk analysis module is low (less than a non-zero threshold SI), then the transaction is authorized (i.e. validated). If the v is high (greater than a non-zero threshold S2), then the transaction is refused. If the risk level is between the thresholds SI and S2, then a doubt exists and the transaction can be refused or a process with “manual” consent (i.e. non-automatic and explicit consent from the end user) can be initiated to collect the user’s consent.

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

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

[0084] An additional check is performed here based on contextual data, possibly containing the customer's habits with respect to the merchant, purchase history, logs / transcriptions of exchanges between the autonomous assistant and the customer, among others. Based on this contextual data, a risk level is calculated and a decision is made based on the risk level (and possibly based on 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 linked to autonomous decision-making.

[0086] In one or more particular embodiments, when the smart user interface detects a purchase intent, the purchase transaction and associated payment is not immediately triggered. Instead, the smart user interface may wait for a defined period of time before being executed, 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 of time has elapsed, the user can no longer modify their request or cancel the payment, and only the risk level generated by the analysis 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 user needs, and inferring user implicit consent for payment decisions.

[0088] The system provides a frictionless, efficient and personalized digital service based on autonomous 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 them to make payment decisions. The system thus enables payments to be processed without the user's explicit consent.

[0090] The risk analysis module may, 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 identification of the object of the purchase, i.e. identification of a product or service to be purchased) and consent for 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 desire to complete the purchase / payment procedure.

[0092] When analyzing the context, the risk analysis module may determine that the purchase proposal generated by the assistant does not appear to meet the user's need. If the purchase proposal does not meet the need, then the payment should not be made, and therefore the risk is high. In addition, in the case where the purchase proposal by the assistant corresponds to the user's need, the risk analysis module also evaluates the interaction that gave rise to this proposal. If the context does not reveal a desire, at least implicit, on the part of the user to proceed with the proposed purchase, and therefore with the associated payment, then the associated risk is also considered high.

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

[0094] In a case where the user explicitly validates the payment with respect to the assistant, the risk is considered low regardless of the relevance of the purchase proposal from the assistant concerning the initial need. For example, in the case of a restaurant, the user orders a dish, the server takes the order, then comes back to see the user immediately after to indicate that the chosen dish is no longer available and offers the user something else. The user can still validate the order, even if it does not correspond exactly to his initial choice.

[0095] Further, 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 autonomously triggered operations and offers a highly personalized and efficient digital payment service.

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

[0098] [Fig.3] presents an example scenario with a payment transaction 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 embodiments, this autonomous virtual assistant is configurable to so that the user can delegate rights to this autonomous virtual assistant for the autonomous triggering of payment transactions and configure these rights. For example, the user can or cannot authorize this autonomous virtual assistant to make decisions for autonomous triggering of payment transactions and configure parameters of the autonomous virtual assistant according to his requirements and / or preferences relating to the autonomous triggering of payment transactions. These parameters include for example: a maximum payment amount, one or more authorized (or respectively prohibited) providers, the nature of the products or services that can be the subject of autonomous triggering of payment transactions, etc.

[0102] In the example scenario, the user does not communicate directly with the provider's platform. Instead, an autonomous 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 relating to an interaction of a user via an intelligent user interface, an implicit intention of the user to trigger a command relating to a product or a service.

[0104] Based on this detection, the autonomous virtual assistant decides to trigger autonomously, on the basis of contextual data, the order and the associated payment to the service provider (here a merchant) via an associated server (or more generally a computer system of the service provider) and a message including the 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, means of payment, etc.) usually used to place an order and make a payment, the contextual data used for risk analysis are attached or included in the data collected for processing the payment transaction.

[0106] The contextual data may be enriched with respect to those collected by the virtual assistant and which relate to the interaction and the content of the exchanges with the virtual assistant. The contextual data may include, for example, one or more elements from among: information on a user profile, information on the user's preferences, information on the user's uses with regard to 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 or included in the data collected for processing the payment transaction: this label is used to indicate the autonomous (AI-powered) nature of the decision to trigger the payment transaction to be carried out. This indication on the payment triggering method can 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 service provider's computer system to a verification entity so that the verification entity processes the payment transaction in order to determine whether or not to authorize the payment transaction.

[0109] The verification entity is for example an entity of a payment method provider or a payment service provider. This provider or service provider may be a service provider implementing a “Wallet” application or purse 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 on the basis of 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 relating to an order and in addition the contextual data (possibly enriched) and the label.

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

[0114] The contextual data is formatted, preferably encrypted, and then sent during step (307) to the risk analysis module for evaluation of the risk linked to the payment transaction. The results of this analysis are then transmitted to the verification entity during 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 on the risk level obtained. This explanatory information serving as justifications can be in text form and indicate on which contextual data the risk level is based. This explanatory information can be used so that a human being (on the provider or user side) 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 analysis of the transaction to the service provider's computer system during step 309.

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

[0120] The payment gateway determines based on the received encrypted data whether the transaction is approved or not. Payment checks may be performed by the payment gateway prior to executing the payment transaction. The verification performed by the payment gateway includes, for example, the usual checks relating to fraud detection, validity of payment means, etc. If the transaction is approved by the payment gateway, the payment transaction is executed and information on the completed transaction is sent to the service provider's bank in step (311). A confirmation of the order and payment is also provided to the service provider's computer system (step 312).

[0121] If, based on the results of the analysis received in step 308, the payment transaction is considered by the verification entity as valid but too risky (i.e. the risk level is higher than a non-zero threshold SI): two options are possible. In a first option, the transaction is refused, which ends 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 a second option, an explicit validation step (315) with possible strong authentication of the user can be carried out before executing the transaction: this second option can be chosen for example when the risk level is below the high threshold S2, but nevertheless above the low threshold SL

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

[0123] [Fig.4] corresponds to the same scenario as [Fig.3] and provides additional implementation details compared to [Fig.3]. The aspects and characteristics described in relation to [Fig.3] are applicable and combinable with those described in relation to [Fig.4],

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

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

[0126] Based on this detection, the autonomous virtual assistant makes a decision to autonomously trigger a payment transaction on behalf of the user and sends a request to trigger the transaction to the service provider's computer system on behalf of the user. By autonomous decision or autonomous triggering, it is meant here that the explicit consent of the user is not requested for this triggering and this decision.

[0127] In step 403, the service provider's computer system requests the verification entity to validate the payment transaction and provides it with transactional information on the payment transaction relating 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 service provider's computer system may ask the verification entity whether this verification entity has the capacity to process a payment transaction with autonomous triggering and the capacity 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 verification entity can 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 service provider's computer system responds to the request for autonomous triggering of a payment transaction from step 402 by indicating to the virtual assistant that processing of the transaction is not possible.

[0131] During step 407, following step 406 according to the first embodiment, the virtual assistant may decide to request validation from the user for the payment transaction. This validation may include authentication (preferably strong authentication) of the user, by entering authentication data in order to verify the identity of the user carrying out the validation.

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

[0133] During step 411, following receipt of the response to step 410, the service provider's computer system can ask the virtual assistant to transmit to it the contextual data on the basis of which the decision to autonomously trigger the transaction is based.

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

[0135] During step 413, following step 412, the service provider's computer system sends a transaction validation request by transmitting to the verification entity the contextual data on the basis of which the decision to autonomously trigger 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 verification 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 the present description. Step 420 may be executed 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 decision to autonomously trigger 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 whether or not to validate the payment transaction based on the obtained risk.

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

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

[0141] During step 441, following step 440, the service 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 the execution of the payment transaction.

[0143] In 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 service 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 triggered.

[0146] During step 460, the verification entity responds to the service provider's computer system by sending a notification indicating its decision to refuse the 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 refused. The process can stop there. Alternatively, the autonomous virtual assistant can request explicit consent from the user. Depending on whether the user consents or not, a "classic" process for triggering the execution of the transaction can be triggered or not.

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

[0149] The aspects and characteristics described in relation to [Fig.3] and [Fig.4] are applicable and combinable with those described in relation 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 a payment transaction on behalf of the user.

[0152] During step 512, the autonomous virtual assistant detects, on the basis of contextual data relating to an interaction of a user with a software application, an implicit intention of the user to trigger a command relating to a product or a 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 request to trigger the transaction 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] In step 514, the autonomous virtual assistant transmits to the service provider's computer system the contextual data on which the autonomous triggering decision is based. Alternatively, the transmission of the contextual data is done in step 512 and step 513 is not executed.

[0155] During step 515, the service provider's computer system requests the verification entity to validate the payment transaction and provides it with the transactional information of the payment transaction relating to the order. In addition to the usual transactional information relating to the payment to be made (amount, beneficiary, debtor, means of payment, etc.), the service provider's computer system sends the contextual data on the basis of which the decision to independently trigger 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 decision to autonomously trigger 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 service 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 carry out other checks on the payment transaction to be executed (e.g. fraud detection) before executing the payment transaction.

[0160] If step 535 is not executed following step 530, the transaction is refused 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 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 triggered.

[0161] [Fig.6] is a flowchart of a method of triggering an operation according to a example of realization.

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

[0163] In step 620, based on the detection, a decision to autonomously trigger the operation on behalf of the user is made without first requiring 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 operation.

[0165] In step 640, an indicator representative of a 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 actually to trigger the detected operation.

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

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

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

[0169] [Fig.7] is a flowchart of a risk analysis method according to an exemplary embodiment.

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

[0171] In step 710, contextual data about a user's interaction with a software application and information about a product or service-related operation to be performed are received from a verification entity, the operation having been identified based on the contextual data.

[0172] In step 720, an indicator is generated: this indicator is representative of 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 actually to trigger the identified operation. The operation is an operation that is the subject of an autonomous triggering decision based on the contextual data.

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

[0174] The verification entity is configured to make a decision whether or not to validate the execution of the operation based on the risk level 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] Additionally, 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 embodiment of [Fig.9]. This conditioning influences the result returned by the LLM model, as well as the approach used to arrive at this 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] [Fig.8] is a flowchart of a risk analysis method according to an exemplary embodiment. This figure illustrates a generic risk analysis algorithm.

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

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

[0183] In step 815, a multimodal formatting of the context into a 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 verified, a risk level is calculated in step 840 on the basis of the obtained interpretation. In addition, a transcription of the interpretation in natural interaction is generated in step 845: explanatory information on the risk level is generated.

[0186] This explanatory information makes it possible, for example, to highlight the contextual data that weighed the most in the risk assessment. In addition, transformations (meta concepts) of the content for reflection purposes (ideas) can be generated. For example, this explanatory information can indicate which parts of the content of the conversation with the virtual assistant were significant in the interpretation and / or generate new entries allowing an explanation of the content.

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

[0188] [Fig.9] is a flowchart of a risk analysis method according to an exemplary embodiment. It illustrates a risk analysis algorithm suitable for analyzing a conversation with a virtual assistant in text mode.

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

[0190] The risk level is determined based on highlights of a transcript of text content of the conversation with the virtual assistant and scores assessed for those highlights.

[0191] In step 910, the context of the interaction is retrieved. The context may include different types of contextual data as described herein in the different embodiments. The contextual data includes in this example text content of 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, highlights of the transcription are generated, a highlight corresponding to text content.

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

[0195] In step 922, the best highlights generated in step 920 are retained based on their respective assessments made in step 921.

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

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

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

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

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

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

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

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

[0204] In step 960, an overall assessment is performed based on the best thinking to generate a level of risk and explanations related to that risk.

[0205] Furthermore, the virtual assistant itself may rely on an LLM that interacts with the user to provide a service, for example by accessing the necessary information through a database of information of the product and service catalogs of the providers to 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] - Provide a safe, reliable, user-friendly and transparent payment experience;

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

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

[0210] - Analyze the interaction context to deduce the implicit consent of the user;

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

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

[0213] - Retrieve payment information (whether or not based on 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 standards of current payments.

[0215] The systems integrate intelligent modules enabling autonomous triggering of transactions and analysis of transactional risk related to an autonomously triggered transaction. The systems are capable of efficiently assessing transactional risks in real time and enabling smooth and secure transactions without requiring manual interventions. These modules are capable of handling the complexity and dynamic nature of AI-driven transactions and providing users with assurance that their transactions are safe and efficient.

[0216] In the description of the different phases and methods, although the steps are described sequentially, certain 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 methods described in this document may 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 methods described in this document may be implemented by software (e.g., via software on one or more processors, for execution on a general purpose or special purpose computer) and / or be implemented by hardware (e.g., one or more circuits, and / or any other hardware component).

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

[0220] This software / program may be coded using any programming language, and 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 desirable form.

[0221] The host device (respectively system) may be implemented by one or more physically distinct machines. The host device (respectively system) may generally have the architecture of a computer, including one or more components of such architecture: data memory(s), 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 method or of another method described in this document are implemented by a device or system provided with means for implementing these steps of this method.

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

[0224] These means may comprise for example one or more configured circuits to perform one or more or all of the steps of one of the methods described herein. These means may comprise, 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 perform one or more or all of the steps of one of the methods 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 the set of functions, according to what is described below for the means concerned.

[0226] The present description also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.

[0227] The information carrier may be any hardware 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 magnetic tapes, hard disks or optically readable digital data storage media, or any combination of these media.

[0228] In some cases, the computer-readable storage medium is not transient. In other cases, the information medium may be a transient medium (e.g., a carrier wave) for transmitting a signal (electromagnetic, electrical, radio, or optical signal) carrying the program instructions. This signal may be conveyed via a suitable transmission means, 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 methods 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

Claims

1. A method for autonomously triggering at least one operation, the method comprising: detecting (610), based on contextual data relating to a user's interaction with a software application, an implicit intention of the user to trigger an operation relating to a product or service; based on the detection, deciding (620) to autonomously trigger the operation on behalf of the user without first requiring explicit consent from the user; transmitting (630) a risk analysis request to a machine learning-based risk analysis module, the risk analysis request including the contextual data and information on the detected operation; receiving (640) from the risk analysis module an indicator representative of a level of risk that the user's intention is not to trigger the detected operation;a decision-making (650) for determining, based at least on the indicator, whether the operation is authorized or not.;

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

3. A method according to claim 1 or 2, comprising: when the operation is not authorized, an operation to obtain explicit consent from the user and / or to require authentication of the user.

4. Method according to claim 1, comprising: when the indicator is lower than a first threshold value and higher than a second non-zero threshold value, sending to the user a request for explicit validation of the triggering of the operation; when the indicator is higher than the first threshold value, sending a notification of refusal of the operation; when the indicator is lower 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 preceding claim, comprising: 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 preceding claim, wherein the software application is or comprises a virtual assistant and the contextual data comprises content of an interaction with the virtual assistant.

7. Method according to any one of the preceding claims, in which the analysis request includes at least one piece of information from among: information on a user profile, information on the user's preferences, information on the user's usages, information on a recommendation of a product or service, information on a history of operations triggered for the user.

8. Method according to any one of claims 2 to 7, in which the operation is a payment transaction for the purchase of at least one product and / or at least one service, in which the notification is a payment notification, the risk level taking into account on the one hand the fact that the purchase seems to meet the user's need and on the other hand that the user's intention is actually to make the payment.

9. System comprising computer means for implementing a method for autonomously triggering at least one operation, the method comprising: a detection, on the basis of contextual data relating to an interaction of a user with a software application, of an implicit intention of the user to trigger an operation relating to a product or a service; on the basis of the detection, a decision to autonomously trigger the operation on behalf of the user without first requiring explicit consent from the user; a transmission of a risk analysis request to a risk analysis module based on machine learning, the risk analysis request including the contextual data and information on the detected operation; a receipt from the risk analysis module of an indicator representative of a level of risk 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.

10. A risk analysis method, comprising: receiving (710), from a verification entity by a machine learning-based risk analysis module, contextual data relating to a user's 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; a generation (720) by the risk analysis module of an indicator representative of a level of risk that the user's intention is not to trigger the identified operation; a transmission (730) of the indicator to the verification entity.

Images