WO2020070721A1 - Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles - Google Patents

Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles

Info

Publication number
WO2020070721A1
WO2020070721A1 PCT/IB2019/058495 IB2019058495W WO2020070721A1 WO 2020070721 A1 WO2020070721 A1 WO 2020070721A1 IB 2019058495 W IB2019058495 W IB 2019058495W WO 2020070721 A1 WO2020070721 A1 WO 2020070721A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
server
data
social network
transaction
Prior art date
Application number
PCT/IB2019/058495
Other languages
English (en)
French (fr)
Inventor
Camila Andrea Diazgranados Bolívar
Rafael Esteban Espinel Pinzón
José Israel Espinosa Alarcón
Diana Maritza Galvis Gutíerrez
David Guillermo Guerrero Calderón
Juan Pablo Alfonso Mosquera Fernandez de Castro
Yesika Padilla Yañez
Rafael Sánchez Cuadros
Original Assignee
Banco Davivienda S.A.
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
Application filed by Banco Davivienda S.A. filed Critical Banco Davivienda S.A.
Publication of WO2020070721A1 publication Critical patent/WO2020070721A1/es

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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • 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/04—Payment circuits
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present disclosure relates to systems and methods of authorizing transactions between a receiving user and a sending user that include verification of the identity of the sending user. Furthermore, this disclosure is within the technological field of computer-implemented inventions aimed at authenticating the identity of a user through computing devices.
  • Document US 2010/0306099 discloses a system and method for authenticating and processing requests received through social networking websites, wherein the defined system includes a data storage means for storing the data associated with a first telephone number. of a user with user identifications on a social network website; and an exchange coupled with the data storage medium, wherein said exchange includes a common format processor and a plurality of converters for interacting with a plurality of mobile communication controllers.
  • the disclosed method comprises the steps of receiving on a server a request from a user authenticated by a social network website; identify a user's first phone number; communicate by the server with a mobile phone on the first phone number to confirm the request; and in response to the request that is confirmed by the mobile phone on the first phone number, process the request using the funds associated with the mobile phone on the first phone number.
  • a disadvantage which is that it requires the communication of the server with the mobile phone and the authentication is done by means of a number only, which does not guarantee that communication is secure and the protocols of a bank or financial institution are not established to carry out the requested transactions.
  • document US 2013/0054458 discloses systems and methods that use a social network platform to provide authentication information to carry out a money transfer transaction, where the method can include, obtain and use the data information.
  • the online social network profile of the sender, receiver or both in order to facilitate a convenient and safe transaction.
  • this disclosure includes an online social network profile database configured to store and correlate profile information for multiple users and a money transfer transaction processing device in communication with the database to authenticate a transaction. money transfer, where all these modalities are implemented on the internet, with dedicated applications for a computer and / or a mobile device.
  • US document 9,218,594 discloses a method and a system for making assisted electronic payments on social networks, where the method includes the steps to determine one or more members of a social network that seeks a payment towards a financial contribution of a real-time transaction between the user and a merchant; querying said one or more members in a descending probability based financial contribution order until sufficient funds have been received for payment of the transaction; and process a money transfer from the user and / or each of the members to the merchant to complete the transaction in real time.
  • document US 2018/0183737 discloses systems, methods and devices to process payment transactions between a user and a merchant using a messaging environment
  • a commerce system allows the user to initiate a communication session with a messaging environment associated with commerce using natural language.
  • the messages sent are analyzed to identify a product and a purchase request for the identified product.
  • a payment transaction is initiated on behalf of the user based on a natural language conversation and without redirecting the user away from the communication session.
  • a payment initiation message can be provided from the messaging environment to the user indicating that the payment transaction has been initiated.
  • Document CO 11-82169 discloses a method for securely processing a transaction, wherein the method includes storing a plurality of encrypted financial transaction instrument identifiers in memory where there is no decryption key for these stored in memory and furthermore, where the financial transaction instrument identifiers are each associated with a mobile communication device. The method also includes receiving from a server a request to process a transaction, removing from memory the financial transaction instrument identifier associated with the mobile communication device, transmitting the removed financial transaction instrument identifier to the mobile communication device, receiving in the mobile communications device the transaction data, and using the received transaction data to carry out a financial transaction.
  • the present disclosure describes a method and a system to authorize through computer devices a transaction between a sending user and a receiving user who are previously registered in a social network.
  • the method disclosed herein comprises a step of storing registration data for each user in a first database located on a first server that is configured to manage a transactional application.
  • the sending user enters their registration data through a first computing device configured to run the transactional application
  • the receiving user enters their registration data through a second computing device configured to run the transactional application, where the devices Computational computers are connected through a communications network with the first server.
  • the method includes a step of generating a sender profile and a receiver profile for the transactional application through the first server, where the profiling step includes associating the issuing user registration data of the storage stage with some Profile data of the issuing user's social network.
  • this profiling step includes associating the registration data of the recipient user of the storage step with profile data from the social network of the recipient user; and creating from the registration data and profile data of the issuing user's social network a sender profile, and from the registration data and profile data of the receiving user's social network a recipient profile.
  • the sender and receiver profiles are stored in the first database.
  • the first server requests the profile data from the social network to a second server that is configured to manage the social network.
  • the method has a step of detecting through the second server a label entered by the sending user in a publication made by the receiving user within the social network.
  • the detection of the label generates that the second server communicates with the first server so that said first server runs the transactional application on the issuing user's computing device.
  • the method includes a step of validating through the first server whether the users have sender and receiver profiles stored in the first database; and a step of generating first authorization data to authorize the transaction between the sending user and the receiving user.
  • the generation of the first authorization data comprises executing through the first server the transactional application on the issuing user's computing device, requesting the issuing user to enter a pattern on the computing device; and comparing the pattern on a third server with a base pattern that is stored in a second database of a third server and comparing the time in which the sending user enters the pattern against a reference time stored in the second database .
  • the third server generates the first authorization data and sends it to a fourth server when the patterns match and the time in which the issuing user enters the pattern matches the reference time stored in the second database.
  • the method has a step of authorizing through the fourth server the transaction between the sending user and the receiving user, where the fourth server notifies the first server that the transaction is authorized.
  • One of the objectives of the method disclosed here is to authorize transactions between a sending user and a receiving user in social networks through computing devices.
  • the method disclosed here can authorize a transaction, such as a purchase or transfer of goods, between users who are registered in a transactional application, where a sending user enters a label in a publication made by the receiving user in the social network.
  • a transaction such as a purchase or transfer of goods
  • the issuing user can participate in the transaction without leaving the social network, and interact with the transactional application from their computing device at the moment of entering a pattern at a certain time.
  • Another objective of the method disclosed here is to reduce the time that a sender user spends on a transaction, from the time they state their intention to make the transaction until it is authorized.
  • the method disclosed here is aimed at reducing the number of interactions that the user makes, for example, in the case that you must fill out forms, use payment gateways, be redirected to other web portals or applications.
  • the issuing user enters a label in the social network in a publication made by the receiving user, which causes the transactional application to run on the issuing user's computer device, requesting that the pattern be entered in a given time, which is then compared with a base standard and with a reference time stored in the third server.
  • the pattern and times coincide, the transaction is authorized.
  • the user perceives that the time he invests in the transaction is much less than what he would use if he had to interact with payment gateways, web pages, forms, authorization calls, entry of keys sent by notifications, SMS, or e-mail, and other methods of authentication and authorization disclosed in the state of the art.
  • the third server runs a risk engine configured to measure and compare the time in which the issuing user enters the pattern against a reference time stored in the second database, and where the Risk generates the first authorization data when the pattern coincides with the base pattern and is entered at the reference time.
  • the transactional application the receiving user has, in addition to his receiving profile, an issuing profile saved in the first database.
  • This allows having a single transactional application for sending and receiving users, instead of having variations of the transactional application for each profile.
  • this allows the receiving user to also initiate the authorization method by entering the tag into a post of another receiving user, without the need to create a new sender profile.
  • the step of storing the registration data of each user in the first located database can also include a sub-stage of opening a financial product related to the issuing user through the transactional application, where the transactional application communicates through the first server with a fourth server configured to grant said financial product.
  • the fourth server can verify that the financial product complies with acceptance requirements, where in the verification of the financial product, the third server communicates with the fourth server and requests financial data. They are subsequently analyzed through the risk engine to determine if the financial product meets the acceptance requirements.
  • the registration data of each user can be selected from first name, last name, cell number, email, identity document number and date of issue, other data corresponding to personal information known to a person fairly well versed in the matter and combinations of the above.
  • the step of comparing the pattern with a base pattern that is stored in a second database of a third server on a third server and comparing the time in which the issuing user enters the pattern against a reference time stored in the second database can run a risk engine that has a machine learning or computational learning component.
  • the machine learning or computational component includes requesting the first server for exchange history data from the sending user; request the second server for social interaction data of the issuing user; and comparing on the third server the exchange history data and social interaction data of the sending user with distinctive data related to the publication of the receiving user, where the third server generates a second authorization data that it sends to the first server.
  • the method step of authorizing the transaction the second authorization data is received before authorizing through the first server in the transactional application the transaction between the sending user and the receiving user.
  • these method realizations compare some characteristics of the product, such as price, type of product, location of the receiving user (distinction data); characteristics of the user's profile, such as favorite pages, publications related to the type of product, preferences in audiovisual and bibliographic content between the receiving user and the sending user, geographical distance between the receiving and sending users (social interaction data), and characteristics of purchasing habits, for example, maximum transaction value, currency used, payment terms used, number of products or services purchased (exchange history data).
  • the risk engine also includes sending a first set of data associated with the pattern which are generated when the issuing user enters the pattern in the transactional application from the computing device, where the first set of data is send to an item called Event Hub located on the fourth server.
  • the risk engine includes analyzing and comparing the first set of data against the base pattern using an element called Stream Analytics-Real Time, where the base pattern is stored on the third server; and send the first data set analyzed and compared from the Stream Analytics-Real Time element to an element called Data Factory and to an element called DB-Fraud Detection Results SQF to store said data set if the pattern matches the base pattern.
  • the risk engine may include sending the first data set analyzed and compared from the Data Factory element to a computational learning component called Machine Feaming.
  • Machine Feaming Using the computational learning component called Machine Feaming, you can decide if the transaction between the sending user and the receiving user is rejected, accepted, or rejected / accepted, where the machine learning component called Machine Leaming generates the first authorization data when the transaction is accepted, where the machine learning component called Machine Leaming sends the authorization data to the DB-Fraud Detection Results element SQL to store them, and where the third server queries in the DB-Fraud Detection Results SQL element the first authorization data to send them to the first server when the transaction is authorized.
  • the transactional application may be configured to allow the receiving user to manage from his computing device an inventory of products or services relating each product or service with a direct link that is published on the social network, where Inventory management includes adding, removing, or modifying published products or services.
  • the tag detection step may further include a substep of running a bind service (webhook) managed by the second server.
  • the linking service runs permanently to detect when the sending user enters the tag in the publication made by the receiving user within the social network.
  • the binding service generates an order for the second server when it detects the label, the order configured to generate that the second server communicates with the first server so that said first server runs the transactional application on the issuing user's computer device.
  • the system for authorizing through computational devices a transaction between a sending user and a receiving user that are previously registered in the social network comprises a first computing device of a sending user configured to execute a transactional application; a second computing device of a receiving user configured to run the transactional application.
  • the system includes a first server connected through a communications network with computing devices and configured to manage the transactional application, saving a first database that includes registration data of the issuing user and registration data of the receiving user and generating profiles of the issuer and receiver of said users from the association of the registration data of the users with some requested social network profile data that the first server requests from a second server.
  • the first server is configured to save the sender and receiver profiles of said users; validate if the sending user and receiving user have sender and receiver profiles stored in the first database when the second server detects a tag; request the issuing user to enter a pattern in the transactional application running on the computing device; receive authorization data from a third server.
  • the second server is connected through the communications network to the first server and is configured to manage the social network; detect the tag, where the tag is entered by the sending user in a publication made by the receiving user within the social network.
  • the detection of the label generates that the second server communicates with the first server so that said first server runs the transactional application installed on the issuing user's computing device.
  • the system includes a third server connected through the communications network to the servers.
  • the third server is configured to measure and compare the time in which the sending user enters the standard against a reference time stored in the second database.
  • the third server and the second server can be the same server, or they can belong to a farm or cluster of servers.
  • the server or server farm has a first module and a second module, where the first module is configured to execute the actions that the second server executes in other modes of the method, and where the second module is configured to execute the Actions that the third server executes in other modalities of the method.
  • the system includes a fourth server configured to authorize the transaction between the sending user and the receiving user, where the fourth server notifies the first server that the transaction is authorized; and where the third server generates the first authorization data and sends it to the fourth server when the patterns match.
  • the system described above is configured to execute any of the method embodiments described at the beginning of this section of the Descriptive Chapter.
  • Figure No.l It shows a flow chart that exposes the logical sequence of the set of orders, steps or technical steps that make up a modality of the disclosed method and that in turn is integrated with a modality of the disclosed system, to authorize transactions in social networks.
  • Figure No.2 It shows a general diagram that exposes some of the technical elements along with their respective interaction that are part of a disclosed system modality and method.
  • Figure No.3 It shows a diagram of the functional process of a modality of a transactional application where a sender / buyer user carries out a transaction; Likewise, in this figure No.3, the diagram illustrates the technical elements together with their respective interaction and of a disclosed system and method.
  • Figure No.4 It shows a diagram of the functional process of a modality of a risk engine together with all its tangible and intangible technical elements and their respective interaction that takes place within a modality of the method and the system. disclosed.
  • One of the objectives of the method disclosed here is to authorize transactions between a sending user (100C) and a receiving user (100V) in social networks through computing devices (300C, 300V).
  • a transaction such as a purchase or transfer of goods
  • a transactional application (200) where an issuing user (100C) enters a label in a publication made. by the receiving user in the social network (RD).
  • the issuing user (100C) can participate in the transaction without leaving the social network (RD), and interacted with the transactional application (200) from their computing device at the time of entering a pattern at a certain time .
  • the method disclosed here can be implemented in the authorization of a transaction that involves a money transfer between two users (100C, 100V) allowing the funds to be moved or transferred from an account of an issuing user to a user account.
  • issuer / buyer (100C) through interactions on a social network (RD) safely, without the need for applications or additional elements required by a bank or financial institution, all in real time without the end user noticing or having significant delays.
  • RD social network
  • Another objective of the method disclosed here is to reduce the time that an issuing user (100C) spends on a transaction, from the time they state their intention to make the transaction until it is authorized.
  • the method disclosed here is aimed at reducing the number of interactions the user makes, for example, in the case that you must fill out forms, use payment gateways, be redirected to other web portals or applications.
  • the issuing user (100C) enters a tag in a publication made by the receiving user in the social network (RD), which causes the transactional application (200) to run on the issuing user's computing device ( 100C) requesting it to enter the pattern at a certain time, which is then compared with a base pattern and with a reference time stored in the third server (403).
  • the transaction is authorized.
  • the user perceives that the time he invests in the transaction is much less than what he would use if he had to interact with payment gateways, web pages, forms, authorization calls, entry of keys sent by notifications, SMS, or e-mail, and other methods of authentication and authorization disclosed in the state of the art.
  • the method allows to carry out an easy, secure and immediate financial transaction in real time through a social network (RD) application external to the banking application, using commands marked with predefined labels, which it takes necessary information from both the sender and the receiver of the transaction, generating the validation and authorization of the transaction through an application, which can be a non-native progressive web application or a conventional native application, this is done through integration and combination of various elements (mobile devices such as a mobile phone, a tablet, or any other device with internet access, a computer or other electronic device with communication elements that have internet access located elsewhere) that are part of the system ( hardware) that together with the method allow to optimize the validation of the identi the user, maintaining all the security protocols that in turn guarantee that the transaction is totally safe in accordance with the standards of the bank or financial institution, where the system is the tangible part that allows the method to carry out a secure transaction. , easy and immediate, through the use of social networks.
  • RD social network
  • easy and safe transactions are made in social networks for mobile devices such as a mobile phone, a tablet, or any other device with internet access which are part of the system, also , through technical elements such as a computer or other electronic device with communication elements that have internet access that are located elsewhere and that in turn are part of the same system, receive, process, transform, and / or emit data
  • the method to carry out an easy, secure and immediate financial transaction through social networks using commands marked with predefined labels which takes necessary information from both the issuer and the recipient of the transaction and generates the validation and authorization of the transaction through an application, which can be a non-native progressive web application or a conventional native application, where the system is the tangible part that allows the method to carry out a secure, easy and immediate transaction through the use of social networks.
  • a secure transaction can be authorized through social networks by invoking a specific command and implementing a security pattern, where the method is carried out in the system.
  • the system is made up of technical elements such as a computer, mobile phone, tablet, or any other device with internet access or similar which can be found located in different places
  • a transactional application 200
  • this is carried out through communication between electronic communication devices such as cell phones, tablets, computers, eg laptops among others.
  • this disclosure describes modalities of a system (S) and a method (M), which can carry out easy and secure transactions in social networks for mobile devices, which is made up of a set of orders or steps or stages techniques (a, b, c, d, e, f, g, 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 and 2A) that integrate method (M) together with technical elements (300, 301, 310, 400) that make up the entire system (S), where system (S) is the tangible part that allows method (M) to be carried out to make a secure, easy and immediate transaction, through the use of social networks (RD).
  • RD social networks
  • said method is made up of a set of orders, steps, technical steps or logical components necessary to carry out an easy, secure and immediate financial transaction in real time through a network application social (RD) external to the banking application, using commands marked with predefined labels, which take necessary information from both a sender and a receiver of the transaction, generating the validation and authorization of the transaction through an application, which can be a non-native progressive web application or a conventional native application, this is done by integrating and combining several tangible technical elements that make up and are part of the (S) or (hardware) system, which together with the (M) method allow optimization of the validation of the user's identity, maintaining all the security protocols which in turn guarantee that the transaction is t otally secure in accordance with the standards of the bank or financial institution, where the system (S) is the tangible part that allows the method (M) to be carried out to carry out a secure, easy and immediate transaction, through the use of social networks; Below is the logical sequence of the set of orders,
  • Step 1.a The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network; Step 1. b the user logs into the transactional application (200) through any mechanism in which the transactional application (200) can be run. For example, the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step l.c After the user has entered the transnational application, he is in a main interface of the transactional application (200) in which the user will have to register or log in. Step l.d (YES) If the user is registered in the database of the first server (400), continue with step l.e;
  • Step Le proceeds to create the seller profile in the transactional application (200) for which the user adds a profile of some social network (RD), the first action of the user is to log in to the social network (RD) and through A transactional application interface (200) shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system.
  • the search system identifies in the databases of the social network (RD) located on the second server (402) the number of profiles that the user has.
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option of selecting which of these profiles is their seller profile;
  • Step 1J if the user agrees to add a seller profile the user selects which of the profiles that appear in the social network (RD) interface corresponds to their seller user profile, when selecting the profile this data is stored profile in a database located on the first server.
  • RD social network
  • Step l.g In the case that the user if he had added a seller's profile through an interface, the user is asked if he wants to sell products;
  • Step lh if the user accepts, we proceed to request the information of the products, for which the user is asked to give information such as the quantity, the name, etc., to the transactional application (200) to save this information in a database. located on the first server (400).
  • Step I The user proceeds to the approval of publishing the product in the social network (RD).
  • the first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step la.b the user logs into the transactional application (200) through any mechanism in which the transactional application (200) can run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step la.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or log in.
  • Step la.d If the user is registered in the database of the first server (400), go to step la.e;
  • Step la.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log in to the social network (RD) already
  • a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has.
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option to select which of these profiles is their seller profile.
  • Step la.f if the user agrees to add a seller profile, the user selects which of the profiles that appear in the social network (RD) interface corresponds to their seller user profile, when selecting the profile, they store this profile data in a database located on the first server (400);
  • Step la.g In the case that the user if he had added a seller profile through an interface, the user is asked if he wants to sell products
  • Step la.h In the case that the user does not want to add products for sale, he returns to the interface of adding seller profile.
  • the first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step lb.b The user logs into the transactional application (200) through any mechanism in which the transactional application (200) can run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step lb.c After login the user is in a main interface of the transactional application (200) in which the user will have to register or login.
  • Step lb.d (YES) If the user is registered in the database of the first server (400), step lb.e is passed;
  • Step lb.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log in to the social network (RD) already
  • a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has.
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option to select which of these profiles is their seller profile.
  • Step lb.f If the user does not want to add a seller profile, proceed to skip this step and proceed to the user registration of the issuer / buyer profile.
  • a transactional application interface (200) allows you, if the user agrees, to add a sender / buyer profile, as the user already registered the social network (RD) in the previous step of adding the seller profile, the The system has already identified the profiles of the social network (RD) that are associated with the account registered in the social network (RD) by the user;
  • Step lb.g (YES) we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application (200) and we proceed to store this profile in a database located on the first server ( 400).
  • a webhook system is immediately activated on the second server (402) of the social network (RD) which identifies any activity that is registered by any user, be it a receiver / seller user (100V) or a sender / buyer user (100C) in a social network (RD);
  • Step lb.h-i (SI) When an issuing user / buyer decides to make a purchase through the transactional application (200), proceed with step l.b.j
  • Step l.b.j the user enters any social network (RD) of his preference;
  • Step l.hk makes a comment on the publication of the product you want to buy from the recipient / seller user (100V) this seller user must be registered in the transactional application (200) and be registered in the database of the first server (400) of the transactional application (200), the alert system that was activated at the time of registration called WEBHOOK identifies an interaction in the profiles that are stored in the database of the first server (400) and reports this activity to the first server ( 400)
  • Step lbl The issuing / purchasing user receives a notification on the electronic purchase approval device, this notification comes through the transactional application (200) and is reflected on the device in any of the forms of notification that the device electronic drive
  • Step lbm If the issuing / purchasing user does not receive the notification, go to step lbn; Step lbn In the event that the notification is not received, the user must enter the control menu of his electronic device and approve the notifications of the transactional application (200), and go to step lb0;
  • Step lb.o Return to step l.b.b.
  • Step lc.a The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step lc.b The user logs into the transactional application (200) through any mechanism in which the transactional application (200) can be run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step lc.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or log in.
  • Step lc.d SI
  • the user If the user is registered in the database of the first server (400), then go to step lce; Step lc. Proceed to create the seller profile in the transactional application (200), for this the user adds a profile of some social network (RD), the first action of the user is to log in to the social network (RD) already
  • a transactional application interface it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has.
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option of selecting which of these profiles is their seller profile;
  • Step lc.f If the user does not want to add a seller profile, proceed to skip this step and proceed to the user registration of the issuer / buyer profile.
  • a transactional application interface (200) allows you, if the user accepts, to add an issuer / buyer profile, as the user already registered the social network (RD) in the previous step of adding the seller profile, the system already has identified the profiles of the social network (RD) that are associated with the account registered in the social network (RD) by the user;
  • Step lc.g (YES) we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application (200) and we proceed to store this profile in a database located on the first server ( 400);
  • Step l.c.h the user is asked to indicate if they want to buy a product
  • Step lc.l In case the user does not want to buy any product, the transactional application (200) returns it to the initial interface, for example to step l.c.e, or to step /. c. b.
  • Step Id A The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network
  • Step Id. B The user logs into the transactional application (200) through any mechanism in which the transactional application (200) can run. For example, the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • Step ld.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or login.
  • Step ld.d If the user is registered in the database of the first server (400), then go to step ld.e;
  • Step ld.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log into the social network (RD) already
  • a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has.
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option of selecting which of these profiles is their seller profile;
  • Step Id.f if the user agrees to add a seller profile the user selects which of the profiles that appear in the social network (RD) interface corresponds to their seller user profile, when selecting the profile they are stored this profile data in a database located on the first server (400);
  • Step ldg In the case where the user had added a seller profile through an interface, the user is asked if he wants to sell products;
  • Step ldh if the user accepts, proceeds to request the information of the products, for which the user is asked to give information such as quantity, name etc, to the transactional application (200) to save this information in a database located on the first server (400).
  • Step Idi The user is given the approval to publish the product on the social network (RD);
  • Step ldh (NO) In case the user does not want to add products for sale, go back to step ld.e).
  • Step ldJ If the user does not want to add a seller profile, proceed to skip this step and proceed to the user registration of the issuer / buyer profile.
  • a transactional application interface (200) allows you, if the user accepts, to add an issuer / buyer profile, as the user already registered the social network (RD) in the previous step of adding the seller profile, the system already has identified the profiles of the social network (RD) that are associated with the account registered in the social network (RD) by the user;
  • Step l l.j (YES) we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application
  • Step ld.j (NO) In case the user does not want to register any issuer / buyer profile and had registered a seller profile, the user ends his registration process in the transactional application (200).
  • a webhook system is identified immediately on the second server (402) of the social network (RD), which identifies some activity that is registered by any user, be it a receiving / selling user (100V) or a sending / buying user (100C) in a social network (RD)
  • Step Id.l (Yes) An issuer / buyer user decides to make a purchase through the transactional application (200).
  • Step ld.l In case the user does not want to buy any product, the transactional application (200) returns it to the initial interface;
  • Step ld.m enters any social network (RD) of his preference, and goes to step l.d.n;
  • Step ll. ⁇ (NO)
  • the user In the case that the notification is not received, the user must enter the control menu of his electronic device and approve the notifications of the transactional application (200).
  • Step 1 The transactional application (200) through an interface asks the user to enter the transaction validation pattern if the user accepts and fills in the pattern, this validation data is saved on the first server (400) of data and sent to the third server (403).
  • Step lJo (No) In case the user does not enter the validation pattern, the application will reject the transaction.
  • Step ld.p (SI)
  • SI Session Identity
  • Stream Analytics a service from AZURE® (MICROSOFT®)
  • AZURE® MICROSOFT®
  • real-time analysis service for example the Event Hub service, which is a fully managed real-time data ingest service also from AZURE®
  • SQL type fraud detection module which is a database where all the information from the previous analysis of the transactions made by the issuing user is stored.
  • Step lcLp (No) In case the Risk Engine (600) identifies that there are not enough guarantees to approve the transaction, the application transactional (200) cancels the transaction and returns issuing user / buyer (100C) to step ld.b;
  • Step ld.q The data sent from the pattern and stored in the third server (403) are compared with the data from the user registry and based on certain variables such as the pattern execution time and the speed of the entry of the pattern are compared with these same indexes at the time of registration and the identity of the user is validated.
  • Step ld.q If the data sent from the pattern and stored on the third server (403) does not correspond to the data at the time of registration by the transactional application (200), the transaction is canceled and the issuing / purchasing user returns ( 100C) to the initial interface of step ld.b.
  • Step ld.r (SI) In the case in which the two previous validation systems were passed, it is passed to the validation by the banking core (1100) which is located on the fourth server (404), where it is identified in the financial products that exist the people requesting the transaction, also that there are sufficient funds to carry out the transaction and if so, proceed with the transaction.
  • Step ld.r In case the validation by the banking core (1100) is not successful, the transactional application (200) cancels the transaction and returns the issuing / purchasing user (100C) to the initial interface.
  • Step le.a The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step le.b The user logs into the transactional application (200) through any mechanism in which the transactional application (200) can be run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step le.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or log in.
  • Step le.d If the user is registered in the database of the first server (400), then go to step le.e; Step le.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log into the social network (RD) already Through a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has. The interface shows the user the profiles that are associated with the social network (RD) and gives them the option of selecting which of these profiles is their seller profile;
  • Step le.f If the user does not want to add a seller profile, proceed to skip this step and proceed to the user registration of the issuer / buyer profile.
  • a transactional application interface (200) allows you, if the user accepts, to add an issuer / buyer profile, as the user already registered the social network (RD) in the previous step of adding the seller profile, the system already has identified the profiles of the social network (RD) that are associated with the account registered in the social network (RD) by the user;
  • Step le.j we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application (200) and we proceed to store this profile in a database located on the first server ( 400).
  • a webhook system is immediately activated on the second server (402) of the social network (RD) which identifies any activity that is registered by any user, be it a receiver / seller user (100V) or a sender / buyer user (100C) in a social network (RD);
  • Step le.l An issuing / purchasing user decides to make a purchase through the transactional application (200);
  • Step le.m enters any social network (RD) of his preference
  • Step le.n The issuing / buying user comments on the publication of the product that they want to buy from the receiving / selling user (100V).
  • This receiving / selling user (100V) must be registered in the transactional application (200) and must be registered in the database of the first server (400) of the application Transactional (200), the alert system that was activated at the time of registration called WEBHOOK identifies an interaction in the profiles that are stored in the database of the first server (400) and reports this activity to the first server (400);
  • the issuing / purchasing user receives a notification on the electronic purchase approval device. This notification comes through the transactional application (200) and is reflected on the device in any of the forms of notification that the electronic device drive.
  • Step le.o The transactional application (200) through an interface asks the issuing / purchasing user to fill out the transaction validation pattern if the user accepts and fills out the pattern, this validation data is saved in the first data server (400) and sent to the third server (403).
  • Step le.p (No) In case the Risk Engine (600) identifies that there are not enough guarantees to approve the transaction, the transactional application (200) cancels the transaction and returns the issuer / buyer user to the initial interface of the step le.b.
  • the Risk Engine (600) can be the same explained in process 1D.
  • Step lf.a The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step lfb the user logs into the transactional application (200) through any mechanism in which the transactional application (200) can be run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step lf.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or log in.
  • Step lf.d (SI) If the user is registered in the database of the first server (400), then, go to step lf.e
  • Step lf.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log in to the social network (RD) already Through a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has.
  • RD social network
  • the interface shows the user the profiles that are associated with the social network (RD) and gives them the option of selecting which of these profiles is their seller profile; Step lff (NO) If the user does not want to add a seller profile, proceed to skip this step and continue to the user registry of the issuer / buyer profile.
  • a transactional application interface (200) allows you, if the user accepts, to add a issuer / buyer profile, as the user has already registered the social network (RD) in the previous step of adding the seller profile, the system has already identified the social network (RD) profiles that are associated with the account registered in the social network (RD) by the user;
  • Step Ifj we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application (200) and we proceed to store this profile in a database located on the first server (400)
  • a webhook system is immediately activated on the second server (402) of the social network (RD) which identifies any activity that is registered by any user, be it a receiver / seller user (100V) or a sender / buyer user (100C) in a social network (RD);
  • Step lf.l An issuing / purchasing user decides to make a purchase through the transactional application (200);
  • Step lf.m the issuing / purchasing user enters any social network (RD) of their choice;
  • Step lf.n the issuing / buying user comments on the publication of the product that they want to buy from the receiving / selling user (100V) this receiving / selling user (100V) must be registered in the transactional application (200) and must be registered in the database of the first server (400) of the transactional application (200), the alert system that was activated at the time of registration called WEBHOOK identifies an interaction in the profiles that are stored in the database of the first server ( 400) and report this activity to the first server (400) Step lf. ⁇ (YES)
  • the issuing / purchasing user receives a notification on the electronic purchase approval device. This notification comes through the transactional application (200) and is reflected on the device in any of the forms of notification that electronic device drive.
  • Step lf.o The transactional application (200) through an interface asks the user to fill in the transaction validation pattern if the user accepts and fills in the pattern, this validation data is saved on the first server (400 ) of data and sent to the third server (403).
  • Step lf.p SI
  • the third data server (403) it is verified that the transaction is normal and that the issuing / purchasing user who is requesting it is him.
  • This step can be carried out through different tools such as Stream Analytics, a service from AZURE® (MICROSOFT®); a real-time analysis service, for example, the Event Hub service, which is a fully managed real-time data ingest service also from AZURE® and an SQL-type fraud detection module which is a database of data where all the information from the previous analysis of the transactions made by the issuing user is stored.
  • Stream Analytics a service from AZURE® (MICROSOFT®)
  • a real-time analysis service for example, the Event Hub service, which is a fully managed real-time data ingest service also from AZURE®
  • an SQL-type fraud detection module which is a database of data where all the information from the previous analysis of the transactions made by the issuing user is stored.
  • Step lfq If the data sent from the pattern and stored on the third server (403) does not correspond to the data at the time of registration, the transactional application (200) cancels the transaction and returns the issuing / purchasing user to the initial interface of the step lf.b ;.
  • Step lg.a The first procedure is the entry to the transactional application (200) by any user through an electronic device that has communication with a telecommunications network;
  • Step Ig. b the user logs into the transactional application (200) through any mechanism in which the transactional application (200) can be run.
  • the user enters the social network (RD) through a computing device that is configured to execute the transaction application.
  • RD social network
  • Step lg.c After entering the user is in a main interface of the transactional application (200) in which the user will have to register or log in.
  • Step lg.d If the user is registered in the database of the first server (400), go to step lg.e; Step Ig.e proceed to create the seller profile in the transactional application (200) for this the user adds a profile of some social network (RD), the first action of the user is to log into the social network (RD) already Through a transactional application interface (200) it shows the user the different profiles that are associated with the account with which they registered in the social network (RD) through a search system, which identifies in the social network (RD) databases located on the second server (402) the number of profiles the user has. The interface shows the user the profiles that are associated with the social network (RD) and gives them the option to select which of these profiles is their seller profile
  • Step lg.f If the user does not want to add a seller profile, proceed to skip this step and continue to the user registry of the issuer / buyer profile.
  • a transactional application interface (200) allows if the user accepts, add an issuer / buyer profile, as the user has already registered the social network (RD) in the previous step of adding the seller profile, the system has already identified the social network (RD) profiles that are associated with the account registered in the social network (RD) by the user;
  • Step lg.j (SI) we proceed to select which of the profiles the user determines as his issuer / buyer profile before the transactional application (200) and we proceed to store this profile in a database located on the first server ( 400)
  • a webhook system is immediately activated on the second server (402) of the social network (RD) which identifies any activity that is registered by any user, be it a receiving / selling user (100V ) or an issuer / buyer user (100C) in a social network (RD);
  • Step lg.l An issuer / buyer user decides to make a purchase through the transactional application (200); Step lg.m the issuer / buyer user enters any social network (RD) of their choice and goes to step lg.n;
  • RD social network
  • Step Ig. ⁇ (YES)
  • the issuing / purchasing user receives a notification on the electronic purchase approval device, this notification comes through the transactional application (200) and is reflected on the device in any of the forms of notification that electronic device drive;
  • Step Ig.o The transactional application (200) through an interface asks the user to fill in the transaction validation pattern if the user accepts and fills in the pattern, this validation data is saved on the first server (400 ) of data and sent to the third server (403).
  • Step Ig.p SI
  • the third data server (403) it is verified that the transaction is normal and that the issuing / purchasing user who is requesting it is him.
  • This step can be carried out through different tools such as Stream Analytics, a service from AZURE® (MICROSOFT®); a real-time analysis service, for example the Event Hub service, which is a fully managed real-time data ingest service also from AZURE® and a SQL type fraud detection module which is a database where all the information from the previous analysis of the transactions made by the issuing user is stored.
  • Step lg.q NO
  • Step lg.q The data sent from the pattern and stored in the third server (403) are compared with the data in the user registry and based on certain variables such as the pattern execution time, the speed between points are compared with these same indexes at the time of registration and user identity is validated.
  • Step lg.r (NO)
  • the transactional application (200) cancels the transaction and returns the issuing / purchasing user to the initial interface of step lg.b.
  • Figure No.1 illustrates each of the logical sequences of the set of orders, steps or technical steps that make up processes 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 and 2A, which in turn Once they make up the entire method (M) to generate a secure transaction in social networks with non-native applications or a conventional native application on mobile devices (300) or computing devices (300C, 300V), said method (M) is executed by a device electronic with internet connection and that communicate through a telecommunications network (310), where this electronic device can correspond, without limitation, to a server, personal computer, laptop, tablet, mobile phone, and / or the like that are part of of the system (S). (See figures No.1, No.2, No.3 and No.4).
  • Method (M) for carrying out the logical sequence of the set of orders, steps or technical steps of processes 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 and 2A comprises each of the following steps or technical steps that will be described below and which in turn will also be done in synchrony by integrating and configuring various technical elements that make up the system (S), as follows: a) Register (1) and store (1.3, 2.4, 3.1) the data of a user (100) who can be a sender / buyer user (100C) only or a sender / buyer user (100C) and at the same time be a receiver / seller user (100V), in a database of a transactional application (200), for example, a progressive web application PWA (200), where said registration (1) includes the creation of a profile for each user (100) with their personal data, by logging in (2) on a social network (RD) where the transaction will take place and, at your Once, it will open (1.2) the financial product that will be related to the
  • the transactional application (200) for example, a progressive PWA web application, is executed. (200) of the user (100) internally in said mobile device (300) so that it authorizes the transaction (7.3) by means of a pattern (7.2 ') for validation (7.1), requesting that the issuing / purchasing user (100C) enter in the mobile device (300) (specifically in the social network application (RD)) a predefined pattern (7.2 ") that serves for authentication of the information and verification of the user (100); (See figures No.2 and No.3).
  • a server (400) can be used that has an API SP (500) application programming interface. along with a risk engine (600) that corresponds to an element in the architecture that allows interaction between social networks (RD) and a transactional application (200). (See figures No.1, No.2, No.3 and No.4).
  • the transactional application (200) is a non-native PWA (200) progressive web application, running on a mobile device (300) connected to the internet, said PWA (200) progressive web application.
  • Non-native is used to perform various functions, where this type of non-native PWA (200) progressive web application uses technologies available in mobile device browsers (300) as defined above, in order to offer a experience on mobile devices (300), very similar to that of a native application, without having to be a native application, and consequently, without having to download or install directly on the mobile device (300).
  • the method (M) previously described is conditioned on the publication (3) of an article or product and / or service for sale or similar or the request for money and transfer of the same in a social network ( RD) which is done through an application called INNVO which is an electronic deposit
  • said INNVO application is supported, communicated and synchronized through a transactional application (200), for example, a progressive web application PWA (200) that is contained in the mobile device (300) of the user (100)
  • said user (100) through the INNVO application can link a profile, which can be a buyer profile (C) and / or a seller profile (V), also this user (100) can add a venture or business according to the related profile (buyer (C) and / or seller (V) respectively)
  • this INNVO application can publish a product or article what the user enters (100) to this INNVO application, which in turn publishes said article or product about the social network (RD) doing it automatically, without said INNVO application
  • said application can carry out financial transactions by means of patterns (7.2 ', 7.2 ") that through a machine leaming (700) together with a risk engine (600) that are contained in a server (400) make information captures and user data (100) which is verified in a secure way that said patterns (7.2 ', 7.2 ") comply with the established parameters such as the speed and time to perform said patterns (7.2', 7.2") profiling the user (100) and in turn verifying it to carry out the financial transaction safely, or on the contrary, managing to detect if there is a possible fraud by proceeding to reject the financial transaction.
  • the INNVO application can withdraw, recharge and transfer money through ATMs of the bank or some financial entity and it can also do it from any savings bank account or current account that the user has (100), this is also done by invoking of a specific command or label (4) preceded by a special character, such as "@InnvoPagar", "INNVO" or any other that can be previously programmed or defined, where the present method (M) together with the system (S ) You can recognize that you want to make a transaction for a money transfer between two users (100C, 100V) and thus, proceed to authorize (7) or transfer the funds from one account to another directly in the social network (RD) , without the need for applications or additional elements required by a bank or financial institution, likewise, it is possible to carry out this process in an agile and immediate way and in real time without the end user (100) noticing or having it. ga considerable delays.
  • the INNVO application also allows to make financial transactions within a group of users (100C, 100V) securely in the social network (RD) through patterns (7.2 ', 7.2 ”) without the need to enter phone numbers or enter insecure data.
  • the group of users (100C, 100V) may be linked to the INNVO application and in turn are linked to the social network (RD).
  • This INNVO application can be easily removed from the mobile device (300) of the user (100) without the need for any authorization or procedure by the bank or financial institution. (See figures No.2 and No.3).
  • the data of both the issuing / buying user (100C) and the receiving / selling user (100V) are registered (1) and stored (1.3, 2.4, 3.1) in the application database transactional (200), for example, of a progressive web application (200), which is found within the mobile device (300) of the user (100) (said user (100) may be the same, as indicated above, that is, , a user (100) only buyer (C) or a user issuer / buyer (100C) and seller (V)), where it is possible to create a profile by means of a simplified registry (1) that includes the data of each user (100) , among which are: names, surnames, cell number, email, document number and its date of issue, where it is also important to take into account that the information of the business or undertaking (2.1, 2.2) of a user receiver / vendor (100V) is stored (2.4, 3.1) in the ap database Transactional authentication (200), for example, of a progressive web application PWA (200
  • the user (100) can log in with their social network (RD) platform in order to associate the ID of your profile in said network with the profile created in the transactional application (200), for example, a progressive web application PWA (200), and therefore to your electronic deposit of the product or any other financial product, such as, for example, a bank account (savings / checking).
  • RD social network
  • this user (100) invokes the transaction in the publication of the product by means of a comment that uses a set of predefined labels (4), as defined above, where this process takes place on its respective mobile device (300). (See figures No.2 and No.3).
  • the aforementioned transactional application (200) of the user (100) is executed in the condition of buyer (C) so that the latter authorizes the transaction through a pattern ( 7.2 ') that it carries out by means of its mobile device (300) that communicates with the server (400) of the financial entity making said pattern (7.2') which corresponds to a previously defined pattern (7.2 ") and stored in the server (400) of the financial entity.
  • the pattern (7.2 ') introduced by the issuing user / buyer (100C) is compared (6.4) with the base pattern (7.2 ”) stored in API SP (500) together with a risk engine (600) that is they find in the server (400) of the bank or financial institution, that, in case of coincidence of both patterns (7.2 ', 7.2 "), the financial institution or bank carries out the corresponding transaction (7.3) and debits the money from the account of the issuing / buying user (100C) to pass it to the receiving / selling user's account (100V), thus concluding with the purchase. (See figures No.2 and No.3).
  • the pattern (7.2 ') is an element of the product architecture whose main function is to authorize the transactions from a base pattern (7.2 ”) by the user (100) that is entered in a window generated by the transactional application (200 ), for example, a progressive web application PWA (200), which is carried out on its respective mobile device (300).
  • This pattern (7.2 ') could be developed, in an exemplary but not limiting way, on a 3x3 dot matrix in which the user (100) can define a pattern that is not marked on the screen of his mobile device (300), and authorization is given by comparing all the points, in the same order as the base standard (7.2 ”) that is stored in the API SP (500) of the server (400) of the bank or financial institution.
  • the pattern (7.2 ') used to verify the identity of the user (100) and thus authorize the financial transaction where said pattern (7.2') can be selected, without limitation of: dot matrices to draw a pattern, multi-digit security code (PIN), keyword, security questions, etc. (See figures No.2 and No.3).
  • the transactional application (200) allows the inventory management of products or articles, thus offering direct links with social networks (RD) to make publications and update their inventory. Additionally, it is possible to manage both profiles of the user (100) (said user (100) can be the same, or a sender / buyer user (100C) or a user who is both a sender / buyer user (100C) and a user receiver / seller (100V)), within the transactional application (200), for example, a progressive web application PWA (200), thus offering a transactionality between natural persons and businesses in social networks (RD). (See figures No.2 and No.3).
  • method (M) makes use of artificial intelligence, specifically with Machine Leaming (700) (machine learning, by its name in English, which will be defined later in detail), as clearly illustrated in figure No.2, No.3 and No.4, said Machine Leaming (700) is used in order to allow the financial transaction to be carried out more easily and quickly in accordance with the previous behavior of users (100C, 100V) and their previous transactions, that is, the system (S) associated with method (M) can connect to any type of artificial intelligence system that can be supplied by any type of provider, such as They are commercially known, in order that said system (S) is more efficient and predicts the behavior of users (100C, 100V) and the way they carry out transactions to reduce interaction times, and other variables involved.
  • Machine Leaming 700
  • machine learning by its name in English, which will be defined later in detail
  • Machine Leaming (700) corresponds to one of the expressions of artificial intelligence in which the machine such as a computer or server (400) and / or mobile device ( 300) or any machine has the ability to learn to perform tasks, predict behaviors and many more, from data analysis. (See figures No.2, No.3 and No.4).
  • a transactional application for example a progressive web application PWA (200)
  • One of those elements is a tool that drives the appearance of the user interface of the progressive web application PWA (200) efficiently and reliably, since the code is stored in the memory (301) cache of the mobile device (300). of the user (100) with which the social network (RD) is accessed. (See figures No.2, No.3 and No.4).
  • an HTTPS security protocol can be used in the internet connection, which guarantees the security of financial information between the transactional application (200), for example, a web application progressive PWA (200), and a cloud, as well as between the cloud and the financial institution.
  • a non-native PWA (200) application provides important advantages over a native application, as defined below. (See figures No.2, No.3 and No.4).
  • the transactional application (200) for example a progressive web application PWA (200), is a cross-platform application, it offers a responsive design that adapts to different screen sizes of various devices mobile (300). In addition to this, its use guarantees greater visibility since the transactional application (200) can appear in web search results and it is possible to download it for free, quickly and easily from any browser.
  • the transactional application (200) for example, a progressive PWA web application (200)
  • PUSH pop-up
  • the use of these applications guarantee a better performance than those native applications existing in the state of the art, a fact that allows the modalities of the disclosed method (M) that use a progressive web application PWA (200) as a transactional application (200) differ greatly from those existing in the prior art.
  • the transactional application 200 used for conducting the financial transaction is a conventional native application rather than a non-native progressive web application.
  • a payment process has to involve the interaction of the entire system (S), where in Figures No .2 and No.3 illustrate a single user (100), who can create two types of profiles: sender / buyer user (100C) and receiver / seller user (100V).
  • a user who wants to have sender / buyer user profiles (100C) and receiver / seller user (100V) performs the initial registration (1) and add or link a profile in their social network (RD ) typical of your business. (See figures No.1, No.2 and No.3).
  • the issuing / purchasing user (100C) enters the social network (RD), registers (1), when it is registered and in parallel, its information is stored (1.3, 2.4, 3.1) user in the database of the transactional application (200), for example, a progressive web application PWA (200).
  • a progressive web application PWA 200
  • the transactional application (200) for example, an application progressive web PWA (200)
  • the social network (RD) tries to link (5) and validate (6) the page so that it is read, if the answer is successful (5, 6), it is added to the social network (RD) and in parallel it is stored in the DB SL (900) database.
  • said receiving / selling user (100V) When the receiving / selling user (100V) appears registered as such in the social network (RD), said receiving / selling user (100V) can then publish (3) the products in the social network (RD) in question, which are they are differentiated by an ID that is assigned by the social network (RD) and which is stored (2.3, 6.1, 6.2.1) in the DB SL (900) database. (See figure No.2).
  • the issuing / buying user (100C) proceeds to make a comment in the publication of the receiving / selling user (100V) using the label (4), as defined above.
  • the social network (RD) notifies (5) the programming interface, which validates (6) filtering the comments that have the special characters and lets them pass, discarding the remainder that are not of interest to the transaction.
  • a risk engine (600) shown in Figures No.2, No.3 and No.4, comes into operation here, where the risk engine (600) outlines the customer or user (100) in relation to whether or not you are eligible to make a transaction, that is, whether you meet the pre-established conditions to carry out a purchase transaction on a social network (RD).
  • RD social network
  • the risk engine (600) proceeds to carry out the transaction in the banking core (1000) or environment of the financial institution, where it is validated that it has left a balance in the account bank, that there are still products available and other questions of law.
  • the transactional application (200) for example, a progressive web application PWA (200)
  • the risk engine (600) that is used to verify and validate the client or user (100) to know if it is suitable or not, to make a transaction, complying with the pre-established conditions by the bank or financial entity in order to carry carry out a secure purchase transaction in a social network (RD), said process is done through the configuration and arrangement of various elements that together with steps or steps that are carried out within the risk engine (600) are made as follows: from the transactional application (200), for example, a progressive web application PWA (200), which is located on the mobile device (300) of the user (100), said user (100) sends (1) the pattern (7.2 ') or pattern to verify your identity in order to authorize the financial transaction.
  • a progressive web application PWA 200
  • Said pattern (7.2 ') for example, a gesture made by the issuing / purchasing user (100C), corresponds to a set of information data to be verified and compared against a base pattern (7.2 ") that is found stored in API SP (500), to do this process this pattern is sent (7.2 ') through a set of information data that is sent to the element called Event Hub (1000) from a banking core (1100) (the Event Hub (1000) can call or fetch data from an external database (1110) from a server of the financial institution or bank) to manage the information that in turn sends it (2) to the element called Stream Analytics - Real time (920 ) which performs the analysis and comparison of the information, when this Information complies (4) is sent to the element called Data Factory (930) which organizes the information and stores it (5) in the element called DB-Fraud Detection Results SQL (910).
  • Data Factory 930
  • this information is also sent (5.1) to the machine leaming engine (700) where it in turn processes the information and responds (5.2), using the information provided to the machine leaming engine (700) where the information is sent to the called element again.
  • DB-Fraud Detection Results SQL (910) also if the information sent from the element called Event Hub (1000) or banking core (1100) to manage the information that in turn sends it (2) to the element called Stream Analytics - Real time (920) which performs the analysis and comparison of the information and when this information does not comply (3) is stored in the element called DB-Fraud Detection Results SQL (910), after the information has passed through the called element DB-Fraud Detection Results SQL (910) is validated where it can be rejected (3.1), accepted (5.3) rejected / accepted (6.2) to the transactional application (200), for example, a progressive PW web application To (200), which is located in the mobile device (300) of the user (100), also this information can be sent from the element called DB-
  • the machine leaming engine (700) located in the risk engine (600) can process and learn from the information received and received (5.4) from the transactional application (200), for example, a progressive web application PWA (200) , which is found on the mobile device (300) of the user (100) and also of the information related to or received from a server (400) that is located elsewhere. (See figure No.4).
  • system (S) is configured to carry out a modality of method (M) as defined above, wherein said system (S) is made up of a mobile device (300) of a first user (100), either a sender / buyer user (100C) or a receiver / seller user (100V), who has an application for access to a social network (RD) and which also allows accessing the internet, where said device (300) also includes an internal memory (301) for storing user data in order to enter when accessing the social network (RD) through the included application (INNVO); a telecommunications network (310) that allows the connection of multiple mobile devices (300) with the internet and with a social network (RD) for access; a server (400) where the social network (RD) is stored and allows users (100C, 100V) to access it, where said server (400) can be of a tangible or virtual type located in a cloud or in a computer located in another place, where the server (400) communicates with the mobile devices (300)
  • the system (S) disclosed here can be used to carry out a secure transaction through a social network (RD), where said transaction is carried out between two users (100C, 100V) configured as the issuing user / buyer (100C) and receiver / seller user (100V), respectively, where one of said users (100C, 100V) publishes a product (3) or a service offered for sale while the second user (100) configured as a buyer ( C) make the purchase through the social network (RD) using a series of labels (4) that are recognized by the social network (RD) and thus the transaction (7.3) is carried out in a secure manner and following patterns (7.2 ' , 7.2 ”) of validation, in order to communicate with the core banking server (1100) (financial institution) and thus, be able to transfer funds from the account of the issuing / purchasing user (100C) to that of the receiver / seller user (100V), infor In this way, I send the two users (100C, 100V) that the transaction was successful
  • the secure transaction is carried out using the method (M) previously illustrated, which allows obtaining The result of this transaction is securely between two users (100C, 100V) who are configured as seller (V) and buyer (C). (See figures No.l, No.2, No.3, No.4).
  • Computational device 300C, 300V: They are all those devices in which the transactional application can be executed and which are communicated through a communications network. Examples of computing devices (300C, 300V) are smartphones, tablets, phablets, personal computers, microprocessors equipped with internet communication modules and user interfaces, other equivalent computing devices known to a person of ordinary skill in the art, and combinations of the themselves.
  • the term "mobile device” (300) is used, which belongs to a set of computing devices (300C, 300V) that include any electronic device that can access a network, such as the internet , by any means, in order to be able to access a social network (RD) in the same way, where said mobile device (300) can be selected, without limitation, from the group consisting of a mobile phone, a laptop , a desktop computer, a server, a personal assistant, a tablet, or the like. (See figures No.2, No.3, No.4).
  • Transactional application (200) In some modalities of the disclosed method and system, a transactional application (200) will be understood as a channel that allows interactions between users (100C, 100V).
  • the transactional application 200 may be of the PWA, native APP, hybrid APP, web page, other types of equivalent applications known to a person of ordinary skill in the art, and combinations thereof.
  • Social network In some modalities of the disclosed method and system, Social network (RD) will be understood as a means of digital interaction between two or more people or users who may be natural and / or legal persons. This interaction can be expressed in various ways such as chats, fixed or temporary publications, comments and reactions that express feelings or thoughts such as "I like it", “I want it”, “I approve”, etc.
  • social networks Some examples of social networks are Facebook®, Instagram®, Linkedln®, SnapChat®, Telegram®, Pinterest®, Twitter®, Google + ®, WhatsApp®, WeChat®, Facebook Messenger®, Skype®, YouTube®, Tumble®, Baidu .tieba®, VWallete®, Tagged® Reddit®, Haboo®, QQ®, QZone-EcuRed, websites, blogs, virtual merchants (e-commerces, in English) and other equivalent social networks known by a person well versed in the subject.
  • Registration data will be understood as data that the user enters at the first moment of interaction with the transactional application (200), these data are aimed at creating and future validation of a person's identity, for example, in the stages of the method where a user enters or logs into the transactional application (200).
  • the first database (905) is a database that is located on the first server, which is responsible for storing and managing information delivered. by the user through the transactional application (200), and from which the registration data is formed.
  • the first database 905 may be selected from hierarchical databases, network databases, transactional databases, relational databases, multidimensional databases, object-oriented databases, documentary databases, deductive databases, and other equivalent databases known to a person of ordinary skill in the art.
  • Communications network shall be understood as a set of technical means that allow remote communication between autonomous equipment such as computing devices and servers. Normally it is about transmitting data by electromagnetic waves through various media (air, vacuum, copper cable, fiber optics, etc.).
  • Non-limiting examples of a communication network are the Internet, WAN, and LAN. It will be understood that the method and system disclosed here You can use any type of equivalent communication network known to a person who is fairly well versed in the field.
  • the issuer profile may be a version of the application in which only the relevant information for a issuing user / buyer (100C) is presented (also called in some embodiments disclosed as a buying user or issuing user a person who , by interacting with the application and its social network (RD), has the intention of emitting emission data towards a receiving / selling user (100V) (also called in some embodiments disclosed as selling user or receiving user).
  • the issuer profile can be a version of the application in which only the relevant information is presented for an issuing user / buyer (100C) who send issuance data corresponding to money transfer in exchange for receive reception data associated with the purchase of products, services and goods offered by a receiving / selling user (100V).
  • the receiver profile may be a version of the application in which only the relevant information is presented for a receiver / seller user (100V) (also called in some embodiments disclosed as seller user or receiver user), who, By interacting with the application and its social network (RD), you intend to receive some emission data in exchange for sending reception data.
  • the receiver profile may be a version of the application in which only the relevant information for a receiving / selling user (100V) to send to a sending / purchasing user (100C) is presented.
  • reception data corresponding to the transfer, shipment or transfer of products, services and goods in exchange for having received emission data sent by the issuing user / buyer corresponding to the transfer of money, goods, or information.
  • the profile of the social network (RD) can be an account or profile created by a person, natural or legal, in some previously established social network (RD).
  • RD social network
  • a person's profile may, or may not, allow them to interact with other people, view content generated by the same social network (RD) or perform actions such as playing, communicating, or publishing content, among others.
  • Label In some modalities of the disclosed method and system, the term “label” (4) is used, which can be an expression or word that allows highlighting a comment that can be made on the social network (RD), where said tag (4) can be any term or expression without limitation, which can preferably be preceded by some additional element, such as a predefined additional sign or some spelling or other symbol. (See figure No.4).
  • a “label” can be understood as a certain word (Fixed) that is commented on in a publication on the social network (RD) and that when completed activates the transactional application ( 200), for example, through a Webhook service configured to detect the entry of the tag.
  • publication means a piece in digital format that may include, text, multimedia, art or any other expression of content proper to the person who makes the publication or created by third parties.
  • the publication is published in a social network (RD) environment, page, or section, where one or more users who have social network (RD) profiles can view the published piece.
  • RD social network
  • a non-limiting example is when a receiving / selling user (100V) publishes a publication in a social network (RD) offering a product, service or, where the publication can be an image, video, animated image (GIF), hyperlink , text, or combinations thereof.
  • the term "pattern" (7.2 ') is used to an expression that allows the validation of a transaction, where said "pattern"(7.2') has no limitation and any means that allows perform the validation of the identity of the issuing user / buyer (100C) or seller (V) and can be selected, without limitation, a security number (PIN), a drawing pattern, a drop-down menu, some security questions, or similar, among others. (See figures No.2, No.3, No.4).
  • First authorization data In some modalities of the disclosed method and system, the first authorization data will be understood as a set of data that has an encrypted pattern and that are unique for each user, since they are registered by each user the first time interacts with transactional application (200).
  • the transactional application (200) prompts the user to enter an initial pattern that generates a set of base data that is saved to a server or database as a base pattern .
  • a third server (403) has a second database (900) where the base dataset corresponding to the base pattern (7.2 ") is stored.
  • the first server (400) sends a set of data associated with the pattern (7.2') to the third server (403), and the third server (403) compares the data set associated with the pattern (7.2 ') with the base data set associated with the base pattern (7.2 "), and the data set associated with the pattern (7.2') coincide with the data set base associated with the base pattern (7.2 "), then the third server (403) generates the first authorization data.
  • each time the sending user (also called in some method modalities and comparator user system) enters the pattern a set of time data is generated and sent to the second database (900) of the third server (403).
  • the second database (900) stores a set of average time data, which is compared against the time data associated with the time the issuing user spends entering the pattern (7.2) in the transactional application (200), and when the time data coincide with the average time data, and in addition, the data set associated with the pattern (7.2 ') coincide with the base data set associated with the base pattern (7.2 "), then the third server (403) generates the first authorization data, then the third server (403) generates the first authorization data.
  • Second authorization data In some modalities of the disclosed method and system, second authorization data will be understood as data that results in an artificial intelligence process where the identity of the Issuing user (also called in some modalities of the method and the comparing user system) and corroborates the payment request that was made through the social network (RD).
  • identity of the Issuing user also called in some modalities of the method and the comparing user system
  • RD social network
  • Reference time In some modalities of the disclosed method and system, reference time will be understood as the time it takes for the user to enter the pattern in the transactional application (200). This time can be a user validation variable because each user spends an average time entering the pattern through the transactional application (200), where an average time is stored in a database.
  • each time the sending user also called in some method and comparator user system modes enters the pattern, a set of time data is generated and sent to the second database (900) of the third server (403).
  • the second database (900) stores a set of data related to the average time, which is compared against the time data associated with the time the issuing user spends by entering the pattern (7.2) in the transactional application (200), and when the time data matches the average time data, the third server (403) generates the first authorization data.
  • the average time data may be updated each time the third server 403 generates first authorization data after having determined that time data associated with the time the user invests issuer by entering the pattern (7.2) in the transactional application (200) match the average time data.
  • the update can be generated by means of a data processing executed by the third server (403), where the data processing can be to generate an arithmetic, geometric, logarithmic mean, or any other type of statistical operation where the average time data is taken.
  • First server (400) In some modalities of the disclosed method and system, the first server (400) is a server associated with the transactional application (200) (application server, in English) that allows to attend requests from a client and return a matching answer.
  • the first server (400) can be located in a cloud, for example, a cloud like that of AWS (Amazon Web Service), and belong to a component in a transactional application infrastructure (200).
  • Second server (402) In some modes of the disclosed method and system, the second server (402) is a server configured to serve requests from a client and return a matching response.
  • the second server (402) can be located in a cloud, for example, a cloud like AWS (Amazon Web Service), and can belong to a component of a Social Payments (SP) infrastructure.
  • AWS Amazon Web Service
  • SP Social Payments
  • the overall Social Payments infrastructure is an application programming interface (API), also called the SP API, where the SP API is run by the second server (402).
  • the second server (402) may be configured to run a Social Listening process, so that the second server (402) consumes a social media watchdog service called Webhook, where the Webhook notifies the second server (402). that a tag (4) has been entered in a publication of a receiving / selling user (100V) in a social network (RD).
  • API application programming interface
  • the second server (402) may be configured to run a Social Listening process, so that the second server (402) consumes a social media watchdog service called Webhook, where the Webhook notifies the second server (402). that a tag (4) has been entered in a publication of a receiving / selling user (100V) in a social network (RD).
  • API application programming interface
  • the Webhook service runs permanently, that is, so that its functionality does not depend on external calls or requests, and its execution is automatic.
  • the second server 402 is configured to manage the social network (RD).
  • An example of managing the social network (RD) is when the second server (402) is able to receive requests from the first server (400) and query within the social network (RD), or send requests to the social network (RD) ), to obtain data or information required for the disclosed method.
  • Examples of data consulted in the social network (RD) are profile data of social network (RD), publication data associated with publications made by users, social interaction data, among others.
  • the third server (403) is a server configured to measure and compare the time at which the sending user (100C) enters the pattern (7.2 ') against a reference time stored in the second database (900).
  • the third server (403) can be located in a cloud, for example, a cloud like that of AWS (Amazon Web Service), and can belong to a component of a Social Payments infrastructure ( SP).
  • the Social Payments infrastructure is an application programming interface (API), also called the SP API, where the SP API is run by the third-party server (403).
  • API application programming interface
  • the third server 403 may be the same second server 402, or it may belong to a farm or cluster of servers belonging to a cloud, for example, a cloud like AWS's. (Amazon Web Service).
  • the second server (402) can be configured with a Social Listening module and a pattern comparison module that can belong to the Social Payments (SP) infrastructure.
  • SP Social Payments
  • the fourth server (404) is a server configured to receive authorization data from the second server (402) and / or the third server (403), and with Based on the receipt of the authorization data, authorize a transaction between a sender / buyer user (100C) and a receiver / seller user (100V). Furthermore, the fourth server (404) is configured to notify the first server (400) that the transaction was authorized, or rejected.
  • the fourth server (404) communicates with a banking core or banking core (1100).
  • the banking core or banking core (1100) is a digital space in which information intrinsic to the operation of a bank's business is centralized. Such sensitive information can be protected in terms of software, hardware and networks of telecommunications. Digital space can be found stored on physical servers or cloud computing spaces.
  • the fourth server 404 authorizes the transaction of transaction data containing information desired by the issuing / purchasing user (100C) and belonging to the issuing / selling user (100V).
  • the transaction data transaction is authorized when the fourth server (404) receives authorization data from the second server (402) and / or the third server (403).
  • the fourth server (404) verifies that the sender / buyer (100C) has available purchase or exchange data that are of interest to the receiving / selling user (100V). This verification can be done by consulting a database that contains data from a user or account profile, where each user or account profile has an associated balance of purchase data or exchange data of the issuing / purchasing user (100C).
  • the fourth server (404) verifies that the issuing / purchasing user (100C) has available purchase or exchange data that are of interest to the receiving user / seller (100V), and the fourth server (404) receives the authorization data from the second server (402) and / or the third server (403), then the transaction is authorized, and consequently the receiving / selling user (100V ) receives the purchase or exchange data belonging to the issuing / purchasing user (100C), and the issuing / purchasing (100C) receives the transaction data that contains information desired by the receiving / purchasing user (100C) and belongs to the issuer / seller user (100V).
  • the transaction data that contains information desired by the receiving user / buyer (100C) is associated with a product, service or that is published by the issuing / selling user (100V) in the social network (RD ).
  • the purchase data or exchange data that belong to the issuing user / buyer (100C) are associated with a balance of money that the issuing user / buyer (100C) has in a financial product, such as a bank account, credit card, wallet virtual, revolving credit, and other equivalent financial products.
  • the issuing user / buyer (100C) buys, receives and / or accesses the service, product or published by the issuing user / seller (100V), and the issuing / selling user (100V) receives money from the issuing / buying user (100C).
  • the issuer / seller user (100V) can receive and / or access another product, service or the issuer / buyer (100C), with which the transaction is equivalent to a barter or exchange of products, services and / or goods .
  • Risk Engine (600) In some modalities of the disclosed method and system, Risk Engine (600) will be understood as a process that allows identifying the level of risk that a transaction has based on the acquisition and administration of information.
  • An APW or PWA application is a web application that does not take up memory space on the device because its support is in the cloud, and can work to all users regardless of the browser they use as it can be adapted to each type of browser.
  • an APW or PWA application can include characteristics typical of mobile applications such as push notifications, GPS, and you can also download a shortcut that is installed in a user interface of a computing device (300C, 300V), for For example, a screen, start window, or app menu, without the need to download it from an app store.
  • APW or PWA applications can be automatically updated without adding load to the computing device (300C, 300V).
  • the APW application can work without having an internet connection thanks to a feature called Service Worker which allows you to perform actions within the application without the need for a stable connection since PWA applications can store information in cache memory, as well as native apps do. Also, PWA application is safe because it handles security protocols for information management such as TLS (Transport Layer Security). Additionally, the PWA application can be shared by URL through text messages and is very user-friendly since its design and experience is presented as an application. native. Also, PWA applications can include responsive design, this means that they can be run on any mobile device with any screen resolution.
  • TLS Transport Layer Security
  • the transactional application 200 may be a PWA application.
  • a financial product means a service offered by an organization that offers financial services, which allows a user to store, request, use, collect, invest (deposit in exchange for a return) money either physical (like a bank vault) or digital.
  • financial products are savings accounts, checking accounts, virtual wallets, credit cards, revolving credits, and combinations thereof.
  • a financial product is granted to the issuing / purchasing user (100C) when an organization that offers financial services through gives the issuing / purchasing user (100C) access to a financial product, where the user issuer / buyer (100C) can be a natural or legal person.
  • the financial product is awarded after the issuing / purchasing user (100C) requests to open the financial product.
  • the opening of the financial product is a process carried out by a user, natural or legal person, for example, the issuing / purchasing user (100C), to request an organization that offers financial services access to a financial product.
  • the organization offering financial services evaluates acceptance criteria that allow identifying whether The user complies with established conditions to have access to a financial product. Examples of acceptance criteria are: indebtedness, amount of income, user assets, credit history, and other equivalent indicators.
  • social interaction data of the issuing user / buyer (100C) shall be understood as data containing information related to the interactions that an issuing user / buyer (100C) performs in a social network (RD) from your social network (RD) profile, for example, favorite pages, type of publications you make on the social network (RD), friends or related users, interaction groups to which you belong in the social network (RD), hours of the day and days of the week in which the issuing / purchasing user (100C) uses their social network (RD) profile, among others.
  • RD social network
  • RD social network
  • RD social network
  • RD social network
  • exchange history data In some modalities of the disclosed method and system, social interaction data of the issuing user / buyer (100C) will be understood as data that contains information related to the transactions that an issuing user / buyer (100C) has carried out through the application.
  • transactional (200) the exchange history data may include information related to the number of purchases made by the issuing user / buyer (100C), maximum amount and minimum amount that the issuing user / buyer (100C) transfers through the application.
  • transactional (200) date of last interaction of the issuing / purchasing user (100C) in the transactional application (200), hours of the day and days of the week in which the issuing / purchasing user (100C) uses the transactional application (200 ) and other equivalent types of information.
  • distinctive data will be understood as data that contains information related to the publication of the receiving / selling user (100V) in the social network (RD).
  • the distinction data may contain information related to the type of product, service or offer offered, price, number of units, language of the publication, geolocation where the recipient / seller user (100V) made the publication, among others.
  • Inventory of products or services In some modalities of the disclosed method and system, inventory of products or services shall be understood as the number of available units of a product or service that the recipient / seller user (100V) has within the social network ( RD) to participate in transactions through the transactional application (200).
  • Machine Learning (700), machine learning engine, or artificial intelligence component In some disclosed method and system modalities, these terms will be understood to relate to an artificial intelligence process or algorithm that permeates a machine such as a computing device (300C, 300V), a computer or server (400) and / or mobile device (300) or other, can learn to make decisions.
  • the machine leaming engine (700) or artificial intelligence component may be an algorithm that guarantees the validation of a user through the capture of information from the social network (RD).
  • the machine leaming engine (700) takes receives input data, which may be social interaction data of the issuing user / buyer (100C) (eg preferred pages, type of publications it makes on the social network (RD), friends or related users, interaction groups to which they belong in the social network (RD), hours of the day and days of the week in which the issuing / purchasing user (100C) uses their profile of the social network (RD), among others), or the recipient / seller user (100V), distinctive data related to the publication of the recipient / seller user (100V) in the social network (RD) (eg type of product, service or Well offered, price, number of units, language of publication, geolocation where the recipient / seller (100V) made the publication, among others).
  • social interaction data of the issuing user / buyer (100C) eg preferred pages, type of publications it makes on the social network (RD), friends or related users, interaction groups to which they belong in the social network (RD), hours of the day and days of the week in which the issuing / purchasing user (100C
  • the machine leaming engine (700) receives as input data, exchange history data provided by the first server (400) corresponding to information related to the interaction of the issuing / purchasing user. (100C) with the transactional application (200).
  • the exchange history data provided by the first server (400) may include information related to the number of purchases made by the issuing user / buyer (100C), maximum amount and minimum amount transferred by the issuing user / buyer (100C) through the transactional application (200), date of last interaction of the issuing user / buyer (100C) in the transactional application (200), hours of the day and days of the week in which the issuing user / buyer ( 100C) uses the transactional application (200) and other equivalent types of information.
  • the machine leaming engine (700) may be an Azure ® Machine Leaning and AI service, eg, the Azure Machine Leaming Service ® service.
  • the machine leaming engine (700) receives as input data, data provided by the second server (402) and the third server (403) that correspond to information related to a base pattern (7.2 ”), And a pattern (7.2 ') that the issuing / purchasing user (100C) enters in the transactional application (200).
  • the machine leaming engine (700) receives as input data, data from a database (1110]) from a banking core (1100) or from a fourth server (404). , which contain information related to the issuer / buyer (100C) having available purchase data or exchange data that are of interest to the recipient / seller user (100V).
  • the purchase or exchange data belonging to the issuing user / buyer (100C) is associated with a balance of money that the issuing user / buyer (100C) has in a financial product, such as a bank account, credit card, virtual wallet, revolving credit, and other equivalent financial products.
  • the machine leaming engine (700) takes the input data and processes it so that it outputs decision data containing information related to whether the transaction is accepted, rejected, or accepted / rejected. .
  • the machine leaming engine (700) sends the first authorization data to a database component, for example, a DB-Fraud Detection Results SQL (910) database component, which it can be a SQL database service offered by Azure ®.
  • a database component for example, a DB-Fraud Detection Results SQL (910) database component, which it can be a SQL database service offered by Azure ®.
  • the third server (403) queries the DB-Fraud Detection Results SQL database component (910), to obtain the first authorization data and send it to the first server (400) when the transaction is authorized.
  • the machine leaming engine (700) can receive as input data, data provided by a module or element called Stream Analytics-Real time (920), which contain information processed by the module. or element called Stream Analytics-Real time (920).
  • the machine leaming engine (700) can receive as input data organized data from a component or element called Data Factory (930) that organizes data processed by the module or element called Stream Analytics-Real time (920).
  • Data analysis module or Stream Analytics-Real time element (920) In some modalities of the disclosed method and system, a data analysis module or Stream Analytics-Real time element (920) will be understood as a module that allows analysis data in real time.
  • the data analysis module or Stream Analytics-Real time element (920) can be a complex event processing and real-time analysis engine configured to analyze and process data from the first server (400), the second server (402), the third server (403), the fourth server (404) or the banking core (1100).
  • the Data Analytics module or Stream Analytics-Real time element (920) may generate patterns and relationships between the processed data. Patterns can be used to trigger actions and start workflows on other elements such as the Data Factory component (930) and the artificial intelligence component or machine leaming engine (700). In addition, patterns or data processed by the Data Analytics module or Stream Analytics-Real time element (920) can be stored in a DB-Fraud Detection Results SQL database component (910).
  • the data analysis module or Stream Analytics-Real time element (920) may be the Azure Stream Analytics ® service from Azure ®.
  • Data management module (930) or Event Hub module In some modalities of the disclosed method and system, the data management module (930) or Event Hub module may be a data transmission platform (in English) and intake of events that allows data to be captured from the first server (400), second server (402), third server (403) and fourth server (404) and / or from the banking core (1100).
  • the Data Management Module (930) or Event Hub module can send the data it captures to the Data Analytics module or Stream Analytics-Real time element (920).
  • the data analysis module or Stream Analytics-Real time element (920) can be the Azure Event Hubs® service from Azure®.
  • the DB-Fraud Detection Results SQL (910) element may be a database where all the information from the previous analysis of the transactions performed is stored by the issuing / purchasing user (100C).
  • the DB-Fraud Detection Results SQL (910) element may be an Azure® SQL database.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La presente divulgación, se refiere a un sistema y un método para transacciones fáciles y seguras en redes sociales para dispositivos móviles tales como un teléfono móvil, una tableta, o cualquier otro dispositivo con acceso a internet el cual hacen parte del sistema, asimismo, mediante elementos técnicos tales como un computador u otro dispositivo electrónico con elementos de comunicación que tenga acceso a internet que se encuentran ubicados en otro lugar y que a su vez hacen parte del mismo sistema, reciben, procesan, transforman, y/o emiten datos en donde se lleva a cabo el método para realizar una transacción financiera fácil, segura e inmediata por medio de redes sociales a partir de comandos marcados con etiquetas predefinidas, que toma información necesaria tanto del emisor como del receptor de la transacción y genera la validación y autorización de la transacción a través de una aplicación, que puede ser una aplicación web progresiva no nativa o una aplicación nativa convencional, en donde el sistema es la parte tangible que permite realizar el método para efectuar una transacción segura, fácil e inmediata, mediante el empleo de redes sociales.

Description

SISTEMA Y MÉTODO PARA TRANSACCIONES FÁCILES Y SEGURAS EN REDES SOCIALES PARA DISPOSITIVOS MÓVILES
CAMPO TÉCNICO RELACIONADO
La presente divulgación se relaciona con sistemas y métodos para autorizar transacciones entre un usuario receptor y un usuario emisor que incluyen la verificación de identidad del usuario emisor. Además, esta divulgación se encuentra dentro del campo tecnológico de las invenciones que se encuentran implementadas por computador dirigidas a autenticar la identidad de un usuario a través de dispositivos computacionales.
DESCRIPCIÓN DEL ESTADO DE LA TÉCNICA
Dentro del estado de la técnica anterior, se encuentran métodos y sistemas para realizar una transacción teniendo como soporte las redes sociales.
El documento US 2010/0306099 divulga un sistema y un método para autenticar y procesar solicitudes recibidas por medio de sitios web de redes sociales, en donde el sistema definido incluye un medio de almacenamiento de datos para almacenar los datos que asocian un primer número de teléfono de un usuario con unas identificaciones del usuario en un sitio web de red social; y un intercambio acoplado con el medio de almacenamiento de datos, donde dicho intercambio incluye un procesador de formato común y una pluralidad de conversores para interactuar con una pluralidad de controladores de comunicaciones móviles.
Así mismo, el método divulgado comprende los pasos de recibir en un servidor una solicitud de un usuario autenticado por un sitio web de red social; identificar un primer número de teléfono del usuario; comunicarse por el servidor con un teléfono móvil en el primer número de teléfono para confirmar la solicitud; y en respuesta a la solicitud que es confirmada por el teléfono móvil en el primer número de teléfono, procesar la solicitud usando los fondos asociados con el teléfono móvil en el primer número de teléfono. Sin embargo, con base al método y el sistema descritos en la patente de invención estadounidense US 20100306099 anteriormente enunciada, presenta una desventaja, la cual consiste en que requiere la comunicación del servidor con el teléfono móvil y la autenticación la hace por medio de un número de teléfono únicamente, lo cual no garantiza que la comunicación sea segura y no se establezca los protocolos de un banco o institución financiera para realizar las transacciones solicitadas.
Por su parte, el documento US 2013/0054458 divulga sistemas y métodos que utilizan una plataforma de red social para suministrar información de autenticación para realizar una transacción de transferencia de dinero, en donde el método puede incluir, obtener y utilizar la información de los datos del perfil de la red social en línea del remitente, receptor o ambos con el fin de facilitar una transacción conveniente y segura. Así, esta divulgación incluye una base de datos de perfil de red social en línea configurada para almacenar y correlacionar la información de perfil para múltiples usuarios y un dispositivo de procesamiento de transacción de transferencia de dinero en comunicación con la base de datos para autenticar una transacción de transferencia de dinero, en donde todas estas modalidades se implementan en internet, con aplicaciones dedicadas para un computador y/o un dispositivo móvil.
Por otro lado, el documento US 9,218,594 divulga un método y un sistema para la realización de pagos electrónicos asistidos en redes sociales, en donde el método incluye los pasos para determinar uno o más miembros de una red social que busca un pago hacia una contribución financiera de una transacción en tiempo real entre el usuario y un comercio; consultar dicho uno o más miembros en un orden basado en probabilidad descendiente de contribución financiera hasta que se hayan recibido suficientes fondos para el pago de la transacción; y procesar una transferencia de dinero desde el usuario y/o cada uno de los miembros al comercio para completar la transacción en tiempo real.
Por su parte, el documento US 2018/0183737 divulga sistemas, métodos y dispositivos para procesar transacciones de pago entre un usuario y un comercio usando un entorno de mensajería, en particular, un sistema de comercio permite que el usuario inicie una sesión de comunicaciones con un entorno de mensajería asociado con el comercio usando un lenguaje natural. Así, los mensajes enviados son analizados para identificar un producto y una solicitud de compra del producto identificado. Con base en el producto identificado y la solicitud para comprar el producto, se inicia una transacción de pago a nombre del usuario con base en una conversación de lenguaje natural y sin redirigir el usuario lejos de la sesión de comunicaciones. Adicionalmente, se puede suministrar un mensaje de inicio de pago desde el entorno de mensajería al usuario indicando que la transacción de pago ha sido iniciada.
El documento CO 11-82169 divulga un método para procesar de forma segura una transacción, en donde el método incluye almacenar una pluralidad de identificadores de instrumento de transacción financiera encriptados en una memoria en donde no hay clave de descifrado para estos almacenados en la memoria y además, en donde los identificadores de instrumento de transacción financiera están cada uno asociados con un dispositivo de comunicaciones móviles. El método también incluye recibir de un servidor una solicitud para procesar una transacción, retirar de la memoria el identificador de instrumento de transacción financiera asociado con el dispositivo de comunicaciones móviles, transmitir el identificador de instrumento de transacción financiera retirado al dispositivo de comunicaciones móviles, recibir en el dispositivo de comunicaciones móviles los datos de transacción, y usar los datos de transacción recibidos para llevar a cabo una transacción financiera.
De acuerdo a lo anterior, es claro que a pesar de la diversidad de oferta de productos y plataformas digitales móviles para la realización de transacciones en línea, actualmente es necesario que los usuarios todavía cuenten con una cuenta bancaria en un banco o institución financiera y que la transacción se realice a través una plataforma digital emitida por dicho banco o institución financiera o servicio que media la transacción.
Lo anterior constituye claramente una limitación significativa para los usuarios y para el desarrollo de nuevos medios de comercio electrónico, toda vez que se realizan etapas adicionales en los procesos de transacción financiera por internet. En consecuencia, existe la necesidad de proporcionar un sistema y un método que permite ejecutar transacciones en aplicaciones extemas a las bancarias de forma más ágil, versátil e inmediata que las que existen actualmente en el mercado, que a su vez mantienen todos los protocolos de seguridad que garantizan que la transacción sea totalmente segura de acuerdo con los estándares del banco o institución financiera. BREVE DESCRIPCIÓN DE LA DIVULGACIÓN
La presente divulgación describe un método y un sistema para autorizar a través de dispositivos computacionales una transacción entre un usuario emisor y un usuario receptor que están registrados previamente en una red social.
El método aquí divulgado comprende una etapa de almacenar unos datos de registro de cada usuario en una primera base de datos localizada en un primer servidor que está configurado para administrar una aplicación transaccional. En esta etapa el usuario emisor ingresa sus datos de registro a través de un primer dispositivo computacional configurado para ejecutar la aplicación transaccional y el usuario receptor ingresa sus datos de registro a través de un segundo dispositivo computacional configurado para ejecutar la aplicación transaccional, donde los dispositivos computacionales se conectan mediante una red de comunicaciones con el primer servidor.
Además, el método incluye una etapa de generar mediante el primer servidor un perfil de emisor y un perfil de receptor para la aplicación transaccional, donde la etapa de generación de perfiles incluye asociar los datos de registro del usuario emisor de la etapa de almacenamiento con unos datos de perfil de la red social del usuario emisor. Además, esta etapa de generación de perfiles incluye asociar los datos de registro del usuario receptor del paso de almacenamiento con unos datos de perfil de la red social del usuario receptor; y crear a partir de los datos de registro y los datos de perfil de la red social del usuario emisor un perfil de emisor, y a partir de los datos de registro y los datos de perfil de la red social del usuario receptor un perfil de receptor. Los perfiles de emisor y receptor se almacenan en la primera base de datos. Además, el primer servidor solicita los datos de perfil de la red social a un segundo servidor que está configurado para administrar la red social.
Asimismo, el método tiene una etapa de detectar a través del segundo servidor una etiqueta que ingresa el usuario emisor en una publicación hecha por el usuario receptor dentro de la red social. La detección de la etiqueta genera que el segundo servidor se comunique con el primer servidor para que dicho primer servidor ejecute la aplicación transaccional en el dispositivo computacional del usuario emisor. También, el método incluye una etapa de validar mediante el primer servidor si los usuarios tienen perfiles de emisor y receptor guardados en la primera base de datos; y una etapa de generar unos primeros datos de autorización para autorizar la transacción entre el usuario emisor y el usuario receptor. La generación de los primeros datos de autorización comprende ejecutar mediante el primer servidor la aplicación transaccional en el dispositivo computacional del usuario emisor solicitando al usuario emisor ingresar un patrón en el dispositivo computacional; y comparar en un tercer servidor el patrón con un patrón base que está almacenado en una segunda base de datos de un tercer servidor y comparar el tiempo en el que el usuario emisor introduce el patrón contra un tiempo de referencia almacenado en la segunda base de datos. El tercer servidor genera los primeros datos de autorización y los envía a un cuarto servidor cuando los patrones coinciden y el tiempo en el que el usuario emisor ingresa el patrón coincide con el tiempo de referencia almacenado en la segunda base de datos.
Asimismo, el método tiene una etapa de autorizar mediante el cuarto servidor la transacción entre el usuario emisor y el usuario receptor, donde el cuarto servidor notifica al primer servidor que la transacción es autorizada.
Uno de los objetivos del método aquí divulgado es autorizar transacciones entre un usuario emisor y un usuario receptor en redes sociales a través de dispositivos computacionales.
Particularmente, el método aquí divulgado puede autorizar una transacción, como una compra o transferencia de bienes, entre usuarios que estén registrados en una aplicación transaccional, donde un usuario emisor ingresa una etiqueta en una publicación hecha por el usuario receptor en la red social. De acuerdo con lo anterior, el usuario emisor puede participar en la transacción sin salir de la red social, e interactuado con la aplicación transaccional desde su dispositivo computacional al momento de ingresar un patrón en un tiempo determinado.
Otro de los objetivos del método aquí divulgado es reducir el tiempo que invierte un usuario emisor en una transacción, desde que manifiesta su intención de hacer la transacción hasta que es autorizada. Particularmente, cuando el usuario emisor quiere hacer una transacción como una compra o transferencia de bienes, el método aquí divulgado está dirigido a reducir el número de interacciones que hace el usuario, por ejemplo, en el caso que debe llenar formularios, usar pasarelas de pago, ser redireccionado a otros portales web o aplicaciones.
En el método aquí divulgado el usuario emisor ingresa en la red social una etiqueta en una publicación hecha por el usuario receptor, lo cual genera que se ejecute la aplicación transaccional en el dispositivo computacional del usuario emisor solicitándole que ingrese el patrón en un tiempo determinado, el cual posteriormente es comparado con un patrón base y con un tiempo de referencia almacenado en el tercer servidor. Cuando los patrones y tiempos coinciden, se autoriza la transacción. De acuerdo con lo anterior, el usuario percibe que el tiempo que invierte en la transacción es mucho menor al que usaría si tuviera que interactuar con pasarelas de pago, páginas web, formularios, llamadas de autorización, ingreso de claves enviadas por notificaciones, SMS, o e-mail, y otros métodos de autenticación y autorización divulgados en el estado de la técnica.
En algunas realizaciones del método aquí divulgado, el tercer servidor ejecuta un motor de riesgo configurado para medir y comparar el tiempo en el que el usuario emisor introduce el patrón contra un tiempo de referencia almacenado en la segunda base de datos, y donde el motor de riesgo genera los primeros datos de autorización cuando el patrón coincide con el patrón base y se ingresa en el tiempo de referencia.
Asimismo, en algunas realizaciones del método aquí divulgado, la aplicación transaccional el usuario receptor tiene además de su perfil de receptor un perfil de emisor guardado en la primera base de datos. Lo anterior permite tener una única aplicación transaccional para usuarios emisores y usuarios receptores, en vez de tener variaciones de la aplicación transaccional para cada perfil. Además, esto permite que el usuario receptor también pueda iniciar el método de autorización al ingresar la etiqueta en una publicación de otro usuario receptor, sin necesidad de tener que crear un nuevo perfil de emisor.
En cualquiera de las realizaciones del método aquí divulgado, la etapa de almacenar los datos de registro de cada usuario en la primera base de datos localizada puede además incluir una subetapa de abrir un producto financiero relacionado con el usuario emisor a través de la aplicación transaccional, donde la aplicación transaccional se comunica a través del primer servidor con un el cuarto servidor configurado para otorgar dicho producto financiero. Opcionalmente, en la etapa de generar unos primeros datos de autorización el cuarto servidor puede verificar que el producto financiero cumpla con unos requisitos de aceptación, donde en la verificación del producto financiero el tercer servidor se comunica con el cuarto servidor y le solicita unos datos financieros que son posteriormente analizados a través el motor de riesgo para determinar si el producto financiero cumple con los requisitos de aceptación.
Adicionalmente, en cualquiera de las realizaciones del método aquí divulgado, los datos de registro de cada usuario pueden seleccionarse entre nombres, apellidos, número de celular, correo electrónico, número de documento de identidad y su fecha de expedición, otros datos correspondientes a información personal conocidos por una persona medianamente versada en la materia y combinaciones de los anteriores.
Asimismo, en cualquiera de las realizaciones del método aquí divulgado, la etapa de comparar en un tercer servidor el patrón con un patrón base que está almacenado en una segunda base de datos de un tercer servidor y comparar el tiempo en el que el usuario emisor introduce el patrón contra un tiempo de referencia almacenado en la segunda base de datos, el método puede ejecutar un motor de riesgo que tiene un componente de aprendizaje computacional o machine leaming.
El componente de aprendizaje computacional o machine leaming incluye solicitar al primer servidor unos datos de historial de intercambio del usuario emisor; solicitar al segundo servidor unos datos de interacción social del usuario emisor; y comparar en el tercer servidor los datos de historial de intercambio y datos de interacción social del usuario emisor con unos datos de distinción relacionados con la publicación del usuario receptor, donde el tercer servidor genera unos segundos datos de autorización que envía al primer servidor.
De acuerdo con lo anterior, la etapa del método de autorizar la transacción, se reciben los segundos datos de autorización antes de autorizar a través del primer servidor en la aplicación transaccional la transacción entre el usuario emisor y el usuario receptor. Una de las ventajas de estas realizaciones del método es que se tienen en cuenta los datos de historial de intercambio y datos de interacción social del usuario emisor, los cual permite tener una capa de seguridad que relaciona el tipo de transacción que se quiere autorizar con unos hábitos de interacción del usuario emisor en la red social.
Por ejemplo, si la transacción es una compra de un producto, estas realizaciones del método comparan unas características propias del producto, como precio, tipo de producto, localización del usuario receptor (datos de distinción); características del perfil del usuario, como páginas favoritas, publicaciones relacionadas con el tipo de producto, preferencias en contenido audiovisual y bibliográfico entre el usuario receptor y el usuario emisor, distancia geográfica entre los usuarios receptor y emisor (datos de interacción social), y características de hábitos de compra, por ejemplo, valor máximo de transacción, moneda utilizada, plazos de pago utilizados, número de productos o servicios adquiridos (datos de historial de intercambio).
Adicionalmente, en algunas realizaciones del método, el motor de riesgo además incluye enviar un primer conjunto de datos asociados al patrón los cuales se generan cuando el usuario emisor ingresa el patrón en la aplicación transaccional desde el dispositivo computacional, donde el primer conjunto de datos se envía a un elemento llamado Event Hub localizado en el cuarto servidor.
También, el motor de riesgo incluye analizar y comparar el primer conjunto de datos contra el patrón base mediante en un elemento llamado Stream Analytics-Real Time, donde el patrón base está guardado en el tercer servidor; y enviar el primer conjunto de datos analizado y comparado desde el elemento Stream Analytics-Real Time a un elemento llamado Data Factory y a un elemento llamado DB-Fraud Detection Results SQF para almacenar dicho conjunto de datos si el patrón coincide con el patrón base.
Además, el motor de riesgo puede incluir enviar el primer conjunto de datos analizado y comparado desde el elemento Data Factory hacia un componente de aprendizaje computacional llamado Machine Feaming.
Mediante el componente de aprendizaje computacional llamado Machine Feaming se puede decidir si la transacción entre el usuario emisor y el usuario receptor es rechazada, aceptada o rechazada/aceptada, donde el componente de aprendizaje computacional llamado Machine Leaming genera los primeros datos de autorización cuando la transacción es aceptada, donde el componente de aprendizaje computacional llamado Machine Leaming envía los datos de autorización al elemento DB-Fraud Detection Results SQL para almacenarlos, y donde el tercer servidor consulta en el elemento DB-Fraud Detection Results SQL los primeros datos de autorización para enviarlos al primer servidor cuando la transacción es autorizada.
Adicionalmente, en cualquiera de las realizaciones del método, la aplicación transaccional puede estar configurada para permitir al usuario receptor gestionar desde su dispositivo computacional un inventario de productos o servicios relacionando cada producto o servicio con un enlace directo que se publica en la red social, donde la gestión de inventario incluye agregar, eliminar o modificar los productos o servicios publicados.
Asimismo, en cualquiera de las realizaciones del método la etapa de detección de la etiqueta puede además incluir una subetapa de ejecutar un servicio de enlazamiento (webhook, en inglés) administrado por el segundo servidor. El servicio de enlazamiento se ejecuta permanentemente para detectar cuando el usuario emisor ingresa la etiqueta en la publicación hecha por el usuario receptor dentro de la red social. Además, el servicio de enlazamiento genera una orden para el segundo servidor cuando detecta la etiqueta, la orden configurada para generar que el segundo servidor se comunique con el primer servidor para que dicho primer servidor ejecute la aplicación transaccional en el dispositivo computacional del usuario emisor.
Por otro lado, el sistema para autorizar a través de dispositivos computacionales una transacción entre un usuario emisor y un usuario receptor que están registrados previamente en la red social, comprende un primer dispositivo computacional de un usuario emisor configurado para ejecutar una aplicación transaccional; un segundo dispositivo computacional de un usuario receptor configurado para ejecutar la aplicación transaccional.
También, el sistema incluye un primer servidor conectado mediante una red de comunicaciones con los dispositivos computacionales y configurado para administrar la aplicación transaccional, guardar una primera base de datos que incluye unos datos de registro del usuario emisor y unos datos de registro del usuario receptor y generar unos perfiles de emisor y receptor de dichos usuarios a partir de la asociación de los datos de registro de los usuarios con unos datos de perfil de la red social solicitado que le solicita el primer servidor a un segundo servidor.
Adicionalmente, el primer servidor está configurado para guardar los perfiles de emisor y receptor de dichos usuarios; validar si el usuario emisor y el usuario receptor tienen perfiles de emisor y receptor guardados en la primera base de datos cuando el segundo servidor detecta una etiqueta; solicitar al usuario emisor el ingreso de un patrón en la aplicación transaccional que se ejecuta en el dispositivo computacional; recibir desde un tercer servidor unos datos de autorización.
Por su parte, el segundo servidor está conectado mediante la red de comunicaciones al primer servidor y está configurado para administrar la red social; detectar la etiqueta, donde la etiqueta la ingresa el usuario emisor en una publicación hecha por el usuario receptor dentro de la red social. La detección de la etiqueta genera que el segundo servidor se comunique con el primer servidor para que dicho primer servidor ejecute la aplicación transaccional instalada en el dispositivo computacional del usuario emisor.
Asimismo, el sistema incluye un tercer servidor conectado mediante la red de comunicaciones a los servidores. El tercer servidor está configurado para medir y comparar el tiempo en el que el usuario emisor introduce el patrón contra un tiempo de referencia almacenado en la segunda base de datos.
En algunas modalidades del método, el tercer servidor y el segundo servidor pueden ser un mismo servidor, o pueden pertenecer a una granja o cluster de servidores. En este caso, el servidor o granja de servidores tiene un primer módulo y un segundo módulo, donde el primer módulo se configura para ejecutar las acciones que ejecuta el segundo servidor en otras modalidades del método, y donde el segundo módulo se configura para ejecutar las acciones que ejecuta el tercer servidor en otras modalidades del método.
También, el sistema incluye un cuarto servidor configurado para autorizar la transacción entre el usuario emisor y el usuario receptor, donde el cuarto servidor notifica al primer servidor que la transacción es autorizada; y donde el tercer servidor genera los primeros datos de autorización y los envía al cuarto servidor cuando los patrones coinciden.
El sistema anteriormente descrito está configurado para ejecutar cualquiera de las realizaciones del método descritas al inicio de esta sección de Capítulo Descriptivo.
Ahora se describirán realizaciones del método y sistemas aquí divulgados, solo a modo de ejemplo, con referencia a las figuras que brevemente se describen a continuación.
BREVE DESCRIPCIÓN DE LAS FIGURAS
Se proporcionará una descripción más particular haciendo referencia a realizaciones ejemplares que se ilustran en las figuras adjuntas, entendiendo que estas figuras representan realizaciones ejemplares y no limitan el alcance de esta divulgación. Las realizaciones ejemplares se describirán y explicarán con especificidad y detalle adicionales mediante el uso de las figuras que se describen brevemente a continuación:
Figura No.l. Muestra un diagrama de flujo que expone la secuencia lógica del conjunto de órdenes, pasos o etapas técnicas que integran una modalidad del método divulgado y que a su vez se integra con una modalidad del sistema divulgado, para autorizar transacciones en redes sociales.
Figura No.2. Muestra un diagrama general que expone algunos de los elementos técnicos junto con su respectiva interacción que forman parte de una modalidad del sistema y el método divulgados.
Figura No.3. Muestra un diagrama del proceso funcional de una modalidad de una aplicación transaccional donde un usuario emisor/comprador realiza una transacción; asimismo en esta figura No.3 se ilustra el diagrama los elementos técnicos junto con su respectiva interacción y de una modalidad del sistema y el método divulgados.
Figura No.4. Muestra un diagrama del proceso funcional de una modalidad de un motor de riesgo junto con todos sus elementos técnicos tangibles e intangibles y su respectiva interacción que se lleva a cabo dentro de una modalidad del método y el sistema divulgados.
DESCRIPCIÓN DETALLADA
Ahora se hará referencia en detalle a varias realizaciones. Cada ejemplo se proporciona a modo de explicación y no pretende ser una limitación y no constituye una definición de todas las realizaciones posibles
Uno de los objetivos del método aquí divulgado es autorizar transacciones entre un usuario emisor (100C) y un usuario receptor (100V) en redes sociales a través de dispositivos computacionales (300C, 300V).
Particularmente, en algunas realizaciones del método aquí divulgado se permite autorizar una transacción, como una compra o transferencia de bienes, entre usuarios que estén registrados en una aplicación transaccional (200), donde un usuario emisor (100C) ingresa una etiqueta en una publicación hecha por el usuario receptor en la red social (RD). De acuerdo con lo anterior, el usuario emisor (100C) puede participar en la transacción sin salir de la red social (RD), e interactuado con la aplicación transaccional (200) desde su dispositivo computacional al momento de ingresar un patrón en un tiempo determinado.
Por ejemplo, en el método aquí divulgado puede ser implementado en la autorización de una transacción que involucre una transferencia de dinero entre dos usuarios (100C, 100V) permitiendo mover o transferir los fondos de una cuenta de un usuario emisor a una cuenta de un usuario emisor/comprador (100C) mediante interacciones en una red social (RD) de manera segura, sin necesidad de aplicaciones o elementos adicionales requeridos por un banco o entidad financiera, todo en tiempo real sin que el usuario final lo note o tenga retrasos considerables.
Otro de los objetivos del método aquí divulgado es reducir el tiempo que invierte un usuario emisor (100C) en una transacción, desde que manifiesta su intención de hacer la transacción hasta que es autorizada. Particularmente, cuando el usuario emisor (100C) está quiere hacer una transacción como una compra o transferencia de bienes, el método aquí divulgado está dirigido a reducir el número de interacciones que hace el usuario, por ejemplo, en el caso que debe llenar formularios, usar pasarelas de pago, ser redireccionado a otros portales web o aplicaciones. En el método aquí divulgado el usuario emisor (100C) ingresa en la red social (RD) una etiqueta en una publicación hecha por el usuario receptor, lo cual genera que se ejecute la aplicación transaccional (200) en el dispositivo computacional del usuario emisor (100C) solicitándole que ingrese el patrón en un tiempo determinado, el cual posteriormente es comparado con un patrón base y con un tiempo de referencia almacenado en el tercer servidor (403). Cuando los patrones y tiempos coinciden, se autoriza la transacción. De acuerdo con lo anterior, el usuario percibe que el tiempo que invierte en la transacción es mucho menor al que usaría si tuviera que interactuar con pasarelas de pago, páginas web, formularios, llamadas de autorización, ingreso de claves enviadas por notificaciones, SMS, o e-mail, y otros métodos de autenticación y autorización divulgados en el estado de la técnica.
En algunas de las realizaciones del método divulgado, el método permite realizar una transacción financiera fácil, segura e inmediata en tiempo real a través de una aplicación de una red social (RD) extema a la aplicación bancaria, empleando comandos marcados con etiquetas predefinidas, que toma información necesaria tanto del emisor como del receptor de la transacción generando la validación y autorización de la transacción a través de una aplicación, que puede ser una aplicación web progresiva no nativa o una aplicación nativa convencional, esto se hace mediante la integración y la combinación de varios elementos (dispositivos móviles tales como un teléfono móvil, una tableta, o cualquier otro dispositivo con acceso a internet, un computador u otro dispositivo electrónico con elementos de comunicación que tenga acceso a internet ubicados en otro lugar) que hacen parte del sistema (hardware) que junto con el método permiten optimizar la validación de la identidad del usuario, manteniendo todos los protocolos de seguridad que a su vez garantizan que la transacción sea totalmente segura de acuerdo con los estándares del banco o institución financiera, en donde el sistema es la parte tangible que permite realizar el método para efectuar una transacción segura, fácil e inmediata, mediante el empleo de redes sociales.
Por ejemplo, en varias modalidades del sistema y método aquí divulgados, se realizan transacciones fáciles y seguras en redes sociales para dispositivos móviles tales como un teléfono móvil, una tableta, o cualquier otro dispositivo con acceso a internet el cual hacen parte del sistema, asimismo, mediante elementos técnicos tales como un computador u otro dispositivo electrónico con elementos de comunicación que tenga acceso a internet que se encuentran ubicados en otro lugar y que a su vez hacen parte del mismo sistema, reciben, procesan, transforman, y/o emiten datos en donde se lleva a cabo el método para realizar una transacción financiera fácil, segura e inmediata por medio de redes sociales a partir de comandos marcados con etiquetas predefinidas, que toma información necesaria tanto del emisor como del receptor de la transacción y genera la validación y autorización de la transacción a través de una aplicación, que puede ser una aplicación web progresiva no nativa o una aplicación nativa convencional, en donde el sistema es la parte tangible que permite realizar el método para efectuar una transacción segura, fácil e inmediata mediante el empleo de redes sociales.
Adicionalmente, en varias modalidades del sistema y método aquí divulgados, se puede autorizar una transacción segura por medio de redes sociales mediante la invocación de un comando específico y la implementación de un patrón de seguridad, en donde el método se lleva a cabo en el sistema, en donde el sistema se compone de elementos técnicos tales como un computador, teléfono móvil, tableta, o cualquier otro dispositivo con acceso a internet o similar el cual se pueden encontrar ubicados en diferentes lugares, asimismo está en algunas modalidades del método y el sistema divulgados, a partir de comandos marcados con etiquetas predefinidas, que toma información necesaria tanto del emisor como del receptor de la transacción, genera la validación y autorización de la transacción a través de una aplicación transaccional (200), que puede ser una aplicación web progresiva (PWA por sus siglas en inglés) no nativa o una aplicación nativa convencional para validar la identidad del usuario, manteniendo los protocolos de seguridad para garantizar que la transacción sea totalmente segura de acuerdo con los estándares del banco o entidad financiera, esto se lleva a cabo mediante la comunicación entre dispositivos de comunicación electrónicos tales como teléfonos celulares, tablets, computadores, pe portátiles entre otros.
Con base a lo anterior, la presente divulgación describe modalidades de un sistema (S) y un método (M), que pueden efectuar transacciones fáciles y seguras en redes sociales para dispositivos móviles, que se conforma de un conjunto de ordenes o pasos o etapas técnicas (a, b, c, d, e, f, g, 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A) que integran el método (M) junto con elementos técnicos (300, 301, 310, 400) que conforman todo el sistema (S), en donde el sistema (S) es la parte tangible que permite realizar el método (M) para efectuar una transacción segura, fácil e inmediata, mediante el empleo de redes sociales (RD). (Ver figuras No.l, No.2, No.3 y No.4). En algunas de las realizaciones del método (M), dicho método se compone de un conjunto de órdenes, pasos, etapas técnicas o componentes lógicos necesarios para realizar una transacción financiera fácil, segura e inmediata en tiempo real a través de una aplicación de una red social (RD) extema a la aplicación bancaria, empleando comandos marcados con etiquetas predefinidas, que toma información necesaria tanto de un emisor como de un receptor de la transacción generando la validación y autorización de la transacción a través de una aplicación, que puede ser una aplicación web progresiva no nativa o una aplicación nativa convencional, esto se hace mediante la integración y la combinación de varios elementos técnicos tangibles que conforman y hacen parte del sistema (S) o (hardware) que junto con el método (M) permiten optimizar la validación de la identidad del usuario, manteniendo todos los protocolos de seguridad que a su vez garantizan que la transacción sea totalmente segura de acuerdo con los estándares del banco o institución financiera, en donde el sistema (S) es la parte tangible que permite realizar el método (M) para efectuar una transacción segura, fácil e inmediata, mediante el empleo de redes sociales; a continuación se expone la secuencia lógica del conjunto de órdenes, pasos o etapas técnicas que integran el método (M) y que a su vez se integra con el sistema (S), la cual se está ilustra de la siguiente manera:
Secuencia lógica de las órdenes, pasos o etapas técnicas que integran el método (M).
Proceso No.l a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) Si
g) Eres vendedor
h) ¿Vender un producto? i) Si
j) Publicar Producto (Red social (RD))
k) Fin
Proceso No.lA a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) Si
g) Eres vendedor
h) ¿Vender un producto?
i) No
j) Se devuelve a la opción ¿Agregar Negocio (Red social (RD))?
Proceso No.lB a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) No n) Activar notificaciones (Navegador)
o) Iniciar sesión (Navegador)
Proceso No.lC a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres comprador
h) ¿comprar un producto?
i) No
j) Se devuelve a la opción ¿Agregar Negocio (Red social (RD))?
Proceso No.lD a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600) ¿Cumple validaciones?
o) Si p) PATRON ¿cumple validaciones?
q) Si
r) CORE BANCARIO (1100) ¿cumple validaciones? s) Si
t) Producto comprado (transacción exitosa) u) Fin
Proceso No.lE a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))? f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones? o) No
p) Producto No comprado (transacción Rechazada) q) Se devuelve a Iniciar sesión (navegador)
Proceso No.lF a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))? f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600) ¿Cumple validaciones? o) Si
p) PATRON ¿cumple validaciones?
q) No
r) Producto No comprado (transacción Rechazada) s) Se devuelve a Iniciar sesión (navegador)
Proceso No.lG a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))? f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones? o) Si
p) PATRON ¿cumple validaciones?
q) Si r) CORE BANCARIO (1100) ¿cumple validaciones?
s) No
t) Producto No comprado (transacción Rechazada)
u) Se devuelve a Iniciar sesión (navegador)
Proceso No.2 a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) No
e) ¿Registrarse?
f) Si
g) ¿Iniciar sesión con Facebook?
h) Apertura producto (Core bancario (1100))
i) No
j) Se devuelve a ¿Registrarse?
Proceso No.2A a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) No
e) ¿Registrarse?
f) No
g) Se devuelve a Iniciar sesión (navegador)
De acuerdo con lo anterior, a continuación, se describen realizaciones de cada uno de los procesos 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A:
Proceso No. 1. a) Ingresar a la aplicación b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Perfil Vendedor (Red social (RD))?
f) Si
g) ¿Vender un producto -?
h) Si - Información
i) Publicar Producto (Red social (RD))
j) Fin
Paso 1.a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones; Paso 1. b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso l.c Después de ingresar el usuario a la aplicación tranasaccional, se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va atener que registrarse o iniciar sesión. Paso l.d (SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), se continua con el paso l.e;
Paso Le se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociados a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda. El sistema de búsqueda identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene.
La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cual de estos perfiles es su perfil de vendedor;
Paso 1J (SI) si el usuario acepta agregar un perfil de vendedor el usuario selecciona cuál de los perfiles que aparecen en la interfaz de la red social (RD) corresponde a su perfil de usuario de vendedor, al seleccionar el perfil se almacenan estos datos de perfil en una base de datos localizada en el primer servidor.
Paso l.g En el caso en que el usuario si hubiera agregado un perfil del vendedor a través de una interfaz se procede a preguntarle al usuario si desea vender productos;
Paso l.h si el usuario acepta se procede a solicitar la información de los productos por lo cual se le solicita al usuario dar información como puede ser la cantidad el nombre etc, a la aplicación transaccional (200) para guardar esta información en una base de datos localizada en el primer servidor (400).
Paso l.i Se procede a que el usuario de la aprobación de publicar el producto en la red social (RD).
Proceso No.1A a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Perfil Vendedor (Red social (RD))?
f) Si -Información
g) ¿Vender un producto? No
Se devuelve a la opción ¿Agregar Negocio (Red social (RD))?
Paso la. a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso la.b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso la.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso la.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), se pasa al paso la.e;
Paso la.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cual de estos perfiles es su perfil de vendedor
Paso la.f(SI) si el usuario acepta agregar un perfil de vendedor el usuario selecciona cual de los perfiles que aparecen en la interfaz de la red social (RD) corresponde a su perfil de usuario de vendedor, al seleccionar el perfil se almacenan estos datos de perfil en una base de datos localizada en el primer servidor (400);
Paso la.g En el caso en que el usuario si hubiera agregado un perfil del vendedor a través de una interfaz se procede a preguntarle al usuario si desea vender productos
Paso la.h (NO) En el caso en que el usuario no quiera agregar productos para la venta vuelve a la interfaz de agregar perfil vendedor.
Paso la. i Si el usuario no aceptó agregar información acerca de sus productos la aplicación transaccional (200) le mostrará la primera interfaz de registro de vendedor.
Proceso No. IB a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) No
n) Activar notificaciones (Navegador)
o) Iniciar sesión (Navegador) Paso Ib. a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso lb.b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso lb.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso lb.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), se pasa el paso lb.e;
Paso lb.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cual de estos perfiles es su perfil de vendedor
Paso lb.f (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador. Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso lb.g (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional (200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400). Al finalizar el registro se activa inmediatamente en el segundo servidor (402) de la red social (RD) un sistema de webhook el cual identifica alguna actividad que se registre por parte de cualquier usuario, ya sea un usuario receptor/vendedor (100V) o un usuario emisor/comprador (100C) en una red social (RD);
Paso lb.h-i(SI) Cuando un usuario emisor/comprador decide realizar una compra a través de la aplicación transaccional (200) se procede con el paso l.b.j
Paso l.b.j el usuario ingresa a cualquier red social (RD) de su preferencia;
Paso l.hk realiza un comentario en la publicación del producto que desea comprar del usuario receptor/vendedor (100V) este usuario vendedor debe estar registrado en la aplicación transaccional (200) y estar registrado en la base de datos del primer servidor (400) de la aplicación transaccional (200), el sistema de alerta que se activó en el momento de registro denominado WEBHOOK identifica una interacción en los perfiles que están almacenados en la base de datos del primer servidor (400) e informa esta actividad al primer servidor (400)
Paso l.b.l (SI) El usuario emisor/comprador recibe una notificación en el dispositivo electrónico de aprobación de la compra esta notificación llega a través de la aplicación transaccional (200) y se refleja en el dispositivo en cualquiera de las formas de notificación que el dispositivo electrónico maneje
Paso l.b.m (NO) Si el usuario emisor/comprador no recibe la notificación, se pasa al paso l.b.n; Paso l.b.n En el caso en que no reciba la notificación el usuario debe ingresar al menú de control de su dispositivo electrónico y aprobar las notificaciones de la aplicación transaccional (200), y se pasa al paso l.b.0;
Paso lb.o Se regresa al paso l.b.b.
Proceso No.1C a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres emisor/comprador
h) ¿comprar un producto?
i) No
j) Se devuelve a la opción ¿Agregar Negocio (Red social (RD))?
Paso lc.a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso lc.b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso lc.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso lc.d (SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), entonces se pasa al paso l.c.e; Paso lc.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cuál de estos perfiles es su perfil de vendedor;
Paso lc.f (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador. Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso lc.g (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional (200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400);
Paso l.c.h se solicita al usuario indicar si desea comprar un producto;
Paso lc.l (NO) En el caso de que el usuario no desee comprar ningún producto la aplicación transaccional (200) lo devuelve a la interfaz inicial, por ejemplo al paso l.c.e, o al paso /. c. b.
Proceso No. ID a) Ingresar a la aplicación b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres emisor/comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones?
o) Si
p) PATRON ¿cumple validaciones?
q) Si
r) CORE BANCARIO (1100) ¿cumple validaciones?
s) Si
t) Producto comprado (transacción exitosa)
u) Fin
Paso Id. a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones
Paso Id. b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción. Paso ld.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso ld.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), entonces se pasa al paso ld.e;
Paso ld.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cual de estos perfiles es su perfil de vendedor;
Paso Id.f(SI) si el usuario acepta agregar un perfil de vendedor el usuario selecciona cual de los perfiles que aparecen en la interfaz de la red social (RD) corresponde a su perfil de usuario de vendedor, al seleccionar el perfil se almacenan estos datos de perfil en una base de datos localizada en el primer servidor (400);
Paso ldg En el caso en que el usuario si hubiera agregado un perfil del vendedor a través de una interfaz se procede a preguntarle al usuario si desea vender productos;
Paso ldh (SI) si el usuario acepta se procede a solicitar la información de los productos por lo cual se le solicita al usuario dar información como puede ser la cantidad, el nombre etc, a la aplicación transaccional (200) para guardar esta información en una base de datos localizada en el primer servidor (400).
Paso Idi Se procede a que el usuario dé la aprobación de publicar el producto en la red social (RD);
Paso ldh (NO) En el caso en que el usuario no quiera agregar productos para la venta vuelve al paso ld.e).
Paso ldJ (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador. Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso l l.j (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional
(200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400);
Paso ld.j (NO) En caso de que el usuario no desee registrar ningún perfil de emisor/comprador y hubiera registrado un perfil de vendedor el usuario finaliza su proceso de inscripción en la aplicación transaccional (200).
Al finalizar el registro se activa inmediatamente en el segundo servidor (402) de la red social (RD) un sistema de webhook el cual identifica alguna actividad que se registre por parte de cualquier usuario, ya sea un usuario receptor/vendedor (100V) o un usuario emisor/comprador (100C) en una red social (RD)
Paso líik (NO) (NO) Si el usuario no acepto registró ningún perfil tanto de vendedor como del emisor/comprador la aplicación transaccional (200) le mostrará la primera interfaz de registro de vendedor ya que la aplicación transaccional (200) requiere de al menos de uno de los dos perfiles para poder continuar con la operación.
Paso Id.l(Sí) Un usuario emisor/comprador decide realizar una compra a través de la aplicación transaccional (200).
Paso ld.l (NO) En el caso de que el usuario no desee comprar ningún producto la aplicación transaccional (200) lo devuelve a la interfaz inicial;
Paso ld.m ingresa a cualquier red social (RD) de su preferencia, y se pasa al paso l.d.n;
Paso ld.n el usuario realiza un comentario en la publicación del producto que desea comprar del usuario receptor/vendedor (100V) este usuario receptor/vendedor (100V) debe estar registrado en la aplicación transaccional (200) y estar registrado en la base de datos del primer servidor (400) de la aplicación transaccional (200), el sistema de alerta que se activó en el momento de registro denominado WEBHOOK identifica una interacción en los perfiles que están almacenados en la base de datos del primer servidor (400) e informa esta actividad al primer servidor (400); Paso líl.ñ (SI) El usuario emisor/comprador recibe una notificación en el dispositivo electrónico de aprobación de la compra esta notificación llega a través de la aplicación transaccional (200) y se refleja en el dispositivo en cualquiera de las formas de notificación que el dispositivo electrónico maneje.
Paso líl.ñ (NO) En el caso en que no reciba la notificación el usuario debe ingresar al menú de control de su dispositivo electrónico y aprobar las notificaciones de la aplicación transaccional (200).
Paso lJo (SI) La aplicación transaccional (200) a través de una interfaz le solicita al usuario ingresar el patrón de validación de transacción si el usuario acepta y diligencia el patrón, estos datos de validación se guardan en el primer servidor (400) de datos y se envían al tercer servidor (403).
Paso lJo (No) En caso de que el usuario no ingrese el patrón de validación la aplicación dará como rechazada la transacción.
Paso ld.p (SI) En el tercer servidor (403) de datos se verifica que la transacción es normal y que el usuario emisor/comprador que la está solicitando es él. Este paso se puede efectuar a través de diferentes herramientas como lo son Stream Analytics, un servicio de AZURE® (MICROSOFT®); un servicio de análisis en tiempo real, por ejemplo el servicio de Event Hub, el cual es un servicio de ingesta de datos en tiempo real totalmente administrado también de AZURE® y un módulo de detección de fraude tipo SQL la cual es una base de datos donde se almacena toda la información del análisis previo de las transacciones realizadas por el usuario emisor.
Paso lcLp (No) En caso de que el Motor de riesgo (600)identifique que no hay las suficientes garantías para aprobar la transacción la aplicación transaccional (200) cancela la transacción y devuelve
Figure imgf000036_0001
usuario emisor/comprador (100C) al paso ld.b;
Paso ld.q (SI) Los datos enviados del patrón y almacenados en el tercer servidor (403) se comparan con los datos del registro de usuario y basándose en ciertas variables como lo son el tiempo de ejecución del patrón y la velocidad de ingreso del patrón se comparan con estos mismos índices del momento del registra y se valida la identidad del usuario.
Paso ld.q (NO) Si los datos enviados del patrón y almacenados en el tercer servidor (403) no corresponden con los datos del momento del registro la aplicación transaccional (200), se cancela la transacción y devuelve el usuario emisor/comprador (100C) a la interfaz inicial del paso ld.b.
Paso ld.r (SI) En el caso en que se pasaron los dos sistemas de validación anteriores se pasa a la validación por parte del core bancario (1100) el cual se encuentra en el cuarto servidor (404), donde se identifica en los productos financieros que sí existan las personas que solicitan la transacción, también que existan los suficientes fondos para ejercer la transacción y de ser así se procede con la transacción.
Paso ld.r (NO) En caso de que la validación por parte del core bancario (1100) no sea exitosa la aplicación transaccional (200) cancela la transacción y devuelve el usuario emisor/comprador (100C) a la interfaz inicial.
Paso ld.s fin de la transacción.
Proceso No.1E a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres emisor/comprador (100C)
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones?
o) No
p) Producto No comprado (transacción Rechazada)
q) Se devuelve a Iniciar sesión (navegador)
Paso le.a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso le.b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso le.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso le.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), entonces se pasa al paso le.e; Paso le.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cuál de estos perfiles es su perfil de vendedor;
Paso le.f (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador. Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso le.j (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional (200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400). Al finalizar el registro se activa inmediatamente en el segundo servidor (402) de la red social (RD) un sistema de webhook el cual identifica alguna actividad que se registre por parte de cualquier usuario, ya sea un usuario receptor/vendedor (100V) o un usuario emisor/comprador (100C) en una red social (RD);
Paso le.l(SI) Un usuario emisor/comprador decide realizar una compra a través de la aplicación transaccional (200);
Paso le.m ingresa a cualquier red social (RD) de su preferencia;
Paso le.n El usuario emisor/comprador realiza un comentario en la publicación del producto que desea comprar del usuario receptor/vendedor (100V) este usuario receptor/vendedor (100V) debe estar registrado en la aplicación transaccional (200) y estar registrado en la base de datos del primer servidor (400) de la aplicación transaccional (200), el sistema de alerta que se activó en el momento de registro denominado WEBHOOK identifica una interacción en los perfiles que están almacenados en la base de datos del primer servidor (400) e informa esta actividad al primer servidor (400);
Paso le. ñ (SI) El usuario emisor/comprador recibe una notificación en el dispositivo electrónico de aprobación de la compra esta notificación llega a través de la aplicación transaccional (200) y se refleja en el dispositivo en cualquiera de las formas de notificación que el dispositivo electrónico maneje.
Paso le.o (SI) La aplicación transaccional (200) a través de una interfaz le solicita al usuario emisor/comprador diligenciar el patrón de validación de transacción si el usuario acepta y diligencia el patrón, estos datos de validación se guardan en el primer servidor (400) de datos y se envían al tercer servidor (403).
Paso le.p (No) En caso de que el Motor de riesgo (600)identifique que no hay las suficientes garantías para aprobar la transacción la aplicación transaccional (200) cancela la transacción y devuelve el usuario emisor/comprador a la interfaz inicial del paso le.b. El Motor de riesgo (600)puede ser el mismo explicado en el proceso 1D.
Proceso No.1F a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))?
f) No
g) Eres emisor/comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador) m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones?
o) Si
p) PATRON ¿cumple validaciones?
Paso lf.a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso lfb el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso lf.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso lf.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), entonces, se pasa al paso lf.e
Paso lf.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cuál de estos perfiles es su perfil de vendedor; Paso lff (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso Ifj (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional (200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400) Al finalizar el registro se activa inmediatamente en el segundo servidor (402) de la red social (RD) un sistema de webhook el cual identifica alguna actividad que se registre por parte de cualquier usuario, ya sea un usuario receptor/vendedor (100V) o un usuario emisor/comprador (100C) en una red social (RD);
Paso lf.l(SI) Un usuario emisor/comprador decide realizar una compra a través de la aplicación transaccional (200);
Paso lf.m el usuario emisor/comprador ingresa a cualquier red social (RD) de su preferencia;
Paso lf.n el usuario emisor/comprador realiza un comentario en la publicación del producto que desea comprar del usuario receptor/vendedor (100V) este usuario receptor/vendedor (100V) debe estar registrado en la aplicación transaccional (200) y estar registrado en la base de datos del primer servidor (400) de la aplicación transaccional (200), el sistema de alerta que se activó en el momento de registro denominado WEBHOOK identifica una interacción en los perfiles que están almacenados en la base de datos del primer servidor (400) e informa esta actividad al primer servidor (400) Paso lf.ñ (SI) El usuario emisor/comprador recibe una notificación en el dispositivo electrónico de aprobación de la compra esta notificación llega a través de la aplicación transaccional (200) y se refleja en el dispositivo en cualquiera de las formas de notificación que el dispositivo electrónico maneje.
Paso lf.o (SI) La aplicación transaccional (200) a través de una interfaz le solicita al usuario diligenciar el patrón de validación de transacción si el usuario acepta y diligencia el patrón, estos datos de validación se guardan en el primer servidor (400) de datos y se envían al tercer servidor (403).
Paso lf.p (SI) En el tercer servidor (403) de datos se verifica que la transacción es normal y que el usuario emisor/comprador que la está solicitando es él. Este paso se puede efectuar a través de diferentes herramientas como lo son Stream Analytics, un servicio de AZURE® (MICROSOFT®); un servicio de análisis en tiempo real, por ejemplo, el servicio de Event Hub, el cual es un servicio de ingesta de datos en tiempo real totalmente administrado también de AZURE® y un módulo de detección de fraude tipo SQL la cual es una base de datos donde se almacena toda la información del análisis previo de las transacciones realizadas por el usuario emisor.
Paso lfq (NO) Si los datos enviados del patrón y almacenados en el tercer servidor (403) no corresponden con los datos del momento del registro la aplicación transaccional (200) cancela la transacción y devuelve el usuario emisor/comprador a la interfaz inicial del paso lf.b;. Proceso No.1 G a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) Si
e) ¿Agregar Negocio (Red social (RD))? f) No
g) Eres emisor/comprador
h) ¿comprar un producto?
i) Si
j) Ingrese a la Red social (RD)
k) Realizar comentario en el producto del vendedor
l) ¿Recibir notificación? (Navegador)
m) Autorizar transacción (patrón)
n) Motor de riesgo (600)¿ Cumple validaciones?
o) Si
p) PATRON ¿cumple validaciones?
q) Si
r) CORE BANCARIO (1100) ¿cumple validaciones?
s) No
t) Producto No comprado (transacción Rechazada)
u) Se devuelve a Iniciar sesión (navegador)
Paso lg.a El primer procedimiento es el ingreso a la aplicación transaccional (200) por parte de cualquier usuario a través de un dispositivo electrónico que tenga comunicación con una red de telecomunicaciones;
Paso Ig. b el usuario inicia sesión en la aplicación transaccional (200) a través de cualquier mecanismo en el cual se pueda ejecutar la aplicación transaccional (200). Por ejemplo, el usuario entra a la red social (RD) a través de un dispositivo computacional que está configurado para ejecutar la aplicación transacción.
Paso lg.c Después de ingresar el usuario se encuentra en una interfaz principal de la aplicación transaccional (200) en la cual el usuario va a tener que registrarse o iniciar sesión.
Paso lg.d(SI) Si el usuario se encuentra registrado en la base de datos del primer servidor (400), se pasa al paso lg.e; Paso Ig.e se procede a crear el perfil de vendedor en la aplicación transaccional (200) para ello el usuario agrega un perfil de alguna red social (RD), lo primera acción del usuario es iniciar sesión en la red social (RD) y a través de una interfaz de la aplicación transaccional (200) le muestra al usuario los diferentes perfiles que se encuentran asociadas a la cuenta con la cual se registró en la red social (RD) a través de un sistema de búsqueda, el cual identifica en las bases de datos de la red social (RD) ubicadas en el segundo servidor (402) el número de perfiles que el usuario tiene. La interfaz muestra al usuario los perfiles que se encuentran asociados a la red social (RD) y le da la opción de seleccionar cuál de estos perfiles es su perfil de vendedor
Paso lg.f (NO) Si el usuario no desea agregar un perfil de vendedor se procede a omitir este paso y seguir al registro de usuario del perfil emisor/comprador Una interfaz de la aplicación transaccional (200) le permite si el usuario acepta, agregar un perfil de emisor/comprador, como el usuario ya registró la red social (RD) en el paso anterior de agregar el perfil de vendedor, el sistema ya tiene identificado los perfiles de la red social (RD) que están asociados a la cuenta registrada en la red social (RD) por parte del usuario;
Paso lg.j (SI) se procede a seleccionar cuál de los perfiles el usuario determina como su perfil de emisor/comprador ante la aplicación transaccional (200) y se procede a almacenar este perfil en una base de datos localizada en el primer servidor (400) Al finalizar el registro se activa inmediatamente en el segundo servidor (402) de la red social (RD) un sistema de webhook el cual identifica alguna actividad que se registre por parte de cualquier usuario, ya sea un usuario receptor/vendedor (100V) o un usuario emisor/comprador (100C) en una red social (RD);
Paso lg.l(SI) Un usuario emisor/comprador decide realizar una compra a través de la aplicación transaccional (200); Paso lg.m el usuario emisor/comprador ingresa a cualquier red social (RD) de su preferencia y pasa al paso lg.n;
Paso lg.n el usuario emisor/comprador realiza un comentario en la publicación del producto que desea comprar del usuario receptor/vendedor (100V) este usuario receptor/vendedor (100V) debe estar registrado en la aplicación transaccional (200) y estar registrado en la base de datos del primer servidor (400) de la aplicación transaccional (200), el sistema de alerta que se activó en el momento de registro denominado WEBHOOK identifica una interacción en los perfiles que están almacenados en la base de datos del primer servidor (400) e informa esta actividad al primer servidor (400);
Paso Ig.ñ (SI) El usuario emisor/comprador recibe una notificación en el dispositivo electrónico de aprobación de la compra esta notificación llega a través de la aplicación transaccional (200) y se refleja en el dispositivo en cualquiera de las formas de notificación que el dispositivo electrónico maneje;
Paso Ig.o (SI) La aplicación transaccional (200) a través de una interfaz le solicita al usuario diligenciar el patrón de validación de transacción si el usuario acepta y diligencia el patrón, estos datos de validación se guardan en el primer servidor (400) de datos y se envían al tercer servidor (403).
Paso Ig.p (SI) En el tercer servidor (403) de datos se verifica que la transacción es normal y que el usuario emisor/comprador que la está solicitando es él. Este paso se puede efectuar a través de diferentes herramientas como lo son Stream Analytics, un servicio de AZURE® (MICROSOFT®); un servicio de análisis en tiempo real, por ejemplo el servicio de Event Hub, el cual es un servicio de ingesta de datos en tiempo real totalmente administrado también de AZURE® y un módulo de detección de fraude tipo SQL la cual es una base de datos donde se almacena toda la información del análisis previo de las transacciones realizadas por el usuario emisor. Paso lg.q (NO) Si los datos enviados del patrón y almacenados en el tercer servidor (403) no corresponden con los datos del momento del registro la aplicación transaccional (200) cancela la transacción y devuelve el usuario emisor/comprador a la interfaz inicial.
Paso lg.q(SI) Los datos enviados del patrón y almacenados en el tercer servidor (403) se comparan con los datos del registro de usuario y basándose en ciertas variables como lo son el tiempo de ejecución del patrón la velocidad entre puntos se comparan con estos mismos índices del momento del registra y se valida la identidad del usuario.
Paso lg.r (NO) En caso de que la validación por parte del core bancario (1100) no sea exitosa la aplicación transaccional (200) cancela la transacción y devuelve el usuario emisor/comprador a la interfaz inicial del paso lg.b.
Proceso No.2 a) Ingresar a la aplicación
b) Iniciar sesión (navegador)
c) ¿Está registrado?
d) No
e) ¿Registrarse?
f) Si
g) ¿Iniciar sesión con red social (RD)?
h) Apertura producto (Core bancario (1100))
i) No
j) Se devuelve a ¿Registrarse? La secuencia lógica del conjunto de órdenes, pasos o etapas técnicas ilustradas anteriormente componen los procesos 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A, el cual a su vez estos procesos 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A conforman todo el método (M) para realizar una transacción segura, fácil e inmediata, mediante el empleo de redes sociales, el cual se encuentra ilustrado en la figura No.1.
En la figura No.1 se ilustran cada una de las secuencias lógicas del conjunto de órdenes, pasos o etapas técnicas que conforman los procesos 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A, que a su vez conforman todo el método (M) para generar una transacción segura en redes sociales con aplicaciones no nativas o una aplicación nativa convencional en dispositivos móviles (300) o dispositivos computacionales (300C, 300V), dicho método (M) es ejecutado por un dispositivo electrónico con conexión a internet y que se comunican mediante una red de telecomunicaciones (310), donde este dispositivo electrónico puede corresponder, sin limitación, a un servidor, computador personal, computador portátil, tableta, teléfono móvil, y/o similares que hacen parte del sistema (S). (Ver figuras No.1, No.2, No.3 y No.4).
El método (M) para llevar acabo la secuencia lógica del conjunto de órdenes, pasos o etapas técnicas de los procesos 1, 1A, 1B, 1C, 1D, 1E, 1F, 1G, 2 y 2A comprende cada uno de los siguientes pasos o etapas técnicas que se describirán a continuación y que a su vez también se harán en sincronía mediante la integración y la configuración de varios elementos técnicos que conforman el sistema (S), así: a) Registrar (1) y almacenar (1.3, 2.4, 3.1) los datos de un usuario (100) que puede ser un usuario emisor/comprador (100C) únicamente o un usuario emisor/comprador (100C ) y al tiempo ser un usuario receptor/vendedor (100V), en una base de datos de una aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200) por sus siglas en inglés, en donde dicho registro (1) incluye la creación de un perfil para cada usuario (100) con los datos personales del mismo, iniciando sesión (2) en una red social (RD) donde se llevará a cabo la transacción y, a su vez, realizará la apertura (1.2) del producto financiero que va a estar relacionado con el usuario (100), en esta etapa de registro y almacenamiento en la base de datos de una aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200) se hace mediante un dispositivo móvil (300) que se encuentra conectado a internet y que a su vez se comunica con otro dispositivo electrónico en otro lugar como por ejemplo un primer servidor (400) o computador conectado a internet. (Ver figura No.2 y No.3). b) Asociar el nombre de usuario y datos de sesión de la red social (RD) con los datos del usuario (100), bien sea emisor/comprador (C) o vendedor (V), y el ID creado para la una aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200) que se encuentra en el dispositivo móvil (300) del usuario (100), este paso o etapa se hace mediante la red de telecomunicación (310) entre el dispositivo móvil (300) y el primer servidor (400) o computador conectado a internet. (Ver figuras No.2 y No.3). c) Monitorear y autenticar (1.1) por parte de la red social (RD) en los perfiles de un usuario receptor/vendedor (100V) y un usuario emisor/comprador (100C) por medio de un elemento en la arquitectura que permite la interacción entre las redes sociales (RD) y una aplicación transaccional (200), con el fin de poder determinar cuándo se invoque un comando o etiqueta específica (4) por parte del usuario emisor/comprador (100C) en la publicación (3) del usuario receptor/vendedor (100V) para así determinar, cuándo se desea realizar una transacción (por ejemplo, una compra), este paso o etapa se hace mediante la red de telecomunicación (310) entre el dispositivo móvil (300) y el servidor o computador (400) conectado a internet. (Ver figuras No.2 y No.3). d) Validar (6.3) si el usuario (100) que invoca el comando o etiqueta (4) para la realización de la compra se encuentra también asociado a un ID de usuario en la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), así como validar si el usuario (100) que recibe el comentario invocando la etiqueta (4) también se encuentra asociado a un ID de usuario receptor/vendedor (100V). Este paso o etapa se hace mediante la red de telecomunicación (310) entre el dispositivo móvil (300) y el servidor o computador (400) conectado a internet. (Ver figuras No.2 y No.3). e) Una vez validada la información del usuario emisor/comprador (100C) y usuario receptor/vendedor (100V) en su dispositivo electrónico o móvil (300), se ejecuta la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200) del usuario (100) internamente en dicho dispositivo móvil (300) para que éste autorice la transacción (7.3) mediante un patrón (7.2’) para validación (7.1), solicitando que el usuario emisor/comprador (100C) introduzca en el dispositivo móvil (300) (específicamente en la aplicación de red social (RD)) un patrón predefinido (7.2”) que sirve para autenticación de la información y comprobación del usuario (100); (Ver figuras No.2 y No.3). f) Comparar el patrón (7.2’) introducido en el dispositivo móvil (300) con un patrón base (7.2”) almacenado en la base de datos del banco o entidad financiera mediante la comunicación entre el dispositivo móvil (300) y el servidor (400) de la entidad financiera, en donde dicho servidor (400) cuenta con una interfaz de programación de aplicaciones API SP (500) por sus siglas en inglés junto con un motor de riesgo (600), en donde se considera y se tiene en cuenta la velocidad con la que dicho patrón (7.2’) fue realizado por el usuario emisor/comprador (100C) ; y (Ver figuras No.2 y No.3). g) En caso de coincidir ambos patrones (7.2’, 7.2”), mediante la comunicación sostenida entre el dispositivo móvil (300) y el servidor (400) del banco o la entidad financiera, realiza la transacción solicitada (7.3) por el usuario emisor/comprador (100C) y se transfieren los fondos al usuario receptor/vendedor (100V) de acuerdo con la etiqueta invocada (4) y los valores correspondientes indicados en la publicación de la red social (RD). (Ver figuras No.2 y No.3).
Así las cosas, en una primera etapa de una modalidad del presente método (M), como se ilustra en las figuras No.2 y No.3, se realiza la implementación de una codificación predeterminada de etiquetas (4) y texto para invocar la realización de la transacción, lo cual puede llevarse a cabo a través de un mensaje o comentario en la aplicación de una red social (RD), extema a una aplicación bancaria. Adicionalmente, en algunas modalidades del método aquí divulgado, se puede emplear un servidor (400) que tiene una interfaz de programación de aplicaciones API SP (500) por sus siglas en inglés junto con un motor de riesgo (600) que corresponde a un elemento en la arquitectura que permite la interacción entre las redes sociales (RD) y una aplicación transaccional (200). (Ver figuras No.1, No.2, No.3 y No.4).
En algunas modalidades del método y el sistema divulgados, la aplicación transaccional (200) es una aplicación web progresiva PWA (200) no nativa, que se ejecuta en un dispositivo móvil (300) conectado a internet, dicha aplicación web progresiva PWA (200) no nativa se emplea para la realización de diversas funciones, en donde este tipo de aplicación web progresiva PWA (200) no nativa emplea tecnologías disponibles en los navegadores de dispositivos móviles (300) tal y como se definieron anteriormente, con el fin de ofrecer una experiencia en los dispositivos móviles (300), muy similar a la de una aplicación nativa, sin tener que ser una aplicación nativa, y en consecuencia, sin tener que realizar una descarga o instalación directamente en el dispositivo móvil (300). Todo esto se realiza en un sistema de telecomunicaciones móviles que permite el acceso a un servidor (400) desde un dispositivo móvil (300), por medio de la red de telecomunicaciones (310), como es evidente para el experto en la materia. (Ver figuras No.2 y No.3).
Así, es importante tener en cuenta que el método (M) anteriormente descrito está condicionado a la publicación (3) de un artículo o producto y/o servicio para venta o similar o la solicitud de dinero y transferencia del mismo en una red social (RD) el cual se hace mediante una aplicación llamada INNVO el cual es un deposito electrónico, dicha aplicación INNVO se encuentra soportada, comunicada y sincronizada mediante una aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200) que se encuentra contenida en el dispositivo móvil (300) del usuario (100), dicho usuario (100) mediante la aplicación INNVO puede vincular un perfil, el cual puede ser un perfil de comprador (C) y/o un perfil de vendedor (V), igualmente este usuario (100) puede agregar un emprendimiento o negocio según el perfil que tenga relacionado (comprador (C) y/o vendedor (V) respectivamente), siguiendo con la descripción, esta aplicación INNVO puede publicar un producto o artículo que ingresa el usuario (100) a esta aplicación INNVO, el cual esta, a su vez publica dicho artículo o producto sobre la red social (RD) haciéndolo de manera automática, sin que dicha aplicación INNVO deba estar necesariamente dentro de la red social (RD), de igual forma esta aplicación INNVO mantiene el registro del inventario de los productos o artículos que el usuario (100) ha publicado y que a su vez le han comprado; esta aplicación INNVO puede iniciar sesión con la red social (RD).
Asimismo, dicha aplicación puede realizar transacciones financieras mediante patrones (7.2’, 7.2”) que a través de un machine leaming (700) junto con un motor de riesgo (600) que se encuentran contenidos en un servidor (400) realiza capturas de información y datos del usuario (100) el cual se verifica de manera segura que dichos patrones (7.2’, 7.2”) cumplan con los parámetros establecidos tales como la velocidad y el tiempo para realizar dichos patrones (7.2’, 7.2”) perfilando el usuario (100) y a su vez verificándolo para realizar la transacción financiera de manera segura, o al contrario, logrando detectar si hay un posible fraude procediendo a rechazar la transacción financiera.
La aplicación INNVO puede retirar, recargar y transferir dinero a través de cajeros automáticos del banco o alguna entidad financiera e igualmente lo puede hacer desde cualquier cuenta bancaria de ahorros o cuenta corriente que tenga el usuario (100), esto se hace también mediante la invocación de un comando o etiqueta específica (4) precedida por un carácter especial, tal como“@InnvoPagar”,“INNVO” o cualquier otra que puede ser previamente programada o definida, en donde el presente método (M) junto con el sistema (S) puede reconocer, que se desea hacer una transacción para una transferencia de dinero entre dos usuarios (100C, 100V) y así, se procede a autorizar (7) o pasar los fondos de una cuenta a otra directamente en la red social (RD), sin necesidad de aplicaciones o elementos adicionales requeridos por un banco o entidad financiera, asimismo, se logra realizar este proceso de manera ágil e inmediato y en tiempo real sin que el usuario (100) final lo note o tenga retrasos considerables.
La aplicación INNVO también permite hacer transacciones financieras dentro de un grupo de usuarios (100C, 100V) de manera segura en la red social (RD) mediante patrones (7.2’, 7.2”) sin necesidad de colocar números telefónicos o el ingreso de datos inseguros o que induzcan a algún error, por otro lado, el grupo de usuarios (100C, 100V) pueden estar vinculados a la aplicación INNVO y a su vez están vinculados a la red social (RD). Esta aplicación INNVO se puede eliminar del dispositivo móvil (300) del usuario (100) de manera fácil sin necesidad de alguna autorización o trámite alguno por parte del banco o entidad financiera. (Ver figuras No.2 y No.3). Luego, tal como se definió anteriormente, los datos tanto del usuario emisor/comprador (100C) como del usuario receptor/vendedor (100V) son registrados (1) y almacenados (1.3, 2.4, 3.1) en la base de datos de la aplicación transaccional (200), por ejemplo, de una aplicación web progresiva (200), que encuentra dentro del dispositivo móvil (300) del usuario (100) (dicho usuario (100) puede ser el mismo, tal como se indicó anteriormente, es decir, un usuario (100) sólo comprador (C) o un usuario emisor/comprador (100C) y vendedor (V)), donde es posible crear un perfil mediante un registro simplificado (1) que comprende los datos de cada usuario (100), dentro de los que se encuentran: nombres, apellidos, número de celular, correo electrónico, número de documento y su fecha de expedición, donde también es importante tener en cuenta que la información del negocio o emprendimiento (2.1, 2.2) de un usuario receptor/vendedor (100V) se almacena (2.4, 3.1) en la base de datos de la aplicación transaccional (200), por ejemplo, de una aplicación web progresiva PWA (200) con la información normal del usuario emisor/comprador (100C) que se encuentra en su dispositivo móvil (300). Todo lo descrito anteriormente, se realiza en la aplicación transaccional (200) que se halla en el dispositivo móvil (300) del usuario (100). (Ver figuras No.2 y No.3).
Así, una vez se han realizado los respectivos registros en la base de datos de la aplicación transaccional (200) definidos anteriormente, el usuario (100) puede iniciar sesión con su plataforma de red social (RD) con el objetivo de asociar el ID de su perfil en dicha red con el perfil creado en la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), y por tanto a su depósito electrónico del producto o cualquier otro producto financiero, tal como, por ejemplo, una cuenta bancaria (ahorros/corriente). De esta manera, cuando el usuario (100) en una red social (RD) desee ejecutar una transacción (7.3), se puede validar (7.1) si existe un perfil de usuario asociado a la cuenta de la aplicación transaccional (200) para realizar la transacción y ejecutar la aplicación, el proceso anterior, se lleva a cabo mediante la comunicación entre el servidor (400) y el dispositivo móvil (300) del usuario (100). (Ver figuras No.2 y No.3).
Después, una vez un usuario (100), en su condición de comprador (C), indica la voluntad de compra de un producto en la red social (RD) que se encuentra ejecutándose al interior de su dispositivo móvil (300), este usuario (100) invoca la transacción en la publicación del producto mediante un comentario que emplea un conjunto de etiquetas (4) predefinidas, tal como se definió anteriormente, en donde este proceso se desarrolla en su respectivo dispositivo móvil (300). (Ver figuras No.2 y No.3).
De este modo, a partir del ID de red social (RD) del usuario (100) mediante su dispositivo móvil (300) que se comunica con el servidor (400) se comprueba (6.3) que dicho usuario (100) tenga una cuenta en la aplicación transaccional (200) asociada, por ejemplo, una aplicación web progresiva PWA (200), y que el receptor (100) de la transacción en la red social (RD) también tenga una cuenta en dicha aplicación transaccional (200). Así, una vez validada la información del emisor (100) y el receptor (100), se ejecuta la mencionada aplicación transaccional (200) del usuario (100) en condición de comprador (C) para que este autorice la transacción mediante un patrón (7.2’) que lleva a cabo mediante su dispositivo móvil (300) que se comunica con el servidor (400) de la entidad financiera haciendo que dicho patrón (7.2’) el cual corresponda a un patrón previamente definido (7.2”) y almacenado en el servidor (400) de la entidad financiera.
Luego, el patrón (7.2’) introducido por el usuario emisor/comprador (100C) es comparado (6.4) con el patrón base (7.2”) almacenado en la API SP (500) junto con un motor de riesgo (600) que se encuentran en el servidor (400) del banco o entidad financiera, que, en caso de coincidencia de ambos patrones (7.2’, 7.2”), la entidad financiera o banco realiza la transacción (7.3) correspondiente y debita el dinero de la cuenta del usuario emisor/comprador (100C) para pasarlo a la cuenta del usuario receptor/vendedor (100V), concluyendo así con la compra. (Ver figuras No.2 y No.3).
El patrón (7.2’) es un elemento de la arquitectura del producto cuya función principal es autorizar las transacciones a partir de un patrón base (7.2”) por el usuario (100) que se dígita en una ventana generada por la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), que se lleva a cabo en su respectivo dispositivo móvil (300). Este patrón (7.2’) podría desarrollarse, de forma ejemplar pero no limitante, sobre una matriz de puntos 3x3 en la que el usuario (100) puede definir un patrón que no se marca en la pantalla de su dispositivo móvil (300), y la autorización se da por comparación de la totalidad de los puntos, en el mismo orden del patrón base (7.2”) que se encuentra almacenado en la API SP (500) del servidor (400) del banco o entidad financiera.
No obstante, en cualquier modalidad del método y el sistema divulgados, el patrón (7.2’) usado para la verificación de la identidad del usuario (100) y así autorizar la transacción financiera, donde dicho patrón (7.2’) se puede seleccionar, sin limitación, de: matrices de puntos para dibujar un patrón, código de seguridad de varios dígitos (PIN), palabra clave, preguntas de seguridad, etc. (Ver figuras No.2 y No.3).
En una modalidad del método y sistema divulgados, la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), permite la gestión de inventario de productos o artículos, ofreciendo así enlaces directos con las redes sociales (RD) para realizar publicaciones y actualizar el inventario de los mismos. Adicionalmente, es posible gestionar ambos perfiles del usuario (100) (dicho usuario (100) puede ser el mismo, o un usuario emisor/comprador (100C) o un usuario que es al tiempo un usuario emisor/comprador (100C) y un usuario receptor/vendedor (100V)), dentro de la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), ofreciendo de esta forma una transaccionalidad entre personas naturales y comercios en las redes sociales (RD). (Ver figuras No.2 y No.3).
En otra una modalidad del método y sistema divulgados, el método (M) hace uso de inteligencia artificial, concretamente con el Machine Leaming (700) (aprendizaje de máquina, por su nombre en inglés, el cual será definido más adelante en detalle), tal como se ilustra claramente en la figura No.2, No.3 y No.4, dicho Machine Leaming (700) se emplea con el fin de permitir que la transacción financiera pueda ser realizada de forma más sencilla y rápida de acuerdo con el comportamiento previo de los usuarios (100C, 100V) y sus transacciones previas, es decir, el sistema (S) asociado al método (M) puede conectarse con cualquier tipo de sistema de inteligencia artificial que puede ser suministrado por cualquier tipo de proveedor, como se conocen comercialmente, con el fin que dicho sistema (S) sea más eficiente y prediga el comportamiento de los usuarios (100C, 100V) y la forma como realizan las transacciones para reducir los tiempos de interacción, y demás variables involucradas. Es importante aclarar que Machine Leaming (700), como es claro para el experto en la materia, corresponde a una de las expresiones de la inteligencia artificial en la que la máquina tal como un computador o servidor (400) y/o dispositivo móvil (300) o cualquier maquina tiene capacidades de aprender a realizar tareas, predecir comportamientos y muchas más, a partir del análisis de datos. (Ver figuras No.2, No.3 y No.4).
En algunas modalidades del método y sistema divulgados se puede tener en cuenta que el empleo de una aplicación transaccional (200), por ejemplo una aplicación web progresiva PWA (200), funciona como el canal transaccional bancario en donde se concentran todas las funcionalidades transaccionales del producto y se gestiona la información de los productos que se publican por parte del usuario (100) en condición de vendedor (V) en redes sociales (RD).
La aplicación transaccional (200) cuando es una aplicación web progresiva PWA (200), constituye una aplicación web no nativa (INNVO) que incorpora ciertos elementos estándar que posibilitan su funcionamiento en conjunto con la aplicación de la red social (RD), dicha aplicación web progresiva PWA (200) constituye una aplicación web no nativa (INNVO) el cual se puede encontrar en un dispositivo móvil (300) de un usuario (100) que as u vez está conectada por medio de una red de telecomunicaciones (310) a un servidor (400). (Ver figuras No.2, No.3 y No.4).
Uno de esos elementos es una herramienta que impulsa la aparición de la interfaz de usuario de la aplicación web progresiva PWA (200) de manera eficiente y confiable, ya que el código se almacena en la memoria (301) caché del dispositivo móvil (300) del usuario (100) con el que se accede a la red social (RD). (Ver figuras No.2, No.3 y No.4).
Sumado a lo anterior, en algunas modalidades del método (M) se puede usar un protocolo de seguridad HTTPS en la conexión de internet, el cual garantiza la seguridad de la información financiera entre la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), y una nube, así como entre la nube y la entidad financiera. Así, la utilización de una aplicación PWA (200) no nativa proporciona ventajas importantes frente a una aplicación nativa, como se definirá a continuación. (Ver figuras No.2, No.3 y No.4).
En algunas modalidades del sistema y método divulgados, la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), es una aplicación multiplataforma, esta ofrece un diseño de respuesta que se adapta a diferentes tamaños de pantalla de diversos dispositivos móviles (300). Adicional a esto, su empleo garantiza una mayor visibilidad por cuanto la aplicación transaccional (200) puede aparecer en resultados de búsqueda web y es posible descargarla de manera gratuita, rápida y fácil desde cualquier explorador.
En algunas modalidades del sistema y método divulgados, la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), puede generar alertas tipo PUSH (emergentes) para facilitar la comunicación y notificación a los usuarios (100C, 100V) y ofrecen rapidez de carga al ejecutarse de manera rápida y eficiente. De esta forma, incorporar lo mejor de las aplicaciones nativas y lo mejor de las páginas web, aunando al hecho que las aplicaciones web progresivas PWA (200) ocupan un espacio de almacenamiento mínimo respecto a las aplicaciones nativas, el empleo de estas aplicaciones garantizan un mejor desempeño que aquellas aplicaciones nativas existentes en el estado del arte, hecho que permite que las modalidades del método (M) divulgado que usen como aplicación transaccional (200) una aplicación web progresiva PWA (200) difieran en gran medida de los existentes en el arte previo.
En algunas de las modalidades del método y sistema divulgados , la aplicación transaccional (200) utilizada para la realización de la transacción financiera es una aplicación nativa convencional en lugar de una aplicación web progresiva no nativa.
Ahora bien, en una modalidad del método y sistema divulgados, y haciendo referencia a las figuras No.2 y No.3, se tiene que un proceso de pago involucra la interacción de todo el sistema (S), en donde en las figuras No.2 y No.3 ilustran un único usuario (100), que puede crear dos tipos de perfiles: usuario emisor/comprador (100C) y usuario receptor/vendedor (100V). En una modalidad del método y sistema divulgados, un usuario que quiera tener perfiles de usuario emisor/comprador (100C) y usuario receptor/vendedor (100V) realiza el registro inicial (1) y agregar o vincular un perfil en su red social (RD) propia de su comercio. (Ver figuras No.1, No.2 y No.3).
De este modo, para que el flujo pueda funcionar, el usuario emisor/comprador (100C) ingresa a la red social (RD), se registra (1), cuando se registra y en paralelo, se almacena su información (1.3, 2.4, 3.1) de usuario en la base de datos de la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200). Si decide ser usuario receptor/vendedor (100V), ingresa a vincular (2.1, 2.2) su emprendimiento o negocio en la red social (RD) y cuando la vincula (2.2), la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), solicita a la interfaz de programación que almacene el ID del usuario (100) y el ID del usuario receptor/vendedor (100V), así como del producto o articulo a vender.
Para poder realizar este procedimiento, la red social (RD) intenta vincular (5) y validar (6) la página para que sea leída, si la respuesta es exitosa (5, 6), se agrega a la red social (RD) y en paralelo se almacena en la base de datos DB SL (900). Esto implica que en la interfaz de programación ya se tiene un registro como usuario receptor/vendedor (100V) y que para la red social (RD), dicho usuario receptor/vendedor (100V) ya es escuchado en dicha página (Ver figura No.2).
Cuando el usuario receptor/vendedor (100V) aparece registrado como tal en la red social (RD), dicho usuario receptor/vendedor (100V) puede entonces publicar (3) los productos en la red social (RD) en cuestión, los cuales se van diferenciando por un ID que va asignando la red social (RD) y que se va almacenando (2.3, 6.1, 6.2.1) en la base de datos DB SL (900). (Ver figura No.2).
Una vez pasa esto, un usuario (100) con un perfil de comprador (C), como se ilustra en la figura No.3, dicho usuario emisor/comprador (100C) ve el producto en la red social (RD) que fue publicado por el usuario receptor/vendedor (100V) (en el que se evidencia que fue publicado por la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200)). El usuario emisor/comprador (100C) procede a realizar un comentario en la publicación del usuario receptor/vendedor (100V) haciendo uso de la etiqueta (4), como se definieron anteriormente. Luego, como se muestra nuevamente en la figura No.2, la red social (RD) le notifica (5) a la interfaz de programación, quien valida (6) filtrando los comentarios que tienen los caracteres especiales y los deja pasar, desechando el resto que no son de interés para la transacción.
Cuando lo deja pasar, va a la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), y le entrega (6.2) el ID del producto o artículo, el ID de la página del usuario receptor/vendedor (100V) y el ID de usuario, para que la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), valide (6.3) si efectivamente ese usuario (100) (comprador (C)) existe y es usuario de la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200).
Si esto es afirmativo, se devuelve y la interfaz lo registra en su base de datos para guardar información histórica de la transacción de cara a una auditoría. Allí se le notifica desde el navegador de internet (7.4) al usuario emisor/comprador (100C) la información para que pueda comprar el producto en el dispositivo móvil (300).
Al abrir la notificación, le aparece toda la información del producto y al verificar que está bien, el usuario emisor/comprador (100C) acepta y aparece el patrón (7.2’), mostrado en la Figura No.2 (método para autorizar las transacciones), allí, el usuario emisor/comprador (100C) dibuja el patrón (7.2’) o ingresa la información de verificación, inmediatamente se invoca al patrón base (7.2”) que se encuentra almacenado en la API SP (500) (donde se captura la velocidad en que se realiza, los puntos seleccionados y la secuencia de los mismos), lo cual es reenviado (7.2’) hacia la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), del dispositivo móvil (300) (nótese que la figura No.2 indica una flecha para este proceso de doble vía), quien el patrón base (7.2”) que se encuentra almacenado en la API SP (500) junto con un motor de riesgo (600), es el encargado de indicar si efectivamente es el usuario emisor/comprador (100C) identificado. (Ver figuras No.2 y No.3). Adicionalmente, aquí entra en funcionamiento un motor de riesgo (600), mostrado en la figuras No.2, No.3 y No.4, donde en el motor de riesgo (600) perfila al cliente o usuario (100) con relación a si es apto o no para hacer una transacción, es decir, si cumple con las condiciones preestablecidas para poder llevar a cabo una transacción de compra en una red social (RD).
Cuando se pasa las etapas de validación del patrón (7.2’), el motor de riesgo (600), procede a realizar la transacción en el núcleo bancario (1000) o entorno de la entidad financiera, donde se valida que haya saldo en la cuenta bancaria, que haya aún productos disponibles y otras cuestiones de ley. Luego de concretar la venta, la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), le notifica (7.4) al usuario receptor/vendedor (100V) que le compraron su producto publicado en la red social (RD). (Ver figura No.2).
El motor de riesgo (600) que se emplea para verificar y validar al cliente o usuario (100) para saber si es apto o no, para hacer una transacción, cumpliendo con las condiciones preestablecidas por el banco o entidad financiera con el fin de llevar a cabo una transacción segura de compra en una red social (RD), dicho proceso se hace mediante la configuración y disposición de varios elementos que junto con unos pasos o etapas que se llevan a cabo dentro del motor de riesgo (600) se hace de la siguiente manera: desde la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), que se encuentra en el dispositivo móvil (300) del usuario (100), dicho usuario (100) envía (1) el patrón (7.2’) o patrón para la verificación de su identidad con el fin de autorizar la transacción financiera.
Dicho patrón (7.2’), por ejemplo, un gesto hecho por el usuario emisor/comprador (100C), corresponde a un conjunto de datos de información que se va a verificar y comparar frente a un patrón base (7.2”) que se encuentra almacenado en la API SP (500), para hacer este proceso se envía este patrón (7.2’) mediante un conjunto de datos de información que se envían al elemento llamado Event Hub (1000) desde un core bancario (1100) (el Event Hub (1000) puede llamar o traer datos de una base de datos (1110) extema de un servidor de la entidad financiera o banco) para gestionar la información que a su vez la envía (2) al elemento llamado Stream Analytics - Real time (920) el cual realiza el análisis y la comparación de la información, cuando esta información cumple (4) se envía al elemento llamado Data Factory (930) el cual organiza la información y la almacena (5) en el elemento llamado DB- Fraud Detección Results SQL (910).
Asimismo esta información también se envía (5.1) al machine leaming engine (700) donde este a su vez procesa la información y responde (5.2), mediante la información allegada al machine leaming engine (700) donde se envía nuevamente la información al elemento llamado DB-Fraud Detección Results SQL (910), asimismo si la información enviada desde el elemento llamado Event Hub (1000) o core bancario (1100) para gestionar la información que a su vez la envía (2) al elemento llamado Stream Analytics - Real time (920) el cual realiza el análisis y comparación de la información y cuando esta información no cumple (3) se almacena en el elemento llamado DB- Fraud Detección Results SQL (910), después de que la información ha pasado por el elemento llamado DB- Fraud Detección Results SQL (910) se realiza su validación en donde puede ser rechazada (3.1), aceptada (5.3) rechazada/ aceptada (6.2) a la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), que se encuentra en el dispositivo móvil (300) del usuario (100), asimismo esta información se puede enviar desde el elemento llamado DB- Fraud Detección Results SQL (910) para realizar una segunda validación (6) a una base de datos DB SL (900) de un servidor (400) para validar (6.1) la información como medida de seguridad para estar seguros de poder realizar la transacción.
El machine leaming engine (700) que se encuentra en el motor de riesgo (600) puede procesar y aprender de la información allegada y recibida (5.4) de la aplicación transaccional (200), por ejemplo, una aplicación web progresiva PWA (200), que se encuentra en el dispositivo móvil (300) del usuario (100) y también de la información allegada o recibida de un servidor (400) que se encuentra en otro lugar. (Ver figura No.4).
En algunas modalidades del sistema divulgado, el sistema (S) se configura para llevar a cabo una modalidad del método (M) como se definió anteriormente, en donde dicho sistema (S) está conformado por un dispositivo móvil (300) de un primer usuario (100), ya sea un usuario emisor/comprador (100C) o un usuario receptor/vendedor (100V), que cuenta con una aplicación para el acceso a una red social (RD) y que además permite acceder a internet, en donde dicho dispositivo (300) además incluye una memoria intema (301) para el almacenamiento de los datos de usuario para poder ingresar a la hora de acceder a la red social (RD) mediante la aplicación incluida (INNVO); una red de telecomunicaciones (310) que permita realizar la conexión de múltiples dispositivos móviles (300) con internet y con una red social (RD) para acceso; un servidor (400) donde se almacena la red social (RD) y permite tener acceso a los usuarios (100C, 100V) de la misma, donde dicho servidor (400) puede ser de tipo tangible o virtual ubicado en una nube o en un computador ubicado en otro lugar, en donde el servidor (400) se comunica con los dispositivos móviles (300) por medio de la red de comunicaciones (310) e internet; un servidor seguro (400) de transacciones, el cual es de propiedad de la entidad financiera y que se conecta por medio de la red de telecomunicaciones (310) con los demás dispositivos móviles (300); y un segundo dispositivo móvil (300) correspondiente a un segundo usuario (100), ya sea un usuario emisor/comprador (100C) o un usuario receptor/vendedor (100V), que se comunica con los demás elementos o componentes del sistema (S) mediante la red de telecomunicaciones (310), en donde dicho segundo dispositivo móvil (300) también cuenta con la aplicación para acceso a la red social (RD) por parte del segundo usuario (100). (Ver figuras No.2, No.3 y No.4).
Así las cosas, en algunas modalidades del sistema (S) aquí divulgado, este puede ser utilizado para realizar una transacción segura mediante una red social (RD), donde dicha transacción se realiza entre dos usuarios (100C, 100V) configurados como usuario emisor/comprador (100C) y usuario receptor/vendedor (100V), respectivamente, donde uno de dichos usuarios (100C, 100V) publica un producto (3) o un servicio que ofrece en venta mientras que el segundo usuario (100) configurado como comprador(C) realiza la compra mediante la red social (RD) utilizando una serie de etiquetas (4) que son reconocidas por la red social (RD) y así se realiza la transacción (7.3) de una forma segura y siguiendo unos patrones (7.2’, 7.2”) de validación, con el fin de realizar la comunicación con el servidor del core bancario (1100) (entidad financiera) y así, poder realizar la transferencia de fondos desde la cuenta del usuario emisor/comprador (100C) a la del usuario receptor/vendedor (100V), informando de esta forma a los dos usuarios (100C, 100V) que la transacción fue realizada de forma exitosa. La transacción segura se realiza mediante el método (M) anteriormente ilustrado, el cual permite obtener como resultado dicha transacción de forma segura entre dos usuarios (100C, 100V) que se configuran como vendedor (V) y comprador (C). (Ver figuras No.l, No.2, No.3, No.4).
Glosario:
A continuación, se describen algunos de los términos usados, en algunas modalidades del método y el sistema divulgadas a lo largo del Capítulo Descriptivo:
Dispositivo computacional (300C, 300V): Son todos aquellos dispositivos en los cuales se puede ejecutar la aplicación transaccional y los cuales están comunicados a través de una red comunicaciones. Ejemplos de dispositivos computaciones (300C, 300V) son teléfonos inteligentes, tablets, phablets, computadores personales, microprocesadores provistos de módulos de comunicación a internet e interfaces de usuario, otros dispositivos computaciones equivalentes conocidos por una persona medianamente versada en la materia y combinaciones de los mismos.
En algunas modalidades del método y el sistema divulgados se usa el término “dispositivo móvil” (300), el cual pertenece a un conjunto de dispositivos computacionales (300C, 300V) que incluyen cualquier dispositivo electrónico que pueda acceder a una red, tal como internet, por cualquier medio, con el fin de poder acceder de la misma forma a una red social (RD), en donde dicho dispositivo móvil (300) puede ser seleccionado, sin limitación, del grupo que consiste de un teléfono móvil, un computador portátil, un computador de escritorio, un servidor, un asistente personal, una tableta, o similar. (Ver figuras No.2, No.3, No.4).
Aplicación transaccional (200): En algunas modalidades del método y el sistema divulgados, se entenderá por aplicación transaccional (200) como un canal que permite hacer interacciones entre usuarios (100C, 100V). Por ejemplo, la aplicación transaccional (200) puede ser de tipo PWA, APP nativa, APP híbrida, página web, otros tipos de aplicaciones equivalentes conocidas por una persona medianamente versada en la materia y combinaciones de las mismas.
Red social (RD): En algunas modalidades del método y el sistema divulgados, se entenderá por Red social (RD) un medio de interacción digital entre dos o más personas o usuarios que pueden ser personas naturales y/o jurídicas. Dicha interacción se puede expresar en diversas formas como chats, publicaciones fijas o temporales, comentarios y reacciones que expresen sentimientos o pensamientos como“me gusta”,“lo quiero”,“lo apruebo”, etc. Algunos ejemplos de redes sociales son Facebook®, Instagram®, Linkedln®, SnapChat®, Telegram®, Pinterest®, Twitter®, Google+®, WhatsApp ®, WeChat ®, Facebook Messenger®, Skype®, YouTube®, Tumble®, Baidu.tieba®, Vkontakte®, Tagged® Reddit®, Haboo®, QQ®, QZone-EcuRed, páginas web, blogs, comercios virtuales (e-commerces, en inglés) y otras redes sociales equivalentes conocidas por una persona medianamente versada en la materia.
Datos de registro: Se entenderá por datos de registro, como unos datos que el usuario ingresa en el primer momento de interacción con la aplicación transaccional (200), estos datos tienen como objetivo la creación y la futura validación de la identidad de una persona, por ejemplo, en las etapas del método donde un usuario ingresa o inicia sesión en la aplicación transaccional (200).
Primera base de datos (905): En algunas modalidades del método y el sistema divulgados, la primera base de datos (905) es una base de datos que se encuentra en el primer servidor, la cual se encarga de almacenar y administrar una información entregada por el usuario a través de la aplicación transaccional (200), y a partir de la cual se forman los datos de registro. Por ejemplo, en algunas modalidades del método y el sistema divulgados, la primera base de datos (905) puede seleccionarse entre bases de datos jerárquicas, base de datos de red, bases de datos transaccionales, bases de datos relaciónales, bases de datos multidimensionales, bases de datos orientadas a objetos, bases de datos documentales, bases de datos deductivas y otras bases de datos equivalentes conocidas por una persona medianamente versada en la materia.
Red de comunicaciones. Se entenderá por red de comunicaciones como un conjunto de medios técnicos que permiten la comunicación a distancia entre equipos autónomos como lo pueden ser dispositivos computacionales y servidores. Normalmente se trata de transmitir datos por ondas electromagnéticas a través de diversos medios (aire, vacío, cable de cobre, fibra óptica, etc.). Ejemplos no limitantes de una red de comunicaciones son Internet, WAN, y LAN. Se entenderá que el método y el sistema aquí divulgado puede emplear cualquier tipo de red de comunicaciones equivalente conocida por una persona medianamente versada en la materia.
Perfil de emisor: El perfil de emisor puede ser una versión de la aplicación en la que se presenta únicamente la información relevante para un usuario emisor/comprador (100C)) (también llamado en algunas realizaciones divulgadas como usuario comprador o usuario emisor una persona que, al interactuar con la aplicación y su red social (RD), tiene una intención de emitir unos datos de emisión hacia un usuario receptor/vendedor (100V) (también llamado en algunas realizaciones divulgadas como usuario vendedor o usuario receptor). En modalidades del método y el sistema aquí divulgados, el perfil de emisor puede ser una versión de la aplicación en la que se presenta únicamente la información relevante para un usuario emisor/comprador (100C) que enviar datos de emisión que corresponden a transferencia de dinero a cambio de recibir unos datos de recepción asociados a la compra de productos, servicios y bienes ofertados por un usuario receptor/vendedor (100V).
Perfil de receptor: El perfil de receptor puede ser una versión de la aplicación en la que se presenta únicamente la información relevante para un usuario receptor/vendedor (100V) (también llamado en algunas realizaciones divulgadas como usuario vendedor o usuario receptor), quien, al interactuar con la aplicación y su red social (RD), tiene la intención de recibir unos datos de emisión a cambio de enviar unos datos de recepción. En modalidades del método y el sistema aquí divulgados, el perfil de receptor puede ser una versión de la aplicación en la que se presenta únicamente la información relevante para un usuario receptor/vendedor (100V) de enviar a un usuario emisor/comprador (100C) unos datos de recepción que corresponden a transferencia, envío o cesión de productos, servicios y bienes a cambio de haber recibido unos datos de emisión enviados por el usuario emisor/comprador que corresponden a transferencia de dinero, bienes, o información.
Perfil de la red social (RD) o perfil de red social (RD) . El perfil de la red social (RD) puede ser una cuenta o perfil que crea una persona, natural o jurídica, en alguna red social (RD) previamente establecida. Dependiendo de la red social (RD), el perfil de una persona puede permitirle, o no, interactuar con otras personas, visualizar contenido generado por la misma red social (RD) o realizar acciones como jugar, comunicarse, o publicar contenido, entre otros.
Etiqueta: En algunas modalidades del método y el sistema divulgados se emplea el término“etiqueta” (4), la cual puede ser una expresión o palabra que permite resaltar un comentario que se puede realizar en la red social (RD), en donde dicha etiqueta (4) puede ser cualquier término o expresión sin limitación, la cual preferiblemente puede ser antecedida por algún elemento adicional, tal como un signo adicional predefinido o algún símbolo ortográfico u otro. (Ver figura No.4).
También, en varias modalidades del método y el sistema aquí divulgados, se puede entender por“etiqueta” como una palabra determinada (Fija) que se comenta en una publicación en la red social (RD) y que al ser diligenciada activa la aplicación transaccional (200), por ejemplo, a través de un servicio Webhook configurado para detectar el ingreso de la etiqueta.
Publicación: En algunas modalidades del método y el sistema divulgados se entenderá por publicación, a una pieza en formato digital que puede incluir, texto, multimedia, arte o cualquier otra expresión de contenido propia de quien realiza la publicación o creada por terceros. La publicación se publica en un entorno, página o sección de la red social (RD), donde uno o más usuarios que tienen perfiles de la red social (RD), pueden ver la pieza publicada. Un ejemplo no limitante es cuando un usuario receptor/vendedor (100V) publica en una red social (RD) una publicación donde oferta un producto, servicio o bien, donde la publicación puede ser una imagen, video, imagen animada (GIF), hipervínculo, texto, o combinaciones de los mismos.
En la presente solicitud, se emplea el término“patrón” (7.2’) a una expresión que permite realizar la validación de una transacción, en donde dicho“patrón” (7.2’) no tiene ninguna limitación y puede ser usado cualquier medio que permita realizar la validación de la identidad del usuario emisor/comprador (100C) o vendedor (V) y puede ser seleccionado, sin limitación, de un número de seguridad (PIN), un patrón de dibujo, un menú desplegable, unas preguntas de seguridad, o similares, entre otros. (Ver figuras No.2, No.3, No.4). Primeros datos de autorización: En algunas modalidades del método y el sistema divulgados se entenderá por primeros datos de autorización como un conjunto de datos que lleva un patrón encriptado y que son únicos para cada usuario, ya que son registrados por cada usuario la primera vez que interactúa con la aplicación transaccional (200). En la primera vez que el usuario interactúa con la aplicación transaccional (200), la aplicación transaccional (200) solicita al usuario ingresar un patrón inicial que genera un conjunto de datos base que se guardan en un servidor o base de datos como un patrón base. Por ejemplo, en algunas modalidades del método y el sistema divulgados, un tercer servidor (403) tiene una segunda base de datos (900) donde se guarda el conjunto de datos base correspondientes al patrón base (7.2”). Cuando un usuario receptor/vendedor (100V) ingresa un patrón (7.2’) en la aplicación transaccional (200) el primer servidor (400) envía un conjunto de datos asociados al patrón (7.2’) al tercer servidor (403), y el tercer servidor (403) compara el conjunto de datos asociados al patrón (7.2’) con el conjunto de datos base asociado al patrón base (7.2”), y el conjunto de datos asociados al patrón (7.2’) coinciden con el conjunto de datos base asociado al patrón base (7.2”), entonces el tercer servidor (403) genera los primeros datos de autorización.
Adicionalmente, en algunas modalidades del método y el sistema divulgados, cada vez que el usuario emisor (también llamado en algunas modalidades del método y el sistema usuario comparador) ingresa el patrón, se genera un conjunto de datos de tiempo que se envían a la segunda base de datos (900) del tercer servidor (403). La segunda base de datos (900) almacena un conjunto de datos de tiempo promedio, los cuales son comparados contra los datos de tiempo asociados al tiempo que invierte el usuario emisor ingresando el patrón (7.2) en la aplicación transaccional (200), y cuando los datos de tiempo coinciden con los datos de tiempo promedio, y además, el conjunto de datos asociados al patrón (7.2’) coinciden con el conjunto de datos base asociado al patrón base (7.2”), entonces el tercer servidor (403) genera los primeros datos de autorización, entonces el tercer servidor (403) genera los primeros datos de autorización.
Segundos datos de autorización: En algunas modalidades del método y el sistema divulgados se entenderá por segundos datos de autorización como unos datos que da como resultado un proceso de inteligencia artificial en donde se valida la identidad del usuario emisor (también llamado en algunas modalidades del método y el sistema usuario comparador) y corrobora el requerimiento de pago que se hizo mediante la red social (RD).
Tiempo de referencia: En algunas modalidades del método y el sistema divulgados se entenderá por tiempo de referencia como el tiempo que el usuario demora en ingresar el patrón en la aplicación transaccional (200). Este tiempo puede ser una variable de validación de usuario debido a que cada usuario gasta un tiempo promedio ingresando el patrón a través de la aplicación transaccional (200), donde un tiempo promedio se almacena en una base de datos.
Por ejemplo, en algunas modalidades del método y el sistema divulgados, cada vez que el usuario emisor (también llamado en algunas modalidades del método y el sistema usuario comparador) ingresa el patrón, se genera un conjunto de datos de tiempo que se envían a la segunda base de datos (900) del tercer servidor (403). La segunda base de datos (900) almacena un conjunto de datos relacionados con el tiempo promedio, los cuales son comparados contra los datos de tiempo asociados al tiempo que invierte el usuario emisor ingresando el patrón (7.2) en la aplicación transaccional (200), y cuando los datos de tiempo coinciden con los datos de tiempo promedio, el tercer servidor (403) genera los primeros datos de autorización.
Además, en algunas modalidades del método y el sistema divulgados, los datos de tiempo promedio pueden actualizarse cada vez que el tercer servidor (403) genera unos primeros datos de autorización después de haber determinado que unos datos de tiempo asociados al tiempo que invierte el usuario emisor ingresando el patrón (7.2) en la aplicación transaccional (200) coinciden con los datos de tiempo promedio. La actualización puede generarse mediante un procesamiento de datos ejecutado por el tercer servidor (403), donde el procesamiento de datos puede ser generar una media aritmética, geométrica, logarítmica, o cualquier otro tipo de operación estadística en donde se tomen los datos de tiempo promedio previamente almacenados en la segunda base de datos (900) y los nuevos datos de tiempo asociados al tiempo que invierte el usuario emisor ingresando el patrón (7.2) en la aplicación transaccional (200), para generar unos datos de tiempo promedio actualizados. Primer servidor (400): en algunas modalidades del método y el sistema divulgados, el primer servidor (400) es un servidor asociado a la aplicación transaccional (200) (application server, en inglés) que permite atender peticiones de un cliente y devolver una respuesta que tenga concordancia. El primer servidor (400) puede estar ubicado en una nube, por ejemplo, una nube como la de AWS (Amazon Web Service), y pertenecer a un componente en una infraestructura de aplicación transaccional (200).
Segundo servidor (402): en algunas modalidades del método y el sistema divulgados, el segundo servidor (402) es un servidor configurado para atender peticiones de un cliente y devolver una respuesta que tenga concordancia. El segundo servidor (402) puede estar ubicado en una nube, por ejemplo, una nube como la de AWS (Amazon Web Service), y puede pertenecer a un componente de una infraestructura Social Payments (SP).
En algunas de las realizaciones de modalidades del método y el sistema divulgados, la infraestructura general Social Payments es una interfaz de programación de aplicaciones (API), también llamada API SP, en donde la API SP es ejecutada por el segundo servidor (402). Por ejemplo, el segundo servidor (402) puede estar configurado para ejecutar un proceso de Social Listening, de manera que el segundo servidor (402) consume un servicio de vigilancia de redes sociales denominado Webhook, donde el Webhook notifica al segundo servidor (402) que se ha ingresado una etiqueta (4) en una publicación de un usuario receptor/vendedor (100V) en una red social (RD).
En algunas de las realizaciones de modalidades del método y el sistema divulgados, el servicio de Webhook se ejecuta permanentemente, es decir, de manera que su funcionalidad no depende de peticiones o llamados extemos, y su ejecución es automática.
En algunas modalidades del método y el sistema divulgados, el segundo servidor (402) está configurado para administrar la red social (RD). Un ejemplo de administrar la red social (RD), es cuando el segundo servidor (402) es capaz de recibir peticiones del primer servidor (400) y consultar dentro de la red social (RD), o enviar peticiones a la red social (RD), para obtener unos datos o información requerida para el método divulgado. Ejemplos de datos consultados en la red social (RD) son datos de perfil de red social (RD), datos de publicación asociados a publicaciones hechas por usuarios, datos de interacción social, entre otros.
Tercer servidor (403): en algunas modalidades del método y el sistema divulgados, el tercer servidor (403) es un servidor configurado para medir y comparar el tiempo en el que el usuario emisor (100C) introduce el patrón (7.2’) contra un tiempo de referencia almacenado en la segunda base de datos (900). Al igual que el segundo servidor (402), el tercer servidor (403) puede estar ubicado en una nube, por ejemplo, una nube como la de AWS (Amazon Web Service), y puede pertenecer a un componente de una infraestructura Social Payments (SP). En algunas de las realizaciones de modalidades del método y el sistema divulgados, la infraestructura Social Payments es una interfaz de programación de aplicaciones (API), también llamada API SP, en donde la API SP es ejecutada por el tercer servidor (403).
En algunas modalidades del método y el sistema divulgados, el tercer servidor (403) puede ser el mismo segundo servidor (402), o puede pertenecer a una granja o cluster de servidores pertenecientes a una nube, por ejemplo, una nube como la de AWS (Amazon Web Service). En este caso el segundo servidor (402) puede estar configurado con un módulo de Social Listening y un módulo de comparación de patrones que pueden pertenecer a la infraestructura Social Payments (SP).
Cuarto servidor (404): en algunas modalidades del método y el sistema divulgados, el cuarto servidor (404) es un servidor configurado para recibir unos datos de autorización desde segundo servidor (402) y/o el tercer servidor (403), y con base en la recepción de los datos de autorización autorizar una transacción entre un usuario emisor/comprador (100C) y un usuario receptor/vendedor (100V). Además, el cuarto servidor (404) está configurado para notificar al primer servidor (400) que la transacción fue autorizada, o rechazada.
En algunas de las modalidades del método y el sistema divulgados, el cuarto servidor (404) se comunica con un núcleo bancario o core bancario (1100). En estas modalidades el núcleo bancario o core bancario (1100) es un espacio digital en el que se centraliza la información intrínseca a la operación del negocio de un banco. Dicha información es sensible puede ser protegida en cuanto al software, hardware y redes de telecomunicaciones. El espacio digital se puede encontrar almacenado en servidores físicos o espacios de computación en la nube.
En otras modalidades del método y sistema divulgados, el cuarto servidor (404) autoriza la transacción de unos datos de transacción que contienen información deseada por el usuario emisor/comprador (100C) y pertenecen al usuario emisor/vendedor (100V). La transacción de datos de transacción se autoriza cuando el cuarto servidor (404) recibe unos datos de autorización desde segundo servidor (402) y/o el tercer servidor (403).
Por ejemplo, para autorizar la transacción, el cuarto servidor (404) verifica que el emisor/comprador (100C) tenga disponibles unos datos de compra o datos de intercambio que son de interés para el usuario receptor/vendedor (100V). Esta verificación puede hacerse consultando una base de datos que contiene unos datos de un perfil de usuario o cuenta, donde cada perfil de usuario o cuenta tiene asociado un saldo de datos de compra o datos de intercambio del usuario emisor/comprador (100C).
De acuerdo con lo anterior, en algunas modalidades del método y sistema divulgados, si el cuarto servidor (404) verifica que el usuario emisor/comprador (100C) tenga disponibles unos datos de compra o datos de intercambio que son de interés para el usuario receptor/vendedor (100V), y el cuarto servidor (404) recibe los datos de autorización desde segundo servidor (402) y/o el tercer servidor (403), entonces se autoriza la transacción, y en consecuencia el usuario receptor/vendedor (100V) recibe los datos de compra o datos de intercambio que pertenecen al usuario emisor/comprador (100C), y el emisor/comprador (100C) recibe los datos de transacción que contienen información deseada por el usuario receptor/comprador (100C) y pertenecen al usuario emisor/vendedor (100V).
En algunas modalidades del método y sistema divulgados los datos de transacción que contienen información deseada por el usuario receptor/comprador (100C) están asociados a un producto, servicio o bien que publica el usuario emisor/vendedor (100V) en la red social (RD). Asimismo, algunas modalidades del método y sistema divulgados los datos de compra o datos de intercambio que pertenecen al usuario emisor/comprador (100C) están asociados a un saldo de dinero que tiene el usuario emisor/comprador (100C) en un producto financiero, como una cuenta bancaria, taqeta de crédito, billetera virtual, crédito rotatorio, y otros productos financieros equivalentes. De acuerdo con lo anterior, cuando el cuarto servidor (404) autoriza la transacción, el usuario emisor/comprador (100C) compra, recibe y/o accede al servicio, producto o bien publicado por el usuario emisor/vendedor (100V), y el usuario emisor/vendedor (100V) recibe dinero por parte del usuario emisor/comprador (100C). También, el usuario emisor/vendedor (100V) puede recibir y/o acceder a otro producto, servicio o bien del emisor/comprador (100C), con lo cual la transacción equivale a un trueque o intercambio de productos, servicios y/o bienes.
Motor de riesgo (600): En algunas modalidades del método y sistema divulgados se entenderá por Motor de riesgo (600)a un proceso que permite identificar el nivel de riesgo que tiene una transacción basándose en la adquisición y administración de información.
Aplicación web progresiva (PWA, por las siglas en inglés de Progressive web app): Una aplicación APW o PWA es una aplicación web que no ocupa espacio de memoria en el dispositivo debido a que su soporte se encuentra en una nube, y puede funcionar para todos los usuarios independientemente del navegador que utilicen ya que puede adaptarse a cada tipo de navegador. Además una aplicación APW o PWA, puede incluir características propias de las aplicaciones móviles como lo son las notificaciones push, GPS y también se puede descargar un acceso directo que queda instalado en una interfaz de usuario de un dispositivo computacional (300C, 300V), por ejemplo, una pantalla, ventana de inicio o menú de aplicaciones, sin necesidad de descargarlo de una tienda de aplicaciones. Además, las aplicaciones APW o PWA pueden actualizarse automáticamente sin adicionar carga al dispositivo computacional (300C, 300V).
Además, la aplicación APW puede trabajar sin tener una conexión a internet gracias a una característica llamada Service Worker la cual permite realizar acciones dentro de la aplicación sin necesidad de una conexión estable ya que las aplicaciones PWA pueden guardan información en memoria cache, así como lo hacen las aplicaciones nativas. Asimismo, aplicación PWA es segura debido a que maneja protocolos de seguridad para el manejo de información como lo es TLS (Transport Layer Security). Adicionalmente, la aplicación PWA se puede compartir por URL a través de mensajes de texto y es muy agradable al usuario ya que su diseño y su experiencia se plantea como una aplicación nativa. También, las aplicaciones PWA pueden incluir design responsive, esto significa que pueden ejecutarse en cualquier dispositivo móvil con cualquier resolución de pantalla.
En algunas modalidades del método y sistema, la aplicación transaccional (200) puede ser una aplicación PWA.
Producto financiero: En algunas modalidades del método y sistema, se entenderá por producto financiero a un servicio ofrecido por una organización que ofrece servicios financieros, que permite a un usuario almacenar, solicitar, utilizar, cobrar, invertir (depositar a cambio de un retomo) dinero bien sea en físico (como una bóveda en un banco) o digital. Ejemplos de productos financieros son cuentas de ahorros, cuentas corriente, billeteras virtuales, taqetas de crédito, créditos rotativos, y combinaciones de los mismos.
En algunas modalidades del método y sistema, se otorga un producto financiero al usuario emisor/comprador (100C) cuando una organización que ofrece servicios financieros a través le da acceso al usuario emisor/comprador (100C) a un producto financiero, en donde el usuario emisor/comprador (100C) puede ser persona natural o jurídica.
En general, el producto financiero se otorga después de que el usuario emisor/comprador (100C) solicita abrir del producto financiero. La apertura del producto financiero es un proceso que realiza un usuario, persona natural o jurídica, por ejemplo, el usuario emisor/comprador (100C), para solicitar a una organización que ofrece servicios financieros el acceso a un producto financiero. En algunas realizaciones del método y el sistema divulgados, después de que el usuario, por ejemplo, el usuario emisor/comprador (100C), solicita la apertura del producto financiero, la organización que ofrece servicios financieros evalúa unos criterios de aceptación que permiten identificar si el usuario cumple con unas condiciones establecidas para contar con el acceso a un producto financiero. Ejemplos de criterios de aceptación son, capacidad de endeudamiento, cantidad de ingresos, activos que posee el usuario, historial crediticio, y otros indicadores equivalentes. Datos de interacción social: En algunas modalidades del método y sistema divulgados, se entenderá por datos de interacción social del usuario emisor/comprador (100C) como unos datos que contienen información relacionada con las interacciones que realiza un usuario emisor/comprador (100C) en una red social (RD) desde su perfil de la red social (RD), por ejemplo, páginas preferidas, tipo de publicaciones que hace en la red social (RD), amigos o usuarios relacionados, grupos de interacción a los que pertenece en la red social (RD), horas del día y días de la semana en las que el usuario emisor/comprador (100C) usa su perfil de la red social (RD), entre otros.
Datos de historial de intercambio. En algunas modalidades del método y sistema divulgados, se entenderá por datos de interacción social del usuario emisor/comprador (100C) como unos datos que contienen información relacionada con las transacciones que ha ejercido un usuario emisor/comprador (100C) a través de la aplicación transaccional (200). Por ejemplo, los datos de historial de intercambio pueden incluir información relacionada con el número de compras que ha hecho el usuario emisor/comprador (100C), monto máximo y monto mínimo que transfiere el usuario emisor/comprador (100C) a través de la aplicación transaccional (200), fecha de última interacción del usuario emisor/comprador (100C) en la aplicación transaccional (200), horas del día y días de la semana en las que el usuario emisor/comprador (100C) usa la aplicación transaccional (200) y otros tipos de información equivalentes.
Datos de distinción. En algunas modalidades del método y sistema divulgados, se entenderá por datos de distinción como unos datos que contienen información relacionada con la publicación del usuario receptor/vendedor (100V) en la red social (RD). Por ejemplo, los datos de distinción pueden contener información relacionada con tipo de producto, servicio o bien ofertado, precio, número de unidades, idioma de la publicación, geolocalización donde el del usuario receptor/vendedor (100V) hizo la publicación, entre otros.
Inventario de productos o servicios: En algunas modalidades del método y sistema divulgados, se entenderá por inventario de productos o servicios como el número de unidades disponibles de un producto o servicio que el usuario receptor/vendedor (100V) dispone dentro de la red social (RD) para participar en transacciones mediante la aplicación transaccional (200). Machine Learning (700), machine learning engine, o componente de inteligencia artifical: En algunas modalidades del método y sistema divulgados, se entenderá que estos términos se relacionan con un proceso o algoritmo de inteligencia artificial que perme a una máquina tal como un dispositivo computacional (300C, 300V), un computador o servidor (400) y/o dispositivo móvil (300) u otro, pueda aprender a tomar decisiones. Por ejemplo, el machine leaming engine (700) o componente de inteligencia artificial puede ser un algoritmo que garantice la validación de un usuario a través de la captura de información de la red social (RD).
En algunas modalidades del método y sistema divulgados, el machine leaming engine (700) toma recibe unos datos de entrada, que pueden ser datos de interacción social del usuario emisor/comprador (100C) (v.g. páginas preferidas, tipo de publicaciones que hace en la red social (RD), amigos o usuarios relacionados, grupos de interacción a los que pertenece en la red social (RD), horas del día y días de la semana en las que el usuario emisor/comprador (100C) usa su perfil de la red social (RD), entre otros), o del usuario receptor/vendedor (100V), datos de distinción relacionados con la publicación del usuario receptor/vendedor (100V) en la red social (RD) (v.g. tipo de producto, servicio o bien ofertado, precio, número de unidades, idioma de la publicación, geolocalización donde el del usuario receptor/vendedor (100V) hizo la publicación, entre otros).
También, en algunas modalidades del método y sistema divulgados, el machine leaming engine (700) recibe como datos de entrada, unos datos de historial de intercambio proporcionados por el primer servidor (400) correspondientes a información relacionada con la interacción del usuario emisor/comprador (100C) con la aplicación transaccional (200). Por ejemplo, los datos de historial de intercambio proporcionados por el primer servidor (400) pueden incluir información relacionada con el número de compras que ha hecho el usuario emisor/comprador (100C), monto máximo y monto mínimo que transfiere el usuario emisor/comprador (100C) a través de la aplicación transaccional (200), fecha de última interacción del usuario emisor/comprador (100C) en la aplicación transaccional (200), horas del día y días de la semana en las que el usuario emisor/comprador (100C) usa la aplicación transaccional (200) y otros tipos de información equivalentes. En algunas modalidades del método y sistema divulgados, el machine leaming engine (700) puede ser un servicio de IA y Machine Leaning de Azure ®, por ejemplo, el servicio Azure Machine Leaming Service ®.
En algunas modalidades del método y sistema divulgados, el machine leaming engine (700) recibe como datos de entrada, unos datos proporcionados por el segundo servidor (402) y el tercer servidor (403) que corresponden a información relacionada con un patrón base (7.2”), y un patrón (7.2’) que ingresa el usuario emisor/comprador (100C) en la aplicación transaccional (200).
En algunas modalidades del método y sistema divulgados, el machine leaming engine (700) recibe como datos de entrada, unos datos de provenientes de una base de datos (1110]) de un core bancario (1100) o de un cuarto servidor (404), los cuales contienen información relacionada con que el emisor/comprador (100C) tenga disponibles unos datos de compra o datos de intercambio que son de interés para el usuario receptor/vendedor (100V). En algunas modalidades del método y sistema divulgados los datos de compra o datos de intercambio que pertenecen al usuario emisor/comprador (100C) están asociados a un saldo de dinero que tiene el usuario emisor/comprador (100C) en un producto financiero, como una cuenta bancaria, taqeta de crédito, billetera virtual, crédito rotatorio, y otros productos financieros equivalentes.
En algunas modalidades del método y sistema divulgados, el machine leaming engine (700) toma los datos de entrada y los procesa de manera que obtiene como salida unos datos de decisión que contienen información relacionada con que la transacción sea aceptada, rechazada o aceptada/rechazada. En algunas modalidades del método y sistema, el machine leaming engine (700) envía los primeros datos de autorización a un componente de base de datos, por ejemplo, un componente de base de datos DB-Fraud Detection Results SQL (910), el cual puede ser un ser servicio de base de datos SQL los ofrecidos por Azure ®. En este caso, el tercer servidor (403) consulta el componente de base de datos DB-Fraud Detection Results SQL (910), para obtener los primeros datos de autorización y enviarlos al primer servidor (400) cuando la transacción es autorizada. Asimismo, en algunas modalidades del método y sistema divulgados, el machine leaming engine (700) puede recibir como datos de entrada, datos proporcionados por un módulo o elemento llamado Stream Analytics-Real time (920), los cuales contienen información procesada por el módulo o elemento llamado Stream Analytics-Real time (920). Similarmente, el machine leaming engine (700) puede recibir como datos de entrada unos datos organizados provenientes de un componente o elemento llamado Data Factory (930) que organiza unos datos procesaros por el módulo o elemento llamado Stream Analytics-Real time (920).
Módulo de análisis de datos o elemento Stream Analytics-Real time (920): En algunas modalidades del método y sistema divulgados, se entenderá por módulo de análisis de datos o elemento Stream Analytics-Real time (920), como un módulo que permite análisis de datos en tiempo real. Por ejemplo, el módulo de análisis de datos o elemento Stream Analytics-Real time (920) puede ser un motor de procesamiento de eventos complejo y de análisis en tiempo real configurado para analizar y procesar datos provenientes del primer servidor (400), el segundo servidor (402), el tercer servidor (403), el cuarto servidor (404) o el core bancario (1100).
En algunas modalidades del método y sistema divulgados, el módulo de análisis de datos o elemento Stream Analytics-Real time (920) puede generar patrones y relaciones entre los datos procesados. Los patrones se pueden usar para desencadenar acciones e iniciar flujos de trabajo en otros elementos como el componente Data Factory (930) y el componente de inteligencia artificial o machine leaming engine (700). Además, los patrones o datos procesados por el módulo de análisis de datos o elemento Stream Analytics-Real time (920) se pueden almacenar en un un componente de base de datos DB-Fraud Detection Results SQL (910).
En algunas modalidades del método y sistema divulgados, el módulo de análisis de datos o elemento Stream Analytics-Real time (920) puede ser el servicio Azure Stream Analytics ® de Azure ®.
Módulo de gestión de datos (930 )o módulo Event Hub: En algunas modalidades del método y sistema divulgados, el módulo de gestión de datos (930) o módulo Event Hub puede ser una plataforma de transmisión de datos (data streaming, en inglés) e ingesta de eventos que permite captar datos desde el primer servidor (400), segundo servidor (402), tercer servidor (403) y cuarto servidor (404) y/o desde el core bancario (1100). El Módulo de gestión de datos (930) o módulo Event Hub puede enviar los datos que captura al módulo de análisis de datos o elemento Stream Analytics-Real time (920). En algunas modalidades del método y sistema divulgados, el módulo de análisis de datos o elemento Stream Analytics-Real time (920) puede ser el servicio Azure Event Hubs® de Azure®.
Elemento DB-Fraud Detection Results SQL (910): En algunas modalidades del método y sistema divulgados, el elemento DB-Fraud Detection Results SQL (910) puede ser una base de datos donde se almacena toda la información del análisis previo de las transacciones realizadas por el usuario emisor/comprador (100C).
En algunas modalidades del método y sistema divulgados, el elemento DB-Fraud Detection Results SQL (910) puede ser una base de datos SQL de Azure®.
Se debe entender que la presente divulgación no se halla limitada a las modalidades descritas e ilustradas, pues como será evidente para una persona versada en el arte, existen variaciones y modificaciones posibles que no se apartan del espíritu de la invención, el cual solo se encuentra definido por las siguientes reivindicaciones.

Claims

REIVINDICACIONES
1. Un método para autorizar a través de dispositivos computacionales (300C, 300V) una transacción entre un usuario emisor (100C) y un usuario receptor (100V) que están registrados previamente en una red social (RD), el método que comprende:
a) almacenar (1.3, 2.4, 3.1) unos datos de registro de cada usuario (100C, 100V) en una primera base de datos (905) localizada en un primer servidor (400) configurado para administrar una aplicación transaccional (200), donde
el usuario emisor (100C) ingresa sus datos de registro a través de un primer dispositivo computacional (300C) configurado para ejecutar la aplicación transaccional (200) y el usuario receptor (100V) ingresa sus datos de registro a través de un segundo dispositivo computacional (300C) configurado para ejecutar la aplicación transaccional (200), y
donde los dispositivos computacionales (300C, 300V) se conectan mediante una red de comunicaciones con el primer servidor (400);
b) generar mediante el primer servidor (400) un perfil de emisor y un perfil de receptor para la aplicación transaccional (200), donde la etapa de generación de perfiles incluye:
asociar los datos de registro del usuario emisor (100C) del paso a) con unos datos de perfil de la red social (RD) del usuario emisor (100C); asociar los datos de registro del usuario receptor (100V) del paso a) con unos datos de perfil de la red social (RD) del usuario receptor (100V); y crear a partir de los datos de registro y los datos de perfil de la red social (RD) del usuario emisor (100C) un perfil de emisor, y a partir de los datos de registro y los datos de perfil de la red social (RD) del usuario receptor (100V) un perfil de receptor,
donde los perfiles de emisor y receptor se almacenan en la primera base de datos (905) y
donde el primer servidor (400) solicita los datos de perfil de la red social (RD) a un segundo servidor (402) que está configurado para administrar la red social (RD);
c) detectar a través del segundo servidor (402) una etiqueta (4) que ingresa el usuario emisor (100C) en una publicación hecha por el usuario receptor (100V) dentro de la red social (RD), donde la detección de la etiqueta (4) genera que el segundo servidor (402) se comunique con el primer servidor (400) para que dicho primer servidor (400) ejecute la aplicación transaccional (200) en el dispositivo computacional (300) del usuario emisor (100C);
d) validar (6.3) mediante el primer servidor (400) si los usuarios (100C, 100V) del paso c) tienen perfiles de emisor y receptor guardados en la primera base de datos (905);
e) generar unos primeros datos de autorización para autorizar la transacción (7.3) entre el usuario emisor (100C) y el usuario receptor (100V), donde la generación de los primeros datos de autorización comprende:
ejecutar mediante el primer servidor (400) la aplicación transaccional (200) en el dispositivo computacional (300C) del usuario emisor (100C) solicitando al usuario emisor (100C) ingresar un patrón (7.2’) en el dispositivo computacional (300C); f) comparar en un tercer servidor (403) el patrón (7.2’) con un patrón base (7.2”) que está almacenado en una segunda base de datos (900) de un tercer servidor (403) y comparar el tiempo en el que el usuario emisor (100C) introduce el patrón (7.2’) contra un tiempo de referencia almacenado en la segunda base de datos (900);
donde el tercer servidor (403) genera los primeros datos de autorización y los envía a un cuarto servidor (404) cuando los patrones (7.2’, 7.2”) coinciden y el tiempo en el que el usuario emisor (100C) ingresa el patrón (7.2’) coincide con el tiempo de referencia almacenado en la segunda base de datos (900); y g) autorizar mediante el cuarto servidor (404) la transacción entre el usuario emisor (100C) y el usuario receptor (100V), donde el cuarto servidor (404) notifica al primer servidor (400) que la transacción es autorizada.
2. El método de la Reivindicación 1, donde el tercer servidor (403) ejecuta un motor de riesgo (600) configurado para medir y comparar el tiempo en el que el usuario emisor (100C) introduce el patrón (7.2’) contra un tiempo de referencia almacenado en la segunda base de datos (900), y donde el motor de riesgo (600) genera los primeros datos de autorización cuando el patrón (7.2’) coincide con el patrón base (7.2”) y se ingresa en el tiempo de referencia.
3. El método de la Reivindicación 1, donde en la aplicación transaccional (200) el usuario receptor (100V) tiene además de su perfil de receptor un perfil de emisor guardado en la primera base de datos (905).
4. El método de acuerdo con cualquiera de las Reivindicaciones anteriores, donde:
- la etapa a) además comprende abrir (1.2) un producto financiero relacionado con el usuario emisor (100C) a través de la aplicación transaccional (200), donde la aplicación transaccional (200) se comunica a través del primer servidor (400) con el cuarto servidor (404) configurado para otorgar dicho producto financiero.
5. El método de la Reivindicación 4, donde en la etapa e) el cuarto servidor (404) verifica que el producto financiero cumpla con unos requisitos de aceptación, donde en la verificación del producto financiero el tercer servidor (403) se comunica con el cuarto servidor (404) y le solicita unos datos financieros que son posteriormente analizados a través el motor de riesgo (600) para determinar si el producto financiero cumple con los requisitos de aceptación.
6. El método de acuerdo con la Reivindicación 1, donde los datos de registro de cada usuario (100C, 100V) se seleccionan entre nombres, apellidos, número de celular, correo electrónico, número de documento de identidad y su fecha de expedición, y combinaciones de los anteriores.
7. El método de acuerdo con cualquiera de las Reivindicaciones anteriores, donde:
en la etapa f) el motor de riesgo (600) tiene un componente de aprendizaje computacional o machine leaming (700) que incluye:
solicitar al primer servidor (400) unos datos de historial de intercambio del usuario emisor (100C);
solicitar al segundo servidor (402) unos datos de interacción social del usuario emisor (100C); y
comparar en el tercer servidor (403) los datos de historial de intercambio y datos de interacción social del usuario emisor (100C) con unos datos de distinción relacionados con la publicación del paso c); donde el tercer servidor (403) genera unos segundos datos de autorización que envía al primer servidor (400); y - el paso g) además comprende recibir los segundos datos de autorización antes de autorizar a través del primer servidor (400) en la aplicación transaccional (200) la transacción entre el usuario emisor (100C) y el usuario receptor (100V).
8. El método de acuerdo con la Reivindicación 2, donde en la etapa f) el motor de riesgo (600) además incluye:
enviar un primer conjunto de datos asociados al patrón (7.2’) los cuales se generan cuando el usuario emisor (100C) ingresa el patrón (7.2’) en la aplicación transaccional (200) desde el dispositivo computacional (300C), donde el primer conjunto de datos se envía a un elemento llamado Event Hub (1000) localizado en el cuarto servidor (404);
analizar y comparar el primer conjunto de datos contra el patrón base (7.2”) mediante en un elemento llamado Stream Analytics-Real Time (920), donde el patrón base (7.2”) está guardado en el tercer servidor (403); y
enviar el primer conjunto de datos analizado y comparado desde el elemento Stream Analytics-Real Time (920), a un elemento llamado Data Factory (930) y a un elemento llamado DB-Fraud Detection Results SQL (910), para almacenar dicho conjunto de datos si el patrón (7.2’) coincide con el patrón base (7.2”);
enviar el primer conjunto de datos analizado y comparado desde el elemento Data Factory (930) hacia un componente de aprendizaje computacional llamado Machine Leaming (700); y
decidir mediante el componente de aprendizaje computacional llamado Machine Leaming (700) si la transacción entre el usuario emisor (100C) y el usuario receptor (100V) es rechazada (3.1), aceptada (5.3) o rechazada/aceptada (6.2), donde el componente de aprendizaje computacional llamado Machine Leaming (700) genera los primeros datos de autorización cuando la transacción es aceptada (5.3), donde el componente de aprendizaje computacional llamado Machine Leaming (700) envía los datos de autorización al elemento DB-Fraud Detection Results SQL (910) para almacenarlos, y donde el tercer servidor (403) consulta en el elemento DB- Fraud Detection Results SQL (910) los primeros datos de autorización para enviarlos al primer servidor (400) cuando la transacción es autorizada.
9. El método de acuerdo con cualquiera de las Reivindicaciones anteriores, donde la aplicación transaccional (200) está configurada para permitir al usuario receptor (100V) gestionar desde su dispositivo computacional (300V) un inventario de productos o servicios relacionando cada producto o servicio con un enlace directo que se publica en la red social (RD), donde la gestión de inventario incluye agregar, eliminar o modificar los productos o servicios publicados.
10. El método de acuerdo con cualquiera de las Reivindicaciones anteriores, donde la etapa c) además comprende ejecutar un servicio de enlazamiento (webhook) administrado por el segundo servidor (402), donde el servicio de enlazamiento se ejecuta permanentemente para detectar cuando el usuario emisor (100C) ingresa la etiqueta (4) en la publicación hecha por el usuario receptor (100V) dentro de la red social (RD), y donde el servicio de enlazamiento genera una orden para el segundo servidor (402) cuando detecta la etiqueta (4), la orden configurada para generar que el segundo servidor (403) se comunique con el primer servidor (400) para que dicho primer servidor (400) ejecute la aplicación transaccional (200) en el dispositivo computacional (300) del usuario emisor (100C).
11. Un sistema para autorizar a través de dispositivos computacionales (300C, 300V) una transacción entre un usuario emisor (100C) y un usuario receptor (100V) que están registrados previamente en la red social (RD), el sistema que comprende:
un primer dispositivo computacional (300C) de un usuario emisor (100C) configurado para ejecutar una aplicación transaccional (200);
un segundo dispositivo computacional (300V) de un usuario receptor (100V) configurado para ejecutar la aplicación transaccional (200);
un primer servidor (400) conectado mediante una red de comunicaciones con los dispositivos computacionales (300C, 300V) y configurado para:
administrar la aplicación transaccional (200);
guardar una primera base de datos (905) que incluye unos datos de registro del usuario emisor (300C) y unos datos de registro del usuario receptor (300V);
generar unos perfiles de emisor y receptor de dichos usuarios (300C, 300V) a partir de la asociación de los datos de registro de los usuarios (300C, 300V) con unos datos de perfil de la red social (RD) solicitado que le solicita el primer servidor (400) a un segundo servidor (402); guardar los perfiles de emisor y receptor de dichos usuarios (300C, 300V);
validar (6.3) si el usuario emisor (100C) y el usuario receptor (100V) tienen perfiles de emisor y comprador guardados en la primera base de datos (905) cuando el segundo servidor (402) detecta una etiqueta (4);
solicitar al usuario emisor (100C) el ingreso de un patrón (7.2”) en la aplicación transaccional (200) que se ejecuta en el dispositivo computacional (300C); y
recibir desde un tercer servidor (403) unos datos de autorización; el segundo servidor (402) conectado mediante la red de comunicaciones al primer servidor (400) y está configurado para:
administrar la red social (RD);
detectar la etiqueta (4), donde la etiqueta (4) la ingresa el usuario emisor (100C) en una publicación hecha por el usuario receptor (100V) dentro de la red social (RD), donde la detección de la etiqueta (4) genera que el segundo servidor (402) se comunique con el primer servidor (400) para que dicho primer servidor (400) ejecute la aplicación transaccional (200) instalada en el dispositivo computacional (300) del usuario emisor (100C); y
un tercer servidor (403) conectado mediante la red de comunicaciones a los servidores (400, 402), donde el tercer servidor (403) está configurado para medir y comparar el tiempo en el que el usuario emisor (100C) introduce el patrón (7.2’) contra un tiempo de referencia almacenado en la segunda base de datos (900), y
un cuarto servidor (404) configurado para autorizar la transacción entre el usuario emisor (100C) y el usuario receptor (100V), donde el cuarto servidor (404) notifica al primer servidor (400) que la transacción es autorizada; y donde el tercer servidor (403) genera los primeros datos de autorización y los envía al cuarto servidor (404) cuando los patrones (7.2’, 7.2”) coinciden; y donde el sistema ejecuta un método de acuerdo con cualquiera de las Reivindicaciones 1 a 11.
PCT/IB2019/058495 2018-10-05 2019-10-04 Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles WO2020070721A1 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CONC2018/0010774A CO2018010774A1 (es) 2018-10-05 2018-10-05 Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles
CONC2018/0010774 2018-10-05

Publications (1)

Publication Number Publication Date
WO2020070721A1 true WO2020070721A1 (es) 2020-04-09

Family

ID=67616264

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/058495 WO2020070721A1 (es) 2018-10-05 2019-10-04 Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles

Country Status (2)

Country Link
CO (1) CO2018010774A1 (es)
WO (1) WO2020070721A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230061559A1 (en) * 2020-09-30 2023-03-02 Snap Inc. Cross-platform data management and integration

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090022682A (ko) * 2007-08-31 2009-03-04 주식회사 비원플러스 키스트로크 기반 행동 패턴 정보를 이용한 금융 거래서비스 제공 방법 및 시스템
US20140282977A1 (en) * 2013-03-15 2014-09-18 Socure Inc. Risk assessment using social networking data
US20160180325A1 (en) * 2014-12-19 2016-06-23 Facebook, Inc. Facilitating sending and receiving of peer-to-business payments
US20160180302A1 (en) * 2014-12-22 2016-06-23 Drew N. Bagot, JR. System and method for processing multiple recurring payments
US20180069867A1 (en) * 2016-09-07 2018-03-08 Cylance Inc. Computer User Authentication Using Machine Learning

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090022682A (ko) * 2007-08-31 2009-03-04 주식회사 비원플러스 키스트로크 기반 행동 패턴 정보를 이용한 금융 거래서비스 제공 방법 및 시스템
US20140282977A1 (en) * 2013-03-15 2014-09-18 Socure Inc. Risk assessment using social networking data
US20160180325A1 (en) * 2014-12-19 2016-06-23 Facebook, Inc. Facilitating sending and receiving of peer-to-business payments
US20160180302A1 (en) * 2014-12-22 2016-06-23 Drew N. Bagot, JR. System and method for processing multiple recurring payments
US20180069867A1 (en) * 2016-09-07 2018-03-08 Cylance Inc. Computer User Authentication Using Machine Learning

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230061559A1 (en) * 2020-09-30 2023-03-02 Snap Inc. Cross-platform data management and integration

Also Published As

Publication number Publication date
CO2018010774A1 (es) 2019-08-20

Similar Documents

Publication Publication Date Title
US20200265417A1 (en) System and Method for Creating and Administering Electronic Credentials
US8701983B2 (en) Systems and methods for gesture-based interaction with computer systems
CN113169980A (zh) 使用区块链的交易账户数据维护
US20150161605A1 (en) Systems and methods for generating and using a digital pass
WO2018145195A1 (en) Secure location based electronic financial transaction methods and systems
US20210173675A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
CN114303164A (zh) 使用事件驱动平台的供方发票对账和支付
US20220171505A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
US20210389854A1 (en) Biometric Authentication, Decentralized Learning Framework, and Adaptive Security Protocols in Distributed Terminal Network
WO2020261074A1 (es) Sistema y método para la aprobación y desembolso de un crédito
US20220159002A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
US20210312026A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
WO2020070721A1 (es) Sistema y método para transacciones fáciles y seguras en redes sociales para dispositivos móviles
US20220262210A1 (en) Graphical User Interface and Operator Console Management System for Distributed Terminal Network
US11640613B2 (en) Motion-enabled transaction system using air sign symbols
CN113168637B (zh) 用于交易验证期间的次级欺诈检测的方法和系统
US11880834B2 (en) Data security for transactions with secure offer system
US12003550B2 (en) Resource protection and verification with bidirectional notification architecture
US20240135364A1 (en) Method for transferring data over a blockchain network for digital transactions
WO2023249558A1 (en) Method and system for adaptively executing a plurality of tasks
WO2021118943A1 (en) Distributed terminals network management, systems, devices, interfaces and workflows
WO2021118942A9 (en) Distributed terminals network management, systems, devices, interfaces and workflows
WO2021118940A1 (en) Distributed terminals network management, systems, devices, interfaces and workflows
CN113168637A (zh) 交易验证期间的次级欺诈检测

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19869516

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19869516

Country of ref document: EP

Kind code of ref document: A1