EP4352681A1 - Système et procédé de chargement de données sécurisées dans un environnement informatique sécurisé multipartite - Google Patents

Système et procédé de chargement de données sécurisées dans un environnement informatique sécurisé multipartite

Info

Publication number
EP4352681A1
EP4352681A1 EP22803502.8A EP22803502A EP4352681A1 EP 4352681 A1 EP4352681 A1 EP 4352681A1 EP 22803502 A EP22803502 A EP 22803502A EP 4352681 A1 EP4352681 A1 EP 4352681A1
Authority
EP
European Patent Office
Prior art keywords
data
user
offers
offer
data tables
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22803502.8A
Other languages
German (de)
English (en)
Inventor
Edison U. Ortiz
David Ian Mckay
Christoph KNOESS
Seung Bong BAEK
Ravi KHANDAVILLI
Adel Al Nabulsi
Arnold Badal-Badalian
Justin Simonelis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Royal Bank of Canada
Original Assignee
Royal Bank of Canada
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/701,612 external-priority patent/US20220301013A1/en
Application filed by Royal Bank of Canada filed Critical Royal Bank of Canada
Publication of EP4352681A1 publication Critical patent/EP4352681A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/092—Reinforcement learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/387—Payment using discounts or coupons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/004—Artificial life, i.e. computing arrangements simulating life
    • G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]

Definitions

  • Embodiments of the present disclosure generally relate to the field of computerized prediction generation, and more specifically, embodiments relate to devices, systems and methods for establishing data linkages for use in provisioning offers and coupons, and operating privacy-enhanced offer and coupon campaigns.
  • cookies In an effort to protect customers, increased scrutiny of “cookies” based approaches has led to restrictions on their availability and usage. However, existing implementation of “cookies” based approaches are fragmented in their approach to adhering to user consent opt-ins / opt-outs, and it is practically very challenging for users to determine and/or manage their consents once given (e.g., accidentally through a mis-click of a button on a “cookies consent banner” widget surfaced on a website). An alternative to “cookies” is proposed herein using a privacy enhanced computing architecture.
  • a computational approach is proposed herein for controlling a user interface for rendering of interactive graphical control elements representing offers and coupons that are inserted into a computational payment process.
  • the offers and coupons can interact with stored payment information resident (or tokens thereof) on a digital wallet data structure.
  • the approach can be implemented as a computing system, a computing method operable on a computing system, or a computer program product affixed in the form of a non-transitory computer readable medium storing machine-interpretable instructions.
  • VCR always protected data storage mechanism
  • Queries for example, can be limited to queries that do not yield specific outputs corresponding to one or a small number of users, or can be limited to queries such as counts, or an overall holistic score associated with a group of characteristics where the holistic score cannot be easily unwound to identify the constituent values. Queries for sensitive data fields can also be transformed or limited in their output (e.g., while the data table may have actual addresses, the query can only interact with an obfuscated or less precise version of the actual addresses, such as postcodes, proximity regions).
  • Consent can be validated for each and every query through comparing against a consent field present in a database field or, in some embodiments, in a global user database, such that user consent can be readily verified and/or given or revoked by the user, propagating across for all future query responses.
  • the query responses are utilized to update a database record corresponding to the users stored on the always protected data storage that is not accessible by queries from merchant or advertising users.
  • a merchant or advertising campaign may identify characteristics of a target audience for a particular offer or coupon or other promotion, and while the system can be used to target these users to present the offers, coupons, or other promotion, the merchant or advertising campaign may have limited or no access to the list of users that were identified as targets. Accordingly, users can be further protected such that the provision of offer, coupon, or other promotion information can be provided in a one-way push, with tracked feedback potentially limited to whether a user has interacted with or used the provisioned offer, coupon, or other promotion information.
  • the always protected data storage mechanism limits the types of query interactions such that the campaigns are unable to obtain access to information that is not necessary for the campaign. This is important for providing a cross-party solution where cross-party data could otherwise be potentially used maliciously, and provides a cross-data set solution between parties having differing levels of technical sophistication and available computing infrastructure.
  • the always protected data storage mechanism serves as common infrastructure for which the parties are able to load their data for increased analytics (e.g., having access to the otherwise silo-ed data of other parties) while providing additional safeguards for adhering to user consents and privacy.
  • the data elements are loaded as individual data tables corresponding to each of the participating data sources into the always protected data storage.
  • These participating data sources can include insurance companies, financial institutions, merchants, loyalty / reward programs, among others, and the data elements can include user data, product data (e.g., SKU-level data), pricing data, inventory data, among others.
  • the always protected data storage can be interacted with using a campaign computing interface (e.g., an advertising campaign computing interface), which is configured to provide query requests to the always protected data storage to obtain query responses or to update a user table or a campaign table stored on the always protected data storage with flagged users or candidate transactions (if the audience list is configured not to be made available to the original requester).
  • the query request can be provided through a graphical user interface, such as a web-based advertising campaign control platform, or through a command line interface, or through an application programming interface (API) with exposed functions.
  • the query request message can, in some embodiments, include various consents from users, or consents from data sources to access the protected data tables.
  • the always protected data storage system receives the query request message and processes the message by first validating the query request message, loading the relevant database tables into memory, and then running the query across the relevant database tables or a combination thereof, for example, combined using various types of JOIN commands.
  • the query request messages are run in batch (e.g., the tables are loaded and then a large volume of queries are run), while in other embodiments, the query request messages can be run ad-hoc.
  • the query response itself can also be processed for validation as a second safety mechanism to ensure that the query response also adheres to various restrictions for user privacy / consent.
  • an optional post-processing validation step can be used to ensure that no sensitive information, such as actual addresses, ages, names, etc. are exposed in the query response.
  • the query request can include Boolean statements or logical criterion, and in some embodiments, can also include a score-based query. For example, a number of criterion can be associated with different score contributions, and users having a contribution score greater than a threshold are identified and/or flagged as potential audience members for an audience list for the campaign.
  • the query response itself is used to flag user accounts that match the criterion in a query request, as opposed to providing identifiable responses, and the query response itself simply indicates that internally within the always protected database, the corresponding users have been flagged (without responding with any identifiable information).
  • the flagged accounts can be interacted with through the always protected database system, for example, in a push approach where coupons and offers are pushed to those users without the marketing or merchant computing systems ever having access to the identities or contact information of those users, or a pull approach where when corresponding users interact various triggering actions on a website or a mobile application, the interaction causes the rendering of an offer or coupon, or other promotional item.
  • triggering conditions are possible, but in an example a trigger could occur, for example, when the user is in a checkout state on a website (e.g., as obtained probabilistically or deterministically by parsing the URL) or when the user is accessing stored checkout details, such as card information stored in a digital wallet or in a wallet mobile application.
  • a feedback loop may established to help train a machine learning model based on tracked intents and actual purchase outcomes, including offer and/or coupon uptake and interactions.
  • the system can be implemented as a physical computing appliance, such as a dedicated server residing in a data center, coupled across various networks, such as the internet, to data sources of various third party partners.
  • Query requests can be received alongside consent information in the form of data messages across a message bus, to be processed by the system using an always protected database loading mechanism.
  • the always protected database may be configured to restrict access and/or delete combined or derived data following usage or query completion.
  • the system outputs may be utilized to control a graphical user interface or a website content management system to render or otherwise surface one or more interactive visual interface elements representative of offers, coupons, or other promotional materials. These interactive visual interface elements can be inserted in the form of widget bars, radio buttons, checklists, etc.
  • the system outputs for example, can include audience lists, updated data tables, new data tables, among others.
  • FIG. 1 is a block schematic diagram of an example data process linkage system, according to some embodiments.
  • FIGS. 2A-2C are block schematic diagrams showing portions of the data process linkage system in more detail.
  • FIG. 3 is an example schematic of a data flow diagram for the orchestration engine, according to some embodiments.
  • FIG. 4 is an example schematic of a computing architecture for the orchestration engine, according to some embodiments.
  • FIG. 5 is an example rendering of an improved display having a combination of a web shopping webview augmented with visual interface elements based on the data linkages, according to some embodiments.
  • FIG. 6 is an example schematic of a computing system or device that can be utilized in implementing the data process linkage system, according to some embodiments.
  • FIG. 7 is an example rendering of deals that may be presented on a user interface, according to some embodiments.
  • FIG. 8 is an example schematic of a reinforcement learning model, according to some embodiments.
  • FIG. 9 is an example rendering of clustered search results for a semantic search, according to some embodiments.
  • FIG. 10 is an example rendering of a data representation of coupon to coupon network, according to some embodiments.
  • FIG. 11 is an example rendering of a data representation of merchant to coupon network, according to some embodiments.
  • FIG. 12 is an example rendering of a next merchant display rendering, according to some embodiments.
  • FIG. 13 is an example rendering of a search bar, according to some embodiments.
  • FIG. 14 is an example flow diagram of a relevancy enhancement, according to some embodiments.
  • FIG. 15A, FIG. 15B, and FIG. 15C are screenshots that illustrate an example coupon or offer loading process flow whereby an offer or coupon may be loaded onto a wallet application and associated with the user, according to some embodiments.
  • FIG. 16A, FIG. 16B, FIG. 16C, and FIG. 16D are screenshots showing an example coupon or offer redemption process flow where an offer for an example heirloom salad kit is being applied and ultimately redeemed, according to some embodiments.
  • FIG. 17 and FIG. 18, are example systems architectures of a system utilizing a trusted execution environment, according to some embodiments.
  • FIG. 18 is a more complex example relative to FIG. 17 showing a number of trusted execution environments controlling access to a plurality of underlying secured database tables, according to some embodiments.
  • Coupons and offers are utilized by companies to improve awareness of their products, and different approaches are utilized to allow for the provisioning of and ultimately, the redemption of the coupons and offers. Coupons and offers aid in encouraging or maintaining purchasing behaviour across temporal dimensions - for example, a user may “clip” or otherwise attach a coupon or an offer for later usage by having it saved or associated with the user’s account, and the user may later apply this coupon or offer in a later transaction. Coupons and offers, in some implementations, can be coupled with undesirable behaviour trackers that a user may not be aware of, such as tracking cookies, unique URLs, among others, which can leak personal information about the user in the context of the purchasing transaction.
  • a digital offer or coupon is made available to a user (e.g., through an interactive control element that the user interacts with, or pushed out to automatically to an audience of users), and the digital offer or coupon is then loaded onto a data structure representative of a digital wallet of the user.
  • the presence of the offer or coupon can be re-surfaced (e.g., rendered onto a corresponding display of a user interface) such that the user is able to observe that a price or quantity (or other characteristic of the transaction) is modified if they choose to apply the coupon or offer.
  • the user may select to apply the coupon or offer (or it may be automatic in some embodiments), and the reduced price / improved offer is automatically provisioned during the payment step, such that the price ultimately charged to the user or the user’s account by an issuer is reflective of the reduced price / improved offer without having to undertake the inconvenience or additional processing required with after-the-fact type redemption tracking, such as affiliate links, statement credits, among others.
  • the approach is implemented on computing components, including computing systems and computer processors / servers that provide a digital payments backend to support payment transactions that can take place across a diversity of different payment mechanisms, such as in-store payments, web-based payments, and in-app payments, among others.
  • “virtual clean room” type trusted execution environment back ends can be utilized for storing and processing sensitive information, such as audience lists for particular campaigns, the specific coupons or offers that are associated with various wallets, and the redemption status of the coupons or offers. This is particularly important where the “virtual clean room” type trusted execution environment is configured to aggregate data sets from multiple data sources together that do not trust one another or cannot trust one another for generation of the target audience list (e.g., the audience list is generated from a JOIN operation from two database tables from separate entities), or where there are privacy considerations where a user cannot or should not be tracked between sessions.
  • the “virtual clean room” type trusted execution environment in this example provides an “always protected database” mechanism can be configured to interoperate with merchants and offer tracking systems to obtain a list of merchant store keeping unit (SKU) level transactions, which can then be utilized for offer campaign provisioning through the pushing of coupons and offers to user devices for later use, including targeted offers.
  • SKU merchant store keeping unit
  • the always protected database is a computational mechanism that restricts access to data accessible from or stored thereon.
  • Queries are received by the always protected database and are validated for adherence to policy requirements of the always protected database, and these policy requirements can be field level (e.g., social insurance numbers, addresses, names, post codes), data value level (e.g., celebrity / VIP address), or source level (e.g., insurance companies may implement a strict privacy regime).
  • Query validation can include restricting the query to only a few pre-approved query types made available in the interface, or in some embodiments, automated approaches to validate queries to ensure that sensitive information is never returned or exposed as part of the query response.
  • Policy requirements may also be associated with individual rows of the database associated with particular users, etc., and in some embodiments, each of the policy requirements can range from obfuscation requirements (e.g., can never be returned as an actual value, only can be returned as a count, or can only ever be returned in groups of >50 results with the identifier field never being shown), consent requirements (e.g., a signed data object or a key is required to be adduced alongside the query to obtain this information), among others.
  • obfuscation requirements e.g., can never be returned as an actual value, only can be returned as a count, or can only ever be returned in groups of >50 results with the identifier field never being shown
  • consent requirements e.g., a signed data object or a key is required to be adduced alongside the query to obtain this information
  • the always protected database a plurality of data tables are available from the various sources, and during query processing, the always protected database loads at least two of the data tables from different entities together and combines them together for a cross-table analysis.
  • the combination can include a logical JOIN command, among others, and various permutations and combinations thereof of query commands.
  • the JOIN command can include the use of a shared related column that is used as a primary or a foreign key, and as described in various embodiments here, the primary key need not be the same for every query operation between two tables. For example, two tables of incomplete information from two separate parties may alternate between different fields being used as primary keys in an attempt to address various gaps resulting from the incomplete information.
  • Various types of joins are possible, such as LEFT JOINs, RIGHT JOINs, INNER JOINs, and OUTER JOINs.
  • query commands can be used on the combined table, such as conducting selections, counting, comparisons, among others, and these query commands can be utilized to represent elements of logical conditions which are utilized to identify particular records to be counted or selected for output, etc.
  • the combined table can be analyzed together in responding to the query, for example, searching vehicle purchase data table alongside an insurance payout data table to help a researcher confidentially identify liability statistics for a particular type of minor fault with the vehicle during manufacturing.
  • a class-action lawsuit payout can be initiated for specific parties using information from the vehicle purchase data table alongside the insurance payout data table.
  • specific consent can be provided and obtained, and the existence and usage of the cryptographic keys can be used in future audit situations to demonstrate that the information was only made available in accordance with user consent (e.g., to help establish that a payout should occur to assist the parties of the class action lawsuit with the required repairs).
  • the query can be received from a campaign management process, such as an advertising campaign management process, an insurance payout management process, a research campaign management process, among others, and these can be provided in the form of Javascript object notation (JSON) messages, extended markup language (XML) messages, among others, or query language messages, indicating the set of logical conditions, and/or the type of response output requested from the system.
  • a campaign management process such as an advertising campaign management process, an insurance payout management process, a research campaign management process, among others
  • JSON Javascript object notation
  • XML extended markup language
  • query language messages indicating the set of logical conditions, and/or the type of response output requested from the system.
  • the campaign process may receive the audience list data structure potentially identifying the relevant users identified for a particular campaign (e.g., a municipality environmental campaign seeking addresses of all purchasers of washing machine SKU 111992948 in post code 90210, to inform them of a promotion to replace their washing machines with eco-friendly alternatives), or in another embodiment, the campaign process generates an audience list that is maintained on the always protected database but not accessible to the campaign process.
  • a particular campaign e.g., a municipality environmental campaign seeking addresses of all purchasers of washing machine SKU 111992948 in post code 90210, to inform them of a promotion to replace their washing machines with eco-friendly alternatives
  • the campaign process generates an audience list that is maintained on the always protected database but not accessible to the campaign process.
  • This alternate embodiment can be used for advertising campaigns where user privacy is maintained in a one-way communications approach whereby the system can be triggered to automatically send messages, communicate, push digital elements (e.g., offers, coupons) into digital wallets (e.g., a digital coupon book) or render visual interface control elements injected into a checkout process, into rendered advertisements, or coupons and offers visual control elements that can be interacted with to apply various discounts, show various information elements, among others.
  • push digital elements e.g., offers, coupons
  • digital wallets e.g., a digital coupon book
  • render visual interface control elements injected into a checkout process into rendered advertisements, or coupons and offers visual control elements that can be interacted with to apply various discounts, show various information elements, among others.
  • privacy is further enhanced as the campaign process does not receive access to the audience list but rather, the audience list is either used for push or pull interactions initiated by the user actions for communications between the always protected database and the user’s device.
  • a user’s purchase interaction may utilize a digital payment mechanism that is coupled to an issuer computing device that requires approval from the issuer computing device.
  • the “virtual clean room” type trusted execution environment may be interacted with to check whether there is a valid offer or coupon to be processed, and if it is determined to be a valid offer or coupon, the “virtual clean room” type trusted execution environment may send a data message to the issuer computing device to modify the transaction such that the price ultimately paid is reduced or modified in accordance to the offer or coupon.
  • the interjection from the “virtual clean room” type trusted execution environment occurs at the issuer payment processing operation, obviating a need to conduct post-processing to map transactions to offers and coupons.
  • the trusted execution environment includes a plurality of secure database tables that are loaded with user data from a plurality of data sources loaded and encrypted in accordance with a set of digital security permissions, and the trusted execution environment is configured to validate, using a data custodian data process, processing of the eligibility query data message to ensure adherence to the set of digital security permissions.
  • the digital security permissions can include limitations on access rights, query responses, among others, and can be unlocked, for example, with the provisioning of a corresponding encryption key for access (e.g., from a merchant device or from a user).
  • the trusted execution environment is configured for a comparison of whether the user trying to redeem a digital offer or a coupon corresponds to one or more targeted users identified in the plurality of secure database tables.
  • the one or more targeted users can be identified through a query operation of a user list that is provided on one or more secure database tables.
  • a number of different organizations may provide separate user lists and a JOIN operation can be used to identify an intersection of users who should be provided a particular digital offer or coupon (e.g., University students in their first year of a co-operative program who also have not yet opened a tax-free savings account and have more than $500 in a low-interest savings account - database tables can, for example, be from the University enrollment records, and a financial institution (e.g., a bank)’s user account records).
  • a financial institution e.g., a bank
  • the validation may occur at different points in a digital transaction processing data process, for example, the validation step may occur when the digital offer or coupon is being loaded onto a digital wallet of the user (e.g., coupled to the user’s mobile device in a secured element thereon), or during redemption of the digital offer or coupon, or at both times.
  • FIG. 1 is a block schematic diagram of an example data process linkage system, according to some embodiments.
  • the data process linkage system 100 is adapted for an eCommerce platform having improved capabilities in linking data representations of intents and data representations of outcomes, such that a computer processor can transform data sets representing offers and/or promotions based on tracked data linkages.
  • the system 100 is a network linked system having an intent tracker system 102, a financial institution system 104, and an online and mobile banking application 106, which can be separate computing systems whose operations are orchestrated together by the financial institution system 104.
  • the network can include a local area network, or a wide area network, such as the Internet.
  • the data process linkage system is utilized as an input into an always protected database, such as the virtual clean room as described herein.
  • the data process linkage system is utilized to receive, for example, through a connected web browser or web search SDK, a user’s browsing history, returned websites, sent queries, and/or other interaction information, and enter into the always protected database either the raw data or a transformed version thereof.
  • a user data table can be populated with the user’s queries, extracted elements from the response pages indicative of the user’s browsing / navigation history, among others.
  • the user data table is populated instead with derivative data derived from the user’s raw data, such as a user profile indicative of particular search trends, demographic information, preferred usage channel (e.g., smartphone browser, mobile application, desktop browser), among others.
  • the user data table includes both raw and transformed data.
  • the user data table can include specific consent fields that can be coupled to particular rows, fields, or the entire data table. These consent fields can include a consent key, a signed message requirement, among others.
  • the consent fields in an example, can be coupled with privacy policies such that, for example, with consent, the entirety of the user data table can be returned as a response result, or without consent, the user table can only be used for aggregated data or one-way push audience lists only, among others. Variations are possible.
  • the consent field can include a value for a cryptographic key to be provided, which, can include a private key corresponding to a stored public key in the field. An example table is provided below.
  • the consent field includes a public key, and when a consent is to be provided, a digitally signed message (using the corresponding private key) is required to be sent which can then be validated using the public key. This is useful, for example, where the user or the user’s device maintains the private key and avoids exposing the private key.
  • the system may be configured to require a message with the studentID be encrypted using the student’s corresponding private key before allowing access to sensitive information, such as the user’s academic average.
  • sensitive information such as the user’s academic average.
  • the user’s graduation year may be accessible without the private key.
  • An intent tracker system 102 shown in more detail at FIG. 2A, is provided that generates a first data set representative of intents, and this information can be tracked by way of web search query history, internet set browse / traversal history, entered keystrokes, trackable aspects of various eCommerce gateways (e.g., data objects representing specific products / services included in a shopping cart), among others.
  • the user may be able to log in using the user’s credentials, and the first data set can thus be associated with the user through, for example, an account associated with a user profile (e.g., stored in an intent tracking active directory).
  • Web search history can be obtained, for example, through monitoring URL activity or HTTP messaging, such as GET/POST information for variable extraction, among others.
  • Responses from websites can also be processed to obtain this information, for example, responses to queries sent, specific links clicked that indicate a particular browsing path, etc.
  • web search history can include a search for “best graphics card for playing games”, “best graphics card under $1000”, “promo code 3080 ti”, “3080 ti review”, “graphics requirements to play latest flight simulator”, and “what is ray tracing”.
  • Each of these queries can be tracked as a character string or a set of tokenized words.
  • the user may also be navigating pages, and the navigation through the webpages can be tracked through “a href” links, as well as the response pages through http document structures that can be obtained through a dom tree analysis. The user’s navigation (both inputs and http responses) can thus be utilized to add additional intent inputs that can be provided in the form of strings.
  • navigation inputs can include “in store pick up”, “shipping costs”, “Waterloo, ON location store hours”, “graphics cards”, on a retailer site, or for a retailer website, or on a review site “best graphics cards for a budget”, “upgrade pick”, “budget pick”, among others.
  • the navigation inputs can be obtained through the URLs that a user is traversing, or intercepting source http responses and processing them to extract information from header or body portions.
  • These intent inputs can be characterized as separate inputs and associate with the user through a primary key associated with the user based on the user being logged in to improve relevancy, for example.
  • the primary key may be stored in the user’s profile, and can include a user number, user identifier, etc.
  • the primary key can be changed from time to time to enhance privacy, and the primary key is known only by the user and the user’s device, and can for example be stored on a secure partition or other secure computing element such that the primary key cannot be used for other purposes.
  • the underlying intent inputs are purged after processing for extraction of input features to further enhance user privacy.
  • semantic expansion can be used to add additional inputs for machine learning, expanding the set of available features at the cost of performance and storage in the machine learning model that may be maintained over time in the user’s profile.
  • semantic enhancement includes introducing semantic variants to replace and/or augment the intent inputs. For example, a search for “Disney” could include replacing with variants based on the most popular related search terms, such as “Disney vacation”, “Orlando travel”, as determined based on semantic similarity and/or popularity with other users, for example.
  • the “tightness” of the semantic expansion could be iteratively reduced if not many offers (e.g., less than a pre-defined number) are ultimately surfaced by the system so that the number of offers shown is below a certain amount of offers, to avoid presenting an empty list of offers.
  • the user’s profile may be associated with personalization data, and the intent tracker system 102 may be configured to generate an initial set of offers and/or promotions.
  • the promotion data object can include a prioritized list or an array of potential purchases. For example, a user may be seeking to buy a new computer, and is searching specific components to be purchased separately (e.g., RAM, power supply), in one or more transactions (e.g., at different stores). Offers and promotions can be associated with machine learning / personalization rewards and penalties, and when they are interacted with or selected, an interaction data representation can be obtained for processing potential outcome features for an outcome feature set. The set of outcome features can then be re processed to tune the linkage representations between the intents and outcomes to update a model representation for the user.
  • the intent tracker system 102 may not have access to outcome information (e.g., whether the user actually went through with a purchase, or purchased through other purchasing portals).
  • outcome information e.g., whether the user actually went through with a purchase, or purchased through other purchasing portals
  • the initial set of offers and/or promotions may be poorly tailored, obsolete, or irrelevant (e.g., surfacing a promotion for an item that the user has already purchased in store).
  • Offers can be presented without an actual query, based on an imputed query based on the user’s profile (e.g., estimating a next query based on past queries and outcomes). In another variation, offers can be presented based on a specific query of offers (e.g., the user searches offers relating to “Disney”).
  • the offers can be presented in the form of rendered advertisements, or through other approaches such as a modification in an order of search results to improve relevance to the user’s query beyond the word tokens in the query (e.g., using the personalized information from the user’s profile).
  • the rendered advertisements can be represented using data, variables, and string representations of the advertisements, such that various features of the advertisements are also tracked as features.
  • an advertisement may have associated retailer features (e.g., a stringRetailer, or numberRetailerlD), channel features (e.g., isMobile, isDesktop, islnStore), and these features may be provided, for example, in different variable types, such as strings, characters, values, integers, among others.
  • Offers can also be presented in the form of coupons and offers that reside on or are coupled to a digital wallet of the user, such that when the user’s session transitions to a checkout state or shows specific information relating to a particular item (e.g., as identified by SKU) or merchant, a coupon or offer is automatically shown on the screen as an interactive visual interface element, and when interacted with, the coupon or offer is applied such that the checkout process can reflect a new or updated price.
  • Offers and coupons can be generated based on a push basis (e.g., all users on the audience list who has given consent to be provided offers and coupons automatically have them loaded into their corresponding digital wallets automatically), or on a pull basis (e.g., all users when entering a checkout process or a browsing process showing individual SKUs will ping the always protected database with a request to check if the user is on the audience list, and if so, then the offer and coupon may be shown to the user.
  • a push basis e.g., all users on the audience list who has given consent to be provided offers and coupons automatically have them loaded into their corresponding digital wallets automatically
  • a pull basis e.g., all users when entering a checkout process or a browsing process showing individual SKUs will ping the always protected database with a request to check if the user is on the audience list, and if so, then the offer and coupon may be shown to the user.
  • a push basis e.g., all users on the audience list who has given consent to be provided
  • the offers can be dynamic for each user, for example, based on a targeted audience that is developed for a particular campaign.
  • aspects of the user’s profile can be used to create a tailored selection of users. For example, a campaign may be targeting users who appear to be interested in graphics cards, be in a 20-35 age range, have searched “graphics card reviews”, while having profiles linked to their social media services.
  • weighted score elements such that the audience only consists of those who have a weighted score greater than a particular number. For example, previously abandoned shopping cards could yield a score of 20, a previous search in the area of interest could yield a score of 1, and the existence of a membership at a gaming website could yield a score of 5, among others.
  • the weighted score can be assessed when the campaign is initiated to generate the initial audience list, appending an audience flag for the user, or, in another embodiment, the weighted score can be assessed dynamically in real-time upon triggering during a checkout state transition or a browsing state transition, among others.
  • a triggering event is detected during computational interactions by the user in the mobile interface or a website, and these triggering events can include website transitions, purchase state transitions, changes in URL (e.g., the URL has changed to a URL associated with a checkout), and in further embodiments, the triggering event may include the presence of a particular SKU being listed on a webpage (as extracted from the received HTML).
  • a listener process is maintained on a mobile application to identify and/or intercept an activation command for a digital wallet or payment process to be launched, such that offers and coupons can be inserted in real-time into the digital wallet or payment process in the form of interactive visual interface elements.
  • Real-time assessments of all of the components of the score may be computationally complex, so in some embodiments, only a differential is determined from the portion of the weighted score elements that are prone to change over time.
  • a relatively static portion of the weighted score elements may include gender, post codes, while a dynamic portion of the weighted score elements may include search history, abandoned digital shopping carts, among others.
  • the audience list represents the audience identified across the one or more data tables of the always protected database, and the audience is represented through flagging various user accounts or responding with a data set indicative of identifying information or identifiers associated with the particular user accounts.
  • the identifiers can be proxies for identity to help preserve privacy.
  • the audience list can be a separate data table in an embodiment, which can then be combined with other data tables using a primary key whenever the audience list is needed to be used alongside other data.
  • the audience list is a set of data records that are appended onto an existing data table.
  • the audience may be specifically generated for example, to generate maximum word of mouth for a particular product, and this is useful especially where availability of a particular product or service is scarce.
  • the offers can also have dynamic features and characteristics, such as variations on an offer are generated by perturbing various characteristics of the offer (such that a most favorable version of the offer would be presented based on tracked characteristics of the user or past preferences). For example, for a particular user, two for a discount deals are tracked in the user’s profile as being of particular interest (e.g., unbeknownst to the system, the user often buys items having such a discount to share with a spouse).
  • the user may be single, and the system may be configured to automatically bias away from two for a discount type deals, because the user typically does not have anybody to share the second product with. Rather, for this user, a smaller direct discount may be of more interest.
  • the interest can be computationally represented through the features stored in the user’s profile and in the weighted linkages between nodes that represent the linkages between intent features and outcome features.
  • the linkages and profile representations are updated and refined such that, in this example, the profile representation begins automatically favoring a type of offer or coupon.
  • a benefit of using semantic tokenization of query and navigation intent features is that the system is now able to automatically capture additional non-linear and non-direct relationships that would otherwise be difficult for a retailer to tune for. For example, a particular user may conduct a large amount of research on large, expensive purchases, conducting significant price comparisons and reading reviews, and the user profile, through intent information may be adapted to automatically recognize this behavior.
  • offers that will be surfaced by the system 102 may include only offers having a particular level of discount
  • the profile may indicate a preference towards free or expedited shipping (e.g., increased convenience), and offers and coupons can be tuned or selected to emphasize convenience related options.
  • the intent tracker system 102 securely interoperates with a trusted execution environment (e.g., a “virtual clean room”), where the first data set representative of intent-based interactions with the eCommerce web pages associated with a specific user is loaded along with a set of privacy related information that can be used for securing the first data set.
  • a trusted execution environment e.g., a “virtual clean room”
  • the trusted execution environment maintains the always protected database and the integrity thereof.
  • the trusted execution environment segregates the always protected database such that query interactions are limited and the data tables themselves may not be directly accessible by the various parties.
  • the trusted execution environment may be configured such that the information stored thereon is not accessible external to the trusted execution environment, and the trusted execution environment may receive or be loaded with one or more encryption keys associated with the user such that the user is able to control an amount of access or a query level associated with the first data set by, in some embodiments, providing a privacy preference setting information data object to the data custodian of the trusted execution environment, or in other embodiments, providing a specific encryption key that allows the trusted execution environment to access the loaded data only to a particular level of permissions (e.g., only aggregated information, only certain fields).
  • a privacy preference setting information data object to the data custodian of the trusted execution environment
  • a specific encryption key that allows the trusted execution environment to access the loaded data only to a particular level of permissions (e.g., only aggregated information, only certain fields).
  • the system 100 provides an architecture having a data processing orchestrator device or service provided by financial institution system 104 (shown in more detail at FIG. 2B) which securely interoperates with data sets at various points in time associated with a set of eCommerce interactions a user may have with computer systems.
  • the data sets are obtained from different data repositories, and are combined together for analysis such that the first data set representing intents (e.g., web search / browse history) can be combined together with a second data set representing outcomes (e.g., purchase transaction history, web site shopping carts).
  • intents e.g., web search / browse history
  • outcomes e.g., purchase transaction history, web site shopping carts
  • the second data set can be obtained, for example, from payment processor engines, and tracks the actual outcomes of various transactions to determine whether they were consummated or not, and what coupons or offers were applied.
  • the second data set can be obtained having differing levels of transaction specificity. For example, in some embodiments, the second data set only has a user identifier along with an aggregate amount spent on a particular transaction at a given time for a merchant or vendor.
  • the second data set in this example may be limited such that it does not have SKU level information.
  • the system 104 may be configured to take additional steps in creating linkages to estimate SKU level information.
  • the second data set can be obtained having SKU level information readily available such that individual products and services associated with the transactions can be identified.
  • Linkages can be established, for example, based on temporal proximity to a purchase, whether the purchase was conducted in a same window or sessional instance, whether the purchase was related to a particular semantic string identified in the recent intent tracking input elements, and the initial strength (e.g., weighting) of a linkage can be modified based on how confident / how close the outcome is relative to the intent. For example, it could be based on temporal proximity (e.g., all purchases in the past five minutes is given a score of 1, half an hour is given a score of 0.8, day is given a score of 0.5, and in the last week would be given a score of 0.2.
  • temporal proximity e.g., all purchases in the past five minutes is given a score of 1, half an hour is given a score of 0.8, day is given a score of 0.5, and in the last week would be given a score of 0.2.
  • all intent features and all outcome features being tracked have an initial score of 0.0, and are updated over time as outcomes are tracked.
  • the linkage model can then be utilized for offer / coupon generation, and in some embodiments, the system 104 is designed to maximize outcome scores when promoting new offers and coupons to the user (indicative of increased convenience or relevance to the user).
  • Outcomes can be tracked and associated with profile re-tuning machine learning rewards or penalties such that the outcomes can be used in a form of a reinforcement learning engine, where an agent is maintained based on world interactions (e.g., the user’s interactions with real-world websites), the machine learning model acting as an agent designed to optimize a particular outcome through determining which users should be eligible for a particular offer or coupon.
  • an agent is maintained based on world interactions (e.g., the user’s interactions with real-world websites), the machine learning model acting as an agent designed to optimize a particular outcome through determining which users should be eligible for a particular offer or coupon.
  • the relationships between particular offers and coupons with one another or with merchants can also be maintained and tracked over a period of time to computationally understand or represent which merchants or coupons are related to one another (e.g., coupon to coupon or merchant to merchant). Semantic search capabilities can then be used to expand the available set of training outcomes or offer / coupon options by computationally estimating relations between merchants and coupons, or between coupon and
  • the financial institution system 104 can interoperate with a token generator to create and manage tokens linking the transactions to specific account identifiers for one or more users. This provides a layer of security abstraction as it may be paramount to maintain the security and privacy of the account identifiers and the linkages thereof.
  • the account identifiers can be replaced for each user with a substitute token or user identifier that can be a token that is managed by the token generator (e.g., periodically refreshed or updated).
  • the information generated by financial institution system 104 can also be loaded into the trusted execution environment such that privacy levels and access levels can be controlled.
  • the financial institution system 104 can include an orchestration engine that is configured to retrieve the first data set and the second data set, or modified versions thereof if specific privacy settings are enabled.
  • the financial institution system 104 is configured to generate data linkages between the first data set and the second data set such that intent data and outcome data can be combined together to generate improved insights.
  • the orchestration engine uses the data linkages as a trained model for receiving and inferring output features such as a next best merchant, a next best price, among others, and interrelations between coupons and coupons, and between merchant and coupons.
  • the data linkages include whether a particular transaction was consummated after research, and in some embodiments, intent tracking or estimation engines are also utilized to generate computer estimated intentions from the first data set, both at a transaction level (e.g., John is trying to buy a computer fan able to power a 500W power supply) and at a thematic level (e.g., John is building a computer capable of playing the latest AAA video game), and these intents are matched against the purchase outcomes associated with the user.
  • a transaction level e.g., John is trying to buy a computer fan able to power a 500W power supply
  • a thematic level e.g., John is building a computer capable of playing the latest AAA video game
  • the orchestration engine is configured to transform, based on the one or more data linkages, a set of offer parameters or offer selections for a target user such that the offer parameters or offer selections can be tailored specifically for that user. For example, an estimation may indicate that the user is still looking to buy a power supply but the right price has not yet been achieved, and in an attempt to finalize the sale at an acceptable price, the offer may be transformed such that the price now fits within the range suitable for the user’s needs, albeit being a refurbished model or used model.
  • the orchestration engine controls the rendering, on a display of a computing device utilized by the target user in interacting with a web page of the one or more webpages, a visual display element representative of the transformed set of offer parameters or offer selections for the target user.
  • FIG. 3 is an example schematic of a data flow diagram 300 for the orchestration engine, according to some embodiments.
  • payment information can be obtained, for example, from a mobile wallet application, and intent information (e.g., search queries, internet browsing history), can be obtained from various external websites.
  • intent information e.g., search queries, internet browsing history
  • the data can be stored in a database data source.
  • FIG. 4 is an example schematic of a computing architecture 400 for the orchestration engine, according to some embodiments.
  • the first data set and the second data set may be stored in the data lake, which is a data warehouse adapted to expose certain data to the orchestrator engine.
  • FIG. 5 is an example rendering 500 of an improved display having a combination of a web shopping webview augmented with visual interface elements based on the data linkages.
  • the web search experience itself is augmented based on the data linkages, and in further embodiments, the contextual information added onto the interface (for example, as a widget bar) surface additional information elements, such as showing insights, personalized offers, among others.
  • the improved display can include one or more sliders or controls adapted to modify privacy settings, which, for example, can modify how information can be retrieved from a trusted execution environment.
  • the user’s mobile device may store one or more keys that can be provided to the trusted execution environment to modify the types and amount of data to be obtained from the trusted execution environment for use in establishing linkages between intents and outcome data representations.
  • FIG. 6 is an example schematic of a computing system 600 or device that can be utilized in implementing the data process linkage system, according to some embodiments.
  • Processor 602 can include computer microprocessors, field programmable gate arrays, or processor chips, and the system 600 can include a desktop computer or a computer server or computing appliance.
  • Memory 604 can include various types of read only memory, random access memory, among others, and the system 600 may be configured for receiving user inputs through input/output interface 606, communicating with other devices through a network interface 608 through the Internet, an intranet, or other types of local and wide area networks.
  • FIG. 7 is an example rendering of deals that may be presented on a user interface, according to some embodiments.
  • a user interface 700 is shown where there, for example, a number of different deals are presented in the form of interactive visual interface controls. These are presented as different options, for example for supporting a reinforcement learning approach based on a multi-armed bandit model, which in this case can be applied at an actual coupon level (or a merchant level).
  • Three example offers are shown as offers 702, 704, and 706.
  • the system is used to feed back information indicating which offer was selected and which were not for use in re-training the system or varying linkage connection weights, according to some embodiments.
  • the offers are not only tracked from an offer type perspective, but in some embodiments, additional features are tracked also in respect of the visual rendering of the offers themselves (color, size, among others).
  • the offer can thus be provided in an offer recommender engine that recommends coupons and other user behaviours that can be tracked in relation to an interaction include (number of transactions, clicks, recent searches, next best merchant), and coupon information (e.g., category, colours used in image, description text).
  • the offer recommender engine can be configured to provide the following input data set: [00115] Coupon data: the information about the coupon based on merchant and category or product level.
  • Contextual data Data contains user demographic/geographic data, purchase history, their spending on merchant or product category, frequency of a purchase per merchant/ per product category, day of the purchase, frequent buyer, revenue generator (75% percentile or above or some other condition)
  • Recommendation list coupons per merchant or coupons per product category, coupons per product
  • Reward list coupon values or some other values ( can be based on preference)
  • the offer recommender engine can output an offer recommendation, which can be provided, for example, in the form of a normalized or raw score that can be used to rank which offers would be shown for the multi-armed bandit (e.g., surface the top 3 offers). Accordingly, over time, as different offers are shown, the multi-armed bandit model can be used to tune the offers with an aim to optimize acceptance of a particular offer being shown.
  • an offer recommendation which can be provided, for example, in the form of a normalized or raw score that can be used to rank which offers would be shown for the multi-armed bandit (e.g., surface the top 3 offers). Accordingly, over time, as different offers are shown, the multi-armed bandit model can be used to tune the offers with an aim to optimize acceptance of a particular offer being shown.
  • the offer recommender engine is an improvement over traditional systems, as it can be configured to automatically handle a constantly changing nature of coupons, and vary for shopping choices that change over time for various reasons, such as seasons, time, changes in life situation, etc.
  • the approach can also be used to address cold start problems by generating recommendations for a user based on demographically available or similar users to establish recommendations for a new user when the system does not yet have sufficient in their user profile.
  • the improved offer recommender engine is also capable of implementing logic to influence the recommendations and to tailor recommendations to improve an outcome.
  • a system could be configured to dynamically alter a recommendation based on a provided range (e.g., the system may be provided discretion to provide the user between 5 to 15% discount, but instructed to remain close to 5% when possible). Based on the input features and linkages, the system may indicate that for a particularly price conscious purchaser, there is very low confidence in a purchase at 5%, but very high confidence in a purchase at 10% discount, and in this situation, the improved offer recommender engine can tune the offer to provide a 10% discount.
  • FIG. 8 is an example schematic of a reinforcement learning model, according to some embodiments.
  • FIG. 800 an example reinforcement learning model approach is shown, using a Multi Armed Bandit (MAB) approach based on actions and rewards.
  • MAB Multi Armed Bandit
  • Applicants have proposed a modified version of MAB to predict the merchant based on a stimulated contextual data using MABWISER, a python based library for MAB.
  • the system first includes instantiating a machine learning model data architecture adapted for reinforcement learning.
  • the approach includes obtaining observations (e.g., based on selecting of an offer among a plurality of offers, and an agent 804 (a mechanism that acts based on the machine learning model data architecture) is trained based on actions 806 taken by a user (e.g., selecting an offer, interacting with an offer, clicking on an offer), which are observed in the “world” / ecosystem at 808.
  • the selected offer is rewarded at 810 or conversely, the non-selected offers are penalized at 810, or both.
  • the machine learning model data architecture including one or more weighed interconnections between nodes representing the first data set, the second data set, and the set of offer parameters.
  • the nodes also include representations based on the tracked data linkages between the first data set and the second data set.
  • the machine learning model data architecture represents a latent space through the weighted interconnections, and can include a neural network. Over time, the machine learning model data architecture is trained based on user selections of offer parameters leading to positive out-come based interactions in the second data set representative of outcomes.
  • the approach is adapted for use with offer and coupon generation, where a model will be trained on user contexts, coupons, and rewards, coupons can be recommended, and based on a user's reaction to the recommendation (e.g. save, click), the model is assigned the rewards/penalty.
  • the agent 804 uses the machine learning model data architecture, identifies offers to be presented to the user, and in some embodiments, automatically selects and presents a plurality of offers to be used to obtain information through the user’s selections.
  • the transforming of the set of offer parameters or offer selections for the target user can include selecting one or more offers for the user based at least on an output value generated by the trained machine learning model data architecture, such that the machine learning model data architecture indicates what offers to show.
  • a plurality of offers are selected for the user to be rendered on the display of the computing device, and in a multi-armed bandit approach, the model obtains information by utilizing the set of offers as a set of multi-armed bandit training inputs for the machine learning model data architecture.
  • Each of the offers is distinguished from one another through their individual characteristics, and vary from one another, and these can be represented as individual features in the machine learning model data architecture. The closer the offers are to one another, the more information about preferences can be automatically gleaned.
  • the system will obtain more information about the specific preference of the user.
  • the user may be single and volume discounts may be of less importance, while free or expedited shipping may be of more importance.
  • the offers can be presented on a display of a computing device, for example, as side by side offers.
  • the offers can also have parameters that vary for the multi-armed bandit that are not directly relating to offer characteristics, but rather relate to how the offer is shown or rendered (color, size, animations, positioning) in the user interface.
  • other parameters can include swapping out the specific product for a competitor product to assess the user’s level of preference for store-brands as compared to name brands, etc., and a willingness for substitution.
  • the multi-armed bandit approach is not only a useful way to improve the relevance of offers, but in some embodiments, the selections from the multi-armed bandit approach form part of the second set of outcome information, and the corresponding data linkages between intent and outcomes can be further automatically updated to bias towards this interconnection (e.g., user searches shipping costs often, and outcomes are more positive when shipping is free, even for a economically equivalent discount, potentially due to psychological reasons).
  • the model is then updated using the new information about reaction to coupon their rewards, and based on new updated model, recommendations will be made.
  • Neighboring policy such as K-mean neighbour, mini-batch-K-means, Locality- sensitive Hashing nearest neighbor, and Radius helps model to cluster the data for better prediction.
  • the offer recommender can be built based on a contextual Multi-Armed Bandit approach, where apart from decision (arms) and rewards, the system takes contexts such as any information about user or product into account. [00135] There are three types of features that can be provided:
  • a base model for offer recommender can be created using coupon text embeddings and merchant's logo, embeddings which both have their use cases as described below.
  • FIG. 9 is an example rendering of clustered search results for a semantic search, according to some embodiments.
  • coupon text embeddings can be grouped together to provide clusters of similar items based on cosine similarity metric, or based on outputs from a machine learning model optimized for positive purchase outcomes, or a combination thereof (e.g., the model output could be used to weight the cosine similarity metric).
  • Semantic searches can be utilized to expand a set of results. For example, the system is tasked with finding a coupon for "Disney” then it will find the deals not only related to word Disney, but also deals associated with Orlando, Disney's products (toys, movies, etc.) with its cosine similarity score. Semantic enhancement approaches can be used to expand search queries in some embodiments, for example, by replacing search terms with semantic variants.
  • a number of coupons representing offers are shown (coupons 0-4), having specific textual descriptions and a distance.
  • the distance can be used to establish the specific semantic distance from a particular query or semantic variants by the user.
  • the first offer has a direct match
  • the second offer shown matches a semantic variant (Orlando vacation).
  • a number of returned results is changed on a slider, more distant results can be shown in the set of offers.
  • the offers can also be grouped together and interrelated using various types of graph data structures, which can be generated using network analysis.
  • the interconnections for the network analysis can be established using semantic analysis similar to the semantic search used to generate variants. For example, the interconnections could be established based on semantic distances from offer to offer, for example.
  • network analysis can be used for semantic search, by using semantic search to further extend to create a network of coupon-coupon, coupon-merchant, or both. These networks can be further used to build recommendation systems or community detection, or clustering as well.
  • the system uses the coupons as node and edges if they are semantically similar, the system generates a coupon-coupon network, as shown in an example 1000 in FIG. 10.
  • merchants can also be added as nodes, and edges between the merchant and the coupon can be established if the merchant offers that coupon. This example is shown in example 1100 in FIG. 11.
  • the graph networks can be used to modify the MAB selections, in some embodiments.
  • the MAB selections can be based on a simple ranking of relevancy scores relative to the user’s query (imputed or explicit)
  • the graph networks are utilized together with the relevancy scores relative to the user’s query.
  • a most relevant offer is first selected based on the semantic distance (e.g., the offer having the highest semantic distance score).
  • the semantic distance scores are modified or determined further based on a machine learning model tracked representations of the user through the intent data sets, the outcome data sets, and/or prior offer selections.
  • the additional offers for the MAB are selected using the graph network instead in this variant.
  • the graph network is interrogated for closest neighbors. For example a particular offer is selected in FIG. 10.
  • the corresponding node is identified, in this example, the node 1002, and node 1002 would be the first offer.
  • the graph network is then interrogated to identify nodes 1004 and 1006, the two neighbor nodes that have the highest semantic similarity score to node 1002.
  • the offers of nodes 1002, 1004, and 1006 are presented. This approach is useful because it picks nodes with minor differences such that these differences can then be used for obtaining very specific information through the MAB reinforcement learning process, improving the representation of the user.
  • FIG. 12 is an example rendering of a next merchant display rendering, according to some embodiments. In this example 1200, four offers are shown that have been selected for the user based on the user’s search history.
  • the system can be utilized to run the semantic search API for relevant offers, and the search could be a real time match based on relevancy and/or a multi-armed bandit selection.
  • Search history retention policies can be established based on a minimum number of searches and time elapsed sine the search.
  • FIG. 13 is an example rendering of a search bar, according to some embodiments.
  • Search bar 1300 may be utilized to enter a specific query, for example, querying available offers or generating a search query as part of a web search.
  • the search query could be tokenized and broken into word tokens for analysis.
  • FIG. 14 is an example flow diagram of a relevancy enhancement approach, according to some embodiments.
  • the flow diagram 1400 is shown in example and the input string can be augmented based on additional information, such as semantically similar variant words obtained from search services, merchants and addresses, prior search history 1402 of the user or other users, and the specific variants and words being used can also be biased towards specific words found in offers such that relevancy of offers is enhanced.
  • NLP classification if only on text can be introduced.
  • An example search query for example, would be a search for 'px7' which is a headphones model).
  • the search results can include ranked merchant and non merchant websites. Additional information can be found on the product or merchant place type as an example. Any information on product, merchant, or site descriptions should be returned for additional processing. Merchant domains and subdomain information can be extracted from the web addresses returned and from offer merchant databases.
  • Custom NERs Named Entity Recognition
  • NERs Named Entity Recognition
  • Some merchants might not have their own domains but rather websites under social media platforms. There may also be some merchants that have one domain serving multiple.
  • a semantic understanding of returned searches can be implemented, for example, by processing returned results including descriptions of products, to help improve on relevancy. Entity recognition and semantic embeddings alongside other NLP capabilities can used to help for a better understanding of intents. Search history processed results may also help with relevancy, as the user might be looking for book jackets in previous searches, and thus the system, in that context, should not show offers or rather rank first offers on clothing. Additional inputs from other predictive services, descriptive information (trending, popular) may also be aggregated as needed and used as additional weighted inputs to help for better offer rankings.
  • FIG. 15A, FIG. 15B, and FIG. 15C are screenshots shown in 1500 that illustrate an example coupon or offer loading process flow whereby an offer or coupon may be loaded onto a wallet application and associated with the user, according to some embodiments.
  • an offer or coupon is shown through an interactive interface element, which when interacted with, leads to the wallet 1502 of FIG. 15B, which shows the offer loaded on as an interactive element 1504 in the wallet.
  • the offers or coupons are stored in a central data object which when interacted with, can provide an expanded graphical user interface screen shown on FIG. 15C listing out numerous offers and coupons, along with use characteristics (e.g., bar codes for scanning for use in physical stores), expiry dates, among others.
  • a feedback signal can be returned indicating that the coupon or offer has been interacted with to the backend system.
  • recordal of the offer or coupon can be tracked for feedback purposes, for example, updating a user data table to indicate that the user has accepted an offer or coupon.
  • the system can be used for processing of the offer and coupons based on the tracked feedback.
  • an injection mechanism can be used to insert coupon codes, promotional codes, etc. directly into the purchase transaction.
  • the coupon or offer can be applied during the transaction message between the financial institution / issuer / payment processing entity.
  • a benefit is that the reimbursement process can be simplified as there is no need to have a data process retroactively trawl through transactions in the future to assess reimbursements and eligibility based on processed transactions. Instead, reimbursement can occur directly in the initial transaction itself, as the user could have already been pre-validated and pre-cleared in the audience list.
  • FIG. 16A, FIG. 16B, FIG. 16C, and FIG. 16D are a set of screenshots 1600 showing an example coupon or offer redemption process flow where an offer for an example heirloom salad kit is being applied and ultimately redeemed.
  • the user finishes a browsing session whereby the user is able to trigger a checkout sequence.
  • the checkout sequence is indicated, for example, through the merchant flagging a page as a checkout sequence, parsing the URL or the URL HTTP variables being communicated, parsing the returned HTML of the webpage being rendered (e.g., identifying keywords such as payment, checkout), among others.
  • the customer journey is maintained through a stateful variable and triggers occur when a transition in states is tracked.
  • the user initiates a call of the mobile wallet, and the user’s credit card information appears.
  • the call of the mobile wallet on the checkout page is a combined trigger for an offer or coupon to be surfaced.
  • the identification of the offer or coupon can be conducted through a traversal or reference look up of the audience list data structure.
  • the offer or coupon can be surfaced through a rendering of a visual control element showing the discount that may be applied, and in FIG. 16C, the screenshot shows a coupon or offer after it has been interacted with by the user to initiate an application of the offer or coupon. The offer or coupon is then applied, and the savings amount can be updated on the graphical user interface.
  • a user may also interact with the graphical user interface and identify what other offers or coupons remain, and potentially select another offer or coupon for application (e.g., where there may be multiple offers or coupons available).
  • the offer shown in this example is a coupon to save $30 on garden products, and the user may select, through a visual interface element, to apply the offer. As shown in FIG. 16B, the savings of $30 is applied and the total amount payable is $124. Other variations are possible, and other offers are possible, such as free shipping, buy one get one free, etc.
  • a SKU number of the product is also utilized as part of the trigger.
  • the item has a SKU of 6427709.
  • the audience list may be coupled to particular SKU items such that the coupon or offer is automatically launched only when a matching SKU or SKU range is identified in the shopping cart or a browsing session.
  • the coupons and/or offers are pre-populated into the user’s wallet, for example in a myOffers data structure. This can occur, for example, through the audience list being utilized to batch push offers and coupons directly into consenting users’ wallets to be pre-loaded.
  • the offers or coupons 1606, 1608, can be surfaced to indicate their availability for future purchases.
  • a benefit of the approach shown in FIGS. 15A, 15B, 15C and FIGS. 16A, 16B, 16C, and 16D is that the coupons and offer provisioning can be separate temporally such that a coupon or offer is saved in a digital wallet for later usage. Accordingly, the coupon or offer provides another avenue for retainers or merchants generate audiences to see their products, and to aid in reducing digital shopping cart abandonment as products are being researched.
  • the offers and coupons persist as data objects stored thereon the digital wallet, a user does not have to remember which offers or coupons were clipped before, and in the embodiments where the offers or coupons are automatically applied through an interjected checkout process through messaging with the issuer to accommodate the payment, the offer or coupon can be applied automatically without computationally expensive batch post-processing (e.g., as required for statement credits).
  • Another benefit of this approach is that there can be coordination without cooperation by merchants and retailers such that overlapping promotions are not permissible.
  • a user may be incentivized by more than one marketing campaign, and the user may otherwise be able to combine or “stack” a number of offers or coupons together.
  • additional business logic may be implemented in the form of rules that limit these capabilities as they can also be processed together when the issuer updates the payment. For example, a user currently may attempt to stack an affiliate marketing link discount (e.g., using a tracked shopping cart registered to a link), combine that with a promotional code entered at checkout, and further combine the checkout with incentive programs (e.g., statement credits) from the issuer / financial institutions. As a result of the lack of coordination between the incentivizing organizations, the user may be able to obtain a product at a cost lower than the actual cost by the retailer to deliver the product.
  • an affiliate marketing link discount e.g., using a tracked shopping cart registered to a link
  • incentive programs e.g., statement credits
  • example systems 1700 and 1800 are shown as example systems architectures, according to some embodiments.
  • Each of the blocks shown are computing systems associated with corresponding parties, such as computer servers, distributed resources computing implementations, among others.
  • FIG. 17 is a more complex implementation where there are potentially multiple financial institutions acting as issuers that each have their own trusted execution environment instances that interoperate with one another to provide a consolidated data storage for aggregated data queries.
  • Merchant systems 1702, 1802 are configured to provide catalogues each having data objects corresponding to products or services available, which can be identified, for example, through merchant specific or global stock keeping unit (SKU) identifiers.
  • SKU stock keeping unit
  • One or more marketing campaigns may be instantiated through an offer or coupon engine 1704, 1804, which can be configured to automatically operate one or more marketing campaigns through implementing logical rules corresponding to eligibility criteria associated with the one or more marketing campaigns.
  • Logical rules can include, for example, requires registration, be automatically or passively pushed, identification of specific demographics (e.g., student discounts) or loyalty program attributes, durations of time in which an offer or coupon is valid.
  • eligibility can be determined through more granular analyses, such as a machine learning engine adapted to conduct queries and trained with outcome information to predict which users are likely to flip to purchasing an object instead of abandoning a shopping cart after an incentive is provisioned.
  • the machine learning engine can also be adapted to dynamically determine the size or quantity of a promotion, offer, or coupon (e.g., 20% for users in Group A, and 25% for users in Group B).
  • the offer or coupon engine 1704, 1804 in some embodiments is configured for interoperation with mobile devices 1706, 1806 such that the offers or coupons can be digitally stored thereon in a digital wallet associated with the user.
  • the digital wallet is maintained on encrypted local storage on the mobile device 1706, 1806, for example, on a secure element, secure processor, or secure memory region on the mobile device 1706, 1806.
  • a trusted execution environment 1708 or 1808 is provided that is a “virtual clean room” (VCR) adapted for secure data processing and queries to enhance privacy and security for the one or more users, or with data from one or more retailers or financial institutions, using an always protected database.
  • VCR virtual clean room
  • the offer or coupon engine 1704, 1804 can be configured to interoperate with the trusted execution environment 1708 or 1808 through the sending of data query messages or request messages thereof that can be utilized for the identification of demographics for provisioning of the coupons or offers.
  • the trusted execution environment 1708 or 1808 holds sensitive data loaded thereon by a plurality of different entities, and the trusted execution environment 1708 or 1808 is conducted to conduct secure queries of the data stored thereon, either in response to specific queries sent by external computing devices or for training machine learning models that can be stored thereon.
  • the trusted execution environment 1708 or 1808 securely retains data (e.g., in accordance with a data custodian data process) in an always protected database that utilizes encryption approaches to ensure that data access is closely limited and monitored, such that the trusted execution environment 1708 or 1808 is an isolated computational data processing system whose data cannot be directly accessed by external computational systems unless logical rules enforced by the data custodian data process are adhered to (e.g., user full names and precise locations cannot be directly returned in a query).
  • users or entities may establish data access permission, and the permissions may be implemented through one or more encryption keys that are maintained by these parties and provided if enhanced access is to be provided, for example. Differing layers of encryption may be established through the use of cascaded encryption, and users or other data sources may also provide access at different levels through the provisioning of a corresponding encryption key.
  • the trusted execution environment 1708, 1808 may be configured to fetch merchant SKU information from merchant computing systems 1702, 1802, and audience list characteristics from coupon and offer engine 1704, 1804, such that audience characteristics and eligibility queries can be conducted within the trusted execution environment 1708. 1808, for example, tracking the loading and registration of offers and coupons, among others.
  • the transaction may be transmitted to issuer computing systems 1712, 1812, which then may send transaction characteristics to be loaded on and/or validated against the records stored thereon in trusted execution environment 1708, 1808.
  • the trusted execution environment 1708, 1808 can be queried, for example, utilizing an encryption key stored thereon on the mobile device 1706, 1806 in conjunction with an encryption key stored on a merchant device or issuer devices to determine whether the offer or coupon can be applied, and upon successful validation, the offer or coupon can be applied, for example, through modifying a price associated with a transaction.
  • the offer or coupon can be applied without leakage of customer information that occurs in alternate approaches, such as shopping cart / affiliate tracking, among others.
  • parties that do not trust the data security of another can also collaborate in conducting targeted marketing campaigns and overlap between campaigns can be resolved and/or mitigated.
  • the approach herein can be adapted to protect privacy and confidentiality, while providing capabilities for hyper personalization and dynamic provisioning.
  • the transactional flows can be adapted for contextual awareness in applicability of offers and coupons, and rules may be implemented to conduct offers and coupons across merchants, for example, and the offers and coupons may automatically trigger without the user selecting it or automatically bringing it up for a real-time redemption.
  • the use of the trusted execution environment 1708, 1808 enables enhanced privacy through providing an interface (e.g., coupled to a software development kit) where the merchants are unable to access identifying information of the users having information maintained in the trusted execution environment 1708, 1808.
  • an interface e.g., coupled to a software development kit
  • a computer system is provided that is adapted for controlling a user interface for rendering of interactive graphical control elements representing offers or coupons.
  • the system injects or inserts these offers or coupons into a computational payment process, which can include a checkout transaction, a digital wallet, among others.
  • a company seeks to initiate a new marketing campaign.
  • the company s advertising specialist launches a campaign management application, which is coupled to the computer system through an API or a graphical user interface.
  • the advertising specialist crafts a campaign, and identifiers a set of logical conditions for including a subset of all users as members of a target audience list.
  • other types of campaigns are possible, such as research campaigns, information awareness campaigns, voting campaigns (e.g., “get out the vote”), etc.
  • the system can be utilized to generate an awareness campaign for a certain type of disease, to identify individuals potentially impacted by routine vehicle recalls, among others.
  • the set of logical conditions depend from campaign to campaign, and in some cases, multiple sets of logical conditions are provided to the system for processing, as some of the sets of logical conditions represent different variations on offers and coupons being provided, or test queries used to determine parameters for the campaign itself.
  • These logical conditions require analysis across a set of data sets and data tables that are associated with different entities, each having different underlying privacy requirements.
  • a benefit of the system as described in various embodiments herein is that the system is adapted for an open data sharing approach where parties that do not necessarily trust each other or the security and privacy policies of one another, but share a trust in the always protected system are able to collaborate together. While on one hand, the system can be adapted for an openness of use, on the other hand, the system is designed to be closed from a processing perspective such that privacy and other security features can be automatically enforced by the always protected database.
  • a payment / digital wallet company providing, for example, for each user, a digital Wallet ID, a list of payment cards available on the digital wallet, an account identifier, a payment card product name, payment specific information such as masked funding primary account number (FPAN) and device primary account number (DPAN), usage history: tap/in- app; amount; timestamp; merchant info, among others.
  • FPAN masked funding primary account number
  • DPAN device primary account number
  • Merchant data sets can include merchant loyalty program information, merchant SKU products and classifications, product types, among others.
  • Financial institutions may also contribute or make available data sets associated with the user’s accounts with the financial institutions, and in some embodiments, the financial institutions may take extra security precautions to flag sensitive data and further restrict direct access without consent.
  • the information in these data sets can further include whether the user is signed up for various financial institution products, such as mobile applications, mobile banking, rewards, among others, and these may be identified, for example, using unique identifiers for various mobile applications, etc.
  • the financial institution may also provide information associated with the user, such as the FPAN of payment cards if available, DPAN and Wallet IDs, card usage details, and, in some embodiments, a clientSurrogatelD.
  • a DPAN can be a digital network token that is generated by a payment network and may be a tokenized version of a substitute of a card that may only be validly used in certain circumstances (e.g., from the particular device it is bound to, for example, using a cryptogram).
  • Another example data source could include schools providing enrollment information data tables, grade scores, participation in extra curricular activities.
  • Other example data sources include insurance company data (e.g., claims history, accident history), government data, tax data, web browser / search firm data, among others.
  • the always protected database system initiates a data load of the corresponding data.
  • the campaign is for sending out offers and coupons to individuals who are interested in buying headphones and will potentially become long term buys of a particular brand’s audiophile headphones.
  • the headphone company only has a limited number of coupons and offers available (e.g., 1000), and uses the system to submit a request to aid in their targeting of the coupons and offers.
  • the query request message in this example is adapted for indicating the characteristics of types of customers of interest (e.g., University students in a STEM program, profile indicating interest in audio devices, having an age of 18-24, having abandoned shopping carts in the past with audio devices in them, living in a post code).
  • the always protected database system receives campaign request message and optionally first ensures that it adheres to various privacy-enhancing query restrictions.
  • the query is a pre-approved template query and thus a validation is not necessary.
  • the always protected database system then identifies and loads the relevant database tables and conducts a query across multiple database tables - e.g., University, search engine, online shopping cart program, insurance, merchant. Two or more data tables can be loaded. For example, twelve insurance companies may use the always protected database to combine their data sets to aid a university researcher in assessing long-term flood risks in a flood prone region.
  • the campaign manager may first run a query to identify how many users would fall into the conditions, identifying the size of a potential audience. Multiple queries may be run to obtain various results.
  • the campaign manager can send in a query request configured to generate the audience list, a data structure listing out the particular records to be flagged.
  • the audience list lists out users meeting the criteria, and in some embodiments, if there are more users than available customers or offers.
  • the audience list can also include SKUs of interest, or merchants of interest that can be incorporated into selecting which offers or coupons are provided to the user.
  • an offer or coupon can be digitally provisioned by either sending to the targeted user for later usage (e.g., when the target user looks at the wallet and sees $50 off PX7 headphones), or (2) surfaced to the target user when the user is buying products on at Merchant 1 ($50 off PX7 headphones). If the user’s purchase includes the SKU of interest, the coupon / offer is applied, and whether the target users takes up / does not take up the offer can be tracked so that the campaign manager can observe offer / coupon fulfillment rates.
  • these approaches can include processing the query message at time of campaign instantiation - e.g., when starting campaign, the campaign manager knows that the manager is sending out 10,000 offers because there are 10,000 eligible people.
  • the query message can be conducted based on triggers (e.g., time of offer surfacing) - this is a more flexible approach - e.g., when the campaign manager starts campaign, a query is established but processed only periodically on a triggering event, such as when the target user searches multiple times and ultimately abandons carts in the past, but now has a cart with the item in it.
  • the campaign goal is to improve a usage of a particular payment card that is a new offering, so that users can become more familiar with the benefits of the payment card.
  • a campaign is launched, and a campaign data process is initiated.
  • the motivation of the campaign may be to encourage more usage of the card or a switching of the card.
  • the financial institution may be the party seeking to encourage more usage of the card or a switching of the card, and in this example, the financial institution initiates a new campaign utilizing the system to conduct various processing across both data tables to improve or append new additional information to the data table of the financial institution.
  • a unique identifier for the installation is generated.
  • the mobile payment and digital wallet service may also have access to this unique identifier for the installation where the mobile payment and digital wallet service is also coupled to an application store, and use this information as a primary key for identifying a particular user.
  • Other primary keys can be used across the various data tables, such as a wallet identifier, a client number (or a surrogate thereof) a phone number, an email, etc.
  • the financial institution’s data table may include, in a simplified example:
  • the mobile payment and digital wallet service could have data associated with the various mobile application numbers or Wallet IDs, such as payment data, tracked usage data of near-field data communications payments, application installation unique identifiers, among others, along with digital wallet information.
  • the WalletID matches, and can be used as a primary key to identifying Arnold for analysis.
  • Arnold may have both financial institution and other payment cards, and an automated analysis (e.g., using count comparisons) of the mobile payment and digital wallet service data table indicates that the count of transactions on the non-financial institution payment card is greater than those on the financial institution payment card.
  • the set of logical conditions can include providing an offer sign-up bonus of $25-$100 (depending on usage/profile) for upgrading the payment card type to a more premium payment card type.
  • a second set of query messages can be used to identify clients such as Steve which have the mobile application on their device but not the financial institution payment card, and are using a non-financial institution payment card. Because Steve does not use a digital wallet, there may be no walletID to match and the primary key may need to use a secondary primary key, such as the IdentifierforVendor. Steve may also not have a financial institution payment card provisioned, and may be using an alternate card. For Steve, the system instead adds Steve to an audience list data structure for an offering of a pre approved credit card, as this offer may be better tuned for Steve.
  • a third set of query messages can be used in respect of the example for Ravi.
  • the query message can identify users across the two data tables such as Ravi who have the financial institution payment card but uses an alternate payment card on the digital wallet, and uses the financial institution payment card only for purchases at a petrol station.
  • the system may be configured to add Ravi to an audience list for generating offers for variable sign-up bonuses.
  • a fourth set of query messages can be used in respect of the example for John.
  • John has a financial institution payment card but is not an active digital wallet user.
  • John is a user who uses tap transactions.
  • a query message can be designed around a set of logical conditions, and John can be added to an audience list by the mobile payment and digital wallet service as a user who could benefit from being incentivized by an offer to use a digital wallet service as the high usage of tap transactions indicates a familiarity with technology.
  • the response from the system could include audience lists for various offers, or control messages to control messaging using the audience lists (e.g., in the embodiment where the audience lists are not provided to the merchants or the parties directly but only maintained on the always protected database).
  • the primary key used to associate the records on the data tables may not always be the same and can vary depending on the information available, as records may be sparse or inconsistent.
  • an approach can instead be used for best efforts matching instead of exact matches to establish a primary key if none is available. This is useful where a high level of accuracy is not required.
  • the system can be useful both ways for the financial institution and the mobile payment and digital wallet service, as they are both able to benefit from the analysis on the combined data tables but do not need to yield any customer privacy or security concerns as data is not being directly provided to the counterparty.
  • the usage of particular data tables is tracked and associated with a compensation mechanism where usage imbalances are tracked and differentials can be associated with a payment.
  • a compensation mechanism where usage imbalances are tracked and differentials can be associated with a payment.
  • every time a data table is requested from Merchant for analysis funds can be provided by other parties, and Merchant could distribute the funds among the users whose data is in the data table of Merchant
  • the response to the query message can include updates to a data table for a particular party.
  • queries can be run across the combined data table to update a net worth status for each of the users based upon, but without exposing any underlying transaction data captured in the mobile payment and digital wallet service data table.
  • a simplified example could be based on average monthly spend, and each of the users can be classified as a high, medium, or low monthly spend customer, which could be useful information for the financial institution for further analysis.
  • an additional field may include a most popular category or type of transaction as obtained from the mobile payment and digital wallet service data table, and offers in the campaign can further be configured to be automatically selected to match the category.
  • an offer may be associated with movie tickets for a user who frequents cinemas, among others.
  • additional data tables may be loaded to allow for dynamically selected offers based on existing inventory levels, etc. For example, for a merchant check-out offer, instead of a cashback offer, the offer may be substituted for products indicated by a merchant as over-stock, clearance, among others (instead of $5 off, the user is offered a free cordless drill instead).
  • connection may include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements).
  • indirect coupling in which at least one additional element is located between the two elements.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Bioethics (AREA)
  • Artificial Intelligence (AREA)
  • Technology Law (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • Computational Linguistics (AREA)
  • Molecular Biology (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • User Interface Of Digital Computer (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Communication Control (AREA)

Abstract

Une approche informatique est proposée pour commander une interface utilisateur destinée au rendu d'éléments de commande graphiques interactifs représentant des offres et des coupons qui sont insérés dans un processus de paiement informatique. En particulier, les offres et coupons peuvent interagir avec des informations de paiement stockées résidant (ou leurs jetons) sur une structure de données de portefeuille numérique. L'approche peut être mise en œuvre en tant que système informatique, un procédé informatique pouvant fonctionner sur un système informatique, ou un produit-programme informatique fixé sous la forme d'un support non transitoire lisible par ordinateur stockant des instructions interprétables par une machine.
EP22803502.8A 2021-05-17 2022-05-17 Système et procédé de chargement de données sécurisées dans un environnement informatique sécurisé multipartite Pending EP4352681A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163189611P 2021-05-17 2021-05-17
US17/701,612 US20220301013A1 (en) 2021-03-22 2022-03-22 Systems and methods for establishing data linkages
PCT/CA2022/050430 WO2022198317A1 (fr) 2021-03-22 2022-03-22 Systèmes et procédés pour établir des liaisons de données
PCT/CA2022/050779 WO2022241551A1 (fr) 2021-05-17 2022-05-17 Système et procédé de chargement de données sécurisées dans un environnement informatique sécurisé multipartite

Publications (1)

Publication Number Publication Date
EP4352681A1 true EP4352681A1 (fr) 2024-04-17

Family

ID=84140277

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22803502.8A Pending EP4352681A1 (fr) 2021-05-17 2022-05-17 Système et procédé de chargement de données sécurisées dans un environnement informatique sécurisé multipartite

Country Status (4)

Country Link
EP (1) EP4352681A1 (fr)
AU (1) AU2022275586A1 (fr)
CA (1) CA3220291A1 (fr)
WO (1) WO2022241551A1 (fr)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002035314A2 (fr) * 2000-10-24 2002-05-02 Doubleclick, Inc. Procede et systeme pour partager des renseignements d'utilisateur anonymises
US20120166268A1 (en) * 2010-12-23 2012-06-28 Exclusive Concepts Time to buy
US20130117126A1 (en) * 2011-11-07 2013-05-09 Apriva, Llc System and method for secure management of customer data in a loyalty program
US11277412B2 (en) * 2018-05-28 2022-03-15 Royal Bank Of Canada System and method for storing and distributing consumer information
CN112567366B (zh) * 2018-05-28 2024-10-11 加拿大皇家银行 用于确保电子交易平台安全的系统和方法

Also Published As

Publication number Publication date
CA3220291A1 (fr) 2022-11-24
WO2022241551A1 (fr) 2022-11-24
AU2022275586A1 (en) 2023-12-14

Similar Documents

Publication Publication Date Title
US11392993B2 (en) System and method providing personalized recommendations
Ghosh et al. Digital deceit: the technologies behind precision propaganda on the internet
US20160012512A1 (en) Lifestyle recommendation system
US20090132395A1 (en) User profiling in a transaction and advertising electronic commerce platform
US10565607B2 (en) Browser based advertising platform and rewards system
US20030144907A1 (en) System and method for administering incentive offers
US20120290399A1 (en) Web Optimization and Campaign Management in a Syndicated Commerce Environment
US20240177187A1 (en) System and method for loading secure data in multiparty secure computing environment
US20180089676A1 (en) Dynamic Multi-Website Data Collection and Data Sharing
US20230116407A1 (en) Systems and Methods for Predicting Consumer Spending and for Recommending Financial Products
US20160063546A1 (en) Method and system for making timely and targeted offers
US20220301013A1 (en) Systems and methods for establishing data linkages
US20230186376A1 (en) Systems and methods for user interface orchestration and presentation
Chung et al. Adaptive personalization of mobile information services
AU2022275586A1 (en) System and method for loading secure data in multiparty secure computing environment
Vajjhala et al. Impact of psycho-demographic factors on smartphone purchase decisions
EP4315223A1 (fr) Systèmes et procédés pour établir des liaisons de données
US12073439B2 (en) Smart contract system and method for managing digital user engagement
Theodorakopoulos et al. Leveraging Big Data Analytics for Understanding Consumer Behavior in Digital Marketing: A Systematic Review
Pillay CONSUMER ONLINE BUYING PATTERNS œ A SOUTH AFRICAN PERSPECTIVE
Zhao et al. In quest of perceived transaction cost’s impact on fintech users’ intention: the moderating role of situational factors
Lilliecrona et al. Factors to consider when adapting to M-commerce: From a design perspective
CA3221730A1 (fr) Systeme de contrat intelligent et procede de gestion de l'implication d'un utilisateur numerique
Pesaran Behbahani et al. A business intelligence framework to provide performance management through a holistic data mining view
Moakler Methods for Causal Inference Using Large-scale Digital Data

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)