EP2810242A1 - Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples - Google Patents

Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples

Info

Publication number
EP2810242A1
EP2810242A1 EP13742884.3A EP13742884A EP2810242A1 EP 2810242 A1 EP2810242 A1 EP 2810242A1 EP 13742884 A EP13742884 A EP 13742884A EP 2810242 A1 EP2810242 A1 EP 2810242A1
Authority
EP
European Patent Office
Prior art keywords
data
model
user
social
analytical model
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP13742884.3A
Other languages
German (de)
English (en)
Other versions
EP2810242A4 (fr
Inventor
Patrick Faith
Theodore Harris
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/520,481 external-priority patent/US10223691B2/en
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of EP2810242A1 publication Critical patent/EP2810242A1/fr
Publication of EP2810242A4 publication Critical patent/EP2810242A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • FIGURE 1 shows a block diagram illustrating example aspects of a centralized personal information platform in some embodiments of the MMCDB
  • FIGURES 2A-F show block diagrams illustrating example aspects of data models within a centralized personal information platform in some embodiments of the MMCDB
  • FIGURE 3 shows a block diagram illustrating example MMCDB component configurations in some embodiments of the MMCDB
  • FIGURE 4 shows a data flow diagram illustrating an example search result aggregation procedure in some embodiments of the MMCDB
  • FIGURE 5 shows a logic flow diagram illustrating example aspects of aggregating search results in some embodiments of the MMCDB, e.g., a Search Results Aggregation ("SRA") component 500
  • SRA Search Results Aggregation
  • FIGURES 6A-D show data flow diagrams illustrating an example card- based transaction execution procedure in some embodiments of the MMCDB
  • FIGURES 7A-E show logic flow diagrams illustrating example aspects of card-based transaction execution, resulting in generation of card-based transaction data and service usage data, in some embodiments of the MMCDB, e.g., a Card-Based Transaction Execution ("CTE") component 700
  • CTE Card-Based Transaction Execution
  • FIGURE 8 shows a data flow diagram illustrating an example procedure to aggregate card-based transaction data in some embodiments of the MMCDB
  • FIGURE 9 shows a logic flow
  • FIGURES 14A-B show flow diagrams illustrating example aspects of normalizing aggregated search, enrolled, service usage, transaction and/or other aggregated data into a standardized data format in some embodiments of the MMCDB, e.g., a Aggregated Data Record Normalization ("ADRN") component 1400;
  • ADRN Aggregated Data Record Normalization
  • FIGURE 15 shows a logic flow diagram illustrating example aspects of recognizing data fields in normalized aggregated data records in some embodiments of the MMCDB, e.g., a Data Field Recognition ("DFR") component 1500;
  • DFR Data Field Recognition
  • FIGURE 16 shows a logic flow diagram illustrating example aspects of classifying entity types in some embodiments of the MMCDB, e.g., an Entity Type Classification (“ETC") component 1600;
  • ETC Entity Type Classification
  • FIGURE 17 shows a logic flow diagram illustrating example aspects of identifying cross-entity correlation in some embodiments of the MMCDB, e.g., a Cross- Entity Correlation (“CEC”) component 1700;
  • CEC Cross- Entity Correlation
  • FIGURE 18 shows a logic flow diagram illustrating example aspects of associating attributes to entities in some embodiments of the MMCDB, e.g., an Entity Attribute Association (“EAA”) component 1800; [ 0026 ]
  • FIGURE 19 shows a logic flow diagram illustrating example aspects of updating entity profile-graphs in some embodiments of the MMCDB, e.g., an Entity Profile-Graph Updating (“EPGU”) component 1900;
  • FIGURE 20 shows a logic flow diagram illustrating example aspects of generating search terms for profile-graph updating in some embodiments of the MMCDB, e.g., a Search Term Generation (“STG”) component 2000; [ 0028 ]
  • FIGURES 21A-E show user interface diagrams illustrating example features of user interfaces for an electronic virtual wallet in some embodiments of the MMCDB; [ 0029 ]
  • FIGURE 22 shows a block diagram illustrating example aspects of a merchant analytics platform in some embodiments of the MMCDB; [ 0030 ] FIGURE
  • FIGURE 37 shows a data flow diagram illustrating an example email data aggregation procedure, in one embodiment of the MMCDB;
  • FIGURE 38 shows a block diagram illustrating an example distributed linking node mesh, in one embodiment of the MMCDB;
  • FIGURES 39A-F show a block diagram illustrating an example distributed linking node mesh search, in one embodiment of the MMCDB;
  • FIGURES 40A-C show a block diagram illustrating an example distributed linking node mesh index creation, in one embodiment of the MMCDB;
  • FIGURE 41 shows a logic flow illustrating an example Encryptmatics XML Converter component, in one embodiment of the MMCDB;
  • FIGURE 42 shows a logic flow illustrating input language loading by an Encryptmatics XML Converter component, in one embodiment of the MMCDB;
  • FIGURES 43A-B show a logic flow illustrating input model conversion by an Encryptmatics XML Converter component, in one embodiment of the MMCDB; 1 [ 0051 ]
  • FIGURE 44 shows a block diagram illustrating aspects of a tumblar data
  • FIGURE 45 shows a logic flow diagram illustrating an example tumblar
  • FIGURE 46 shows an example data flow illustrating mesh aggregation
  • FIGURE 47 shows an example logic flow illustrating cluster response
  • FIGURE 48A-C illustrate an example MMCDB application embodiment
  • FIGURE 49 shows a block diagram illustrating embodiments of a MMCDB
  • Reference number 201 is
  • MMCDB MULTI-SOURCE, MULTI-DIMENSIONAL, CROSS-ENTITY, MULTIMEDIA DATABASE PLATFORM APPARATUSES, METHODS AND SYSTEMS
  • MMCDB components transform data aggregated from various computer resources, via MMCDB components, into updated entity profiles, social graphs and/or investment recommendations.
  • the MMCDB components implement advantageous features as set forth below.
  • FIGURE 1 shows a block diagram illustrating example aspects of a centralized personal information platform in some embodiments of the MMCDB.
  • originators 111 such as merchants 111b, consumers 111c (including, e.g., social networking sites), account issuers, acquirers 111a, and/or the like, desire to utilize information from payment network systems for enabling various features for consumers, and may provide input for the generation of a centralized personal information platform.
  • the mesh server 105 may aggregate and store such inputs in consolidated database 104b.
  • input types e.g., consumer transactions 111b, social network interactions nid (e.g., emails, reviews, text posts, photos, audio/video/multimedia, conversations, chats, etc.), financial institution activity 111a (e.g., acquirers, authorizations, denials, issuers, fraud detection, etc.), merchant activities 111b (e.g., offers, coupons, redemptions, etc.), and/or the like
  • the mesh server 105 may aggregate and store such inputs in consolidated database 104b.
  • the mesh server aggregation may be achieved by obtaining a feed of financial transactions (e.g., if the mesh server is also a pay network server), by obtaining complete feed access (e.g., firehose feeds), from social networks (e.g., Facebook, Twitter, etc.), using publically available data API's (e.g., Google seach API), and/or the like.
  • the feeds may be obtained via high-bandwidth network connections.
  • An example of the high-bandwidth network connections may include multiple optical fiber connections to an Internet backplane such as the multinational Equinix Exchange, New York International Internet eXchange (e.g., "NYIIX", and/or the like.
  • the obtained feeds may be stored in fast storage array servers for processing or access by other processing servers.
  • the fast storage array servers may include server blades such as those manufactured by Dell Computer (e.g., Dell model M820, M620, and/or the like), having multiple RAID fast SSD drives of type SAS with memory cache of type Li, L2, L3, and/or the like.
  • the feeds may be stored in a public cloud storage service (e.g., Amazon S3, and/or the like) or private cloud (e.g., OpenStack Storage object and/or OpenStack Storage block storage running on servers such as those described above).
  • the fast storage servers may employ a distributed file system that provides high-throughput access to stored data.
  • Example file systems suitable for this purpose may include the Hadoop Distributed File System (e.g., "HDFS"), Google BigTable, and/or the like.
  • the file system may be implemented substantially as a key /value store or, in other embodiments, as a structured file system containing directories and files.
  • a hybrid key /value structured file system may be used in order to utilize the capabilities of both a key /value store and a structured file system.
  • the fast storage array servers may be connected to one or mesh servers (e.g., 105) for feed processing.
  • the mesh servers may be server blades such as those described above.
  • the servers may be virtualized and running on a private virtualization platform such as VMWare ESXi, Xen, OpenStack Compute and/or the like.
  • the servers may be virtualized using a publically available cloud service such as Amazon EC2 (e.g., via an Amazon Machine Image / "AMI", and/or the like) or Rackspace (e.g., by providing a machine image such as a VDI or OVA file suitable for creating a virtualized machine).
  • the mesh server may generate dictionary short code words for every type of input and associate with that short word with the input (e.g., a MD5 hash, etc. may generate a short word for every type of input, where the resulting short code is unique to each input).
  • This short code to actual data input association when aggregated, may form the basis of a mesh dictionary.
  • An example of mesh dictionary entry substantially in the following form of XML is:
  • Segmented portions, complete dictionaries, and/or updates thereto may thus be sent en masse to mesh analytics clone servers; for example, such update may be done at off-network peak hours set to occur at dynamically and/or at set intervals.
  • This allows the analytics servers to perform analytics operations, and it allows those analytics servers to operate on short codes even without the full underlying backend data being available.
  • dictionaries may be analyised using less space than the full underlying raw data would require.
  • dictionaries may be distributed between multiple servers. In one embodiment, the dictionaries are replicated across multiple servers and, periodically, synchronized.
  • any inconstancies in distributed and/or separated dictionaries may be reconciled using demarcation protocol and/or controlled inconsistency reconciliation for replicated data (see D. Barbara H. Garcia-Molina, The case for controlled inconsistency in replicated data," Proc. of the Workshop on Management of Replicated Data, Houston, TX, Nov. 1990; D. Barbara H. Garcia-Molina, The demarcation protocol a technique for maintaining arithmetic constraints in distributed database systems, CS-TR-320-91, Princeton University, April 1991; the contents of both which are herein expressly incorporated by reference).
  • dictionaries may defer any analytic operations that require the backend data until when the caching of the dictionary is complete.
  • ⁇ may be considered as “payment network server” or “pay network server.” It should be understood that such server may incorporate mesh servers, and it also contemplates that such mesh servers may include a network of mesh analytics clone servers, clustering node servers, clustering servers, and/or the like.
  • entities may desire include application services 112 such as alerts 112a, offers 112c, money transfers 112 ⁇ , fraud detection 112b, and/or the like.
  • application services 112 such as alerts 112a, offers 112c, money transfers 112 ⁇ , fraud detection 112b, and/or the like.
  • originators may request data to enable application services from a common, secure, centralized information platform including a consolidated, cross-entity profile-graph database 101.
  • the originators may submit complex queries to the MMCDB in a structure format, such as the example below.
  • the query includes a query to determine a location (e.g., of a user), determine the weather associated with the location, perform analyses on the weather data, and provide an exploded graphical view of the results of the analysis:
  • meta data " . /fModels/robotExample . meta"
  • a user may log into a website via a
  • the computing device may provide a IP address, and a timestamp to
  • the MMCDB may identify a profile of the user from its
  • the MMCDB may provide access to information on a need-to-know basis to ensure the security of data of entities on which the MMCDB stores information.
  • access to information from the centralized platform may be restricted based on the originator as well as application services for which the data is requested.
  • the MMCDB may thus allow a variety of flexible application services to be built on a common database infrastructure, while preserving the integrity, security, and accuracy of entity data.
  • the MMCDB may generate, update, maintain, store and/or provide profile information on entities, as well as a social graph that maintains and 1 updates interrelationships between each of the entities stored within the MMCDB.
  • the MMCDB may store profile information on an issuer bank 102a (see profile
  • the MMCDB may also store relationships between such entities. For example,
  • the MMCDB may store information on a relationship of the issuer bank 102a
  • FIGURES 2A-F show block diagrams illustrating example aspects of data
  • the MMCDB may store a variety of attributes of
  • the MMCDB may store user profile attributes.
  • a user profile model may store user identifying information 201, user
  • 21 model may store user identifying information 220, user financial account information
  • a user payment card attributes data model may include field types
  • 26 such s, but not limited to: user identifying information 230, user financial account
  • 31 user services attributes data model may include field types such as, but not limited to: 1 user identifying information 240, user alias 241, consumer application user alias status
  • consumer application 256 user activity audit 257, login results 258, and/or the like.
  • a user services usage attributes data model may include field types
  • a user graph attributes data model may include field types such as, but not4 limited to: user identifying information 280, user contact 281, consumer application5 user alias status 282, relationship 283, and/or the like.
  • the6 MMCDB may store each object (e.g., user, merchant, issuer, acquirer, IP address,7 household, etc.) as a node in graph database, and store data with respect to each node in8 a format such as the example format provided below:
  • TOKENENTITYKEY 2b8494 flbdlcl Ie0acbd6d88 8c43 f7 c2 : TOKEN : 1 000:1
  • TOKENENTITYKEY 2b8494 flbdlcl Ie0acbd6d88 8c43 f7 c2 : TOKEN : 0 :2
  • TOKENENTITYKEY 2b8494 flbdlcl Ie0acbd6d88 8c43 f7 c2 : TOKEN : 1 000:4
  • TOKENENTITYKEY 2b8494 flbdlcl Ie0acbd6d88 8c43 f7 c2 : TOKEN : 0 :3 2cf8cbaebdlclle0b6515de4f9281135, 2cf8cbaebdlclle0b6515de4f9281135 , USERNAME : 000064A2 OFF962 D4
  • the MMCDB may store data in a JavaScript Object Notation ("JSON") format.
  • the stored information may include data regarding the object, such as,
  • 'MEMBERSHIP' ⁇ ' TYPEOFTYPES ' : ['MEMBERSHIPS'], 'FUNCTIONS': ⁇ ' ENTITYCREATION ' : ' putNet ork ' ⁇
  • 'TOKENENTITIESRELATIONSHIPS' ['USER'], 'ATTRIBUTES': ⁇ 'STATUS': (2, 'STRING', 0, 'VALUE'), 'EXPDT': (6, 'DATETIME', 0, 'VALUE'), 'USERSECURITYNAME': (4, 'STRING', 0, 'VALUE'), 'USER': (3,
  • ⁇ 'MCCSEG' (4, 'STRING', 0, 'VALUE'), 'MCC: (2, 'STRING', 0, 'VALUE'), ' MCCNAME ' : (3, 'STRING', 0, 'VALUE'), 'ISACTIVE': (0, 'BOOL', 1, 'VALUE'), ⁇ ': (1, 'STRING', 0, 'VALUE') ⁇ ⁇
  • ⁇ 'STATUS' (2, 'STRING', 0, 'VALUE'), 'MERCHANT': (3, 'STRING', 0, 'VALUE'), 'TITLE': (5, 'STRING', 0, 'VALUE'), 'NOTES': (7, 'STRING', 0, 'VALUE'), 'UPDATEDBY': (11, 'STRING', 0, 'VALUE'), ⁇ ': (1, 'STRING', 0, 'VALUE'), ' DECRIPTION ' : (6,
  • 'UNIQUEATTIBUTES' [ ' MODELNAME ' ]
  • 'TOKENENTITIESRELATIONSHIPS' ['USER', 'MERCHANT', ' PAYMENTCARD ' ]
  • 'ATTRIBUTES' ⁇ 'XML': (2, 'STRING', 0, 'VALUE'), 'MODELNAME': (3, 'STRING', 0, 'VALUE'), 'DESCRIPTION': (4, 'STRING', 0, 'VALUE'), ⁇ ': (1,
  • 'MCCSEGNAME ' (3, 'STRING', 0, 'VALUE'), 'ISACTIVE': (0, 'BOOL', 1, 'VALUE'), ⁇ ': (1, 'STRING', 0, 'VALUE') ⁇
  • FIGURE 3 shows a block diagram illustrating example MMCDB component configurations in some embodiments of the MMCDB.
  • the MMCDB may aggregate data from a variety of sources to generate centralized personal information. The may also aggregate various types of data in order to generate the centralized personal information.
  • the MMCDB may utilize search results aggregation component(s) 301 (e.g., such as described in FIGS. 4-5) to aggregate search results from across a wide range of computer networked systems, e.g., the Internet.
  • the MMCDB may utilize transaction data aggregation component(s) 302 (e.g., such as described in FIGS.
  • the MMCDB may utilize service usage data aggregation component(s) 303 (e.g., such as described in FIGS. 6-9) to aggregate data on user's usage of various services associated with the MMCDB.
  • the MMCDB may utilize enrollment data component(s) 304 (e.g., such as described in FIGS. 12-13) to aggregate data on user's enrollment into various services associated with the MMCDB.
  • the MMCDB may utilize email data component(s) 305a (e.g., such as described in FIG. 37) to aggregate data regarding the user's email correspondence history into various services associated with the MMCDB.
  • the MMCDB may utilize social data aggregation component(s) 305 (e.g., such as described in FIGS. 10-11) to aggregate data on user's usage of various social networking services accessible by the MMCDB.
  • the aggregated data may be used to generate dictionary entries. Further detail regarding the generation of dictionary entries may be found throughout this specification, drawings, and claims and particularly with reference to Fig. 1 and Fig. 46. 1 [ 0074]
  • the MMCDB may acquire the aggregated data, and
  • the MMCDB may extract data from the
  • 8 MMCDB may identify names, user ID(s), addresses, network addresses, comments
  • the MMCDB may classify entity types associated with the field of data, as2 well as entity identifiers associated with the field of data, e.g., via component(s) 3083 (e.g., such as described in FIG. 16). For example, the MMCDB may identify an Internet4 Protocol (IP) address data field to be associated with a user ID john.q.public (consumer5 entity type), a user John Q.
  • IP Internet4 Protocol
  • the0 MMCDB may utilize the entity types and entity identifiers to correlate entities across1 each other, e.g., via cross-entity correlation component(s) 309 (e.g., such as described in2 FIG. 17).
  • the MMCDB may identify, from the aggregated data, that a3 household entity with identifier H123 may include a user entity with identifier John Q.4 Public and social identifier john.q.public@facebook.com, a second user entity with5 identifier Jane P. Doe with social identifier jpdoe@twitter.com, a computer entity with6 identifier IP address 192.168.4.5, a card account entity with identifier ****i234, a bank7 issuer entity with identifier AB23145, a merchant entity with identifier Acme Stores, Inc.8 where the household sub-entities make purchases, and/or the like.
  • the MMCDB may utilize the entity identifiers, data associated with each0 entity and/or correlated entities to identify associations to other entities, e.g., via entity1 attribute association component(s) 310 (e.g., such as described in FIG. 18).
  • entity1 attribute association component(s) 310 e.g., such as described in FIG. 18.
  • the MMCDB may identify specific purchases made via purchase transactions by members of the household, and thereby identify attributes of members of the household on the basis of the purchases in the purchase transactions made by members of the household.
  • the MMCDB may update a profile for each entity identified from the aggregated data, as well as a social graph interrelating the entities identified in the aggregated data, e.g., via entity profile-graph updating component(s) 311 (e.g., such as described in FIGS. 19, 40, 41A-E and 42A-C).
  • entity profile-graph updating component(s) 311 e.g., such as described in FIGS. 19, 40, 41A-E and 42A-C
  • the updating of profile and/or social graphs for an entity may trigger a search for additional data that may be relevant to the newly identified correlations and associations for each entity, e.g., via search term generation component(s) 313-314 (e.g., such as described in FIG. 20).
  • the updating of a profile and/or social graph may trigger searches across the Internet, social networking websites, transaction data from payment networks, services enrolled into and/or utilized by the entities, and/or the like.
  • such updating of entity profiles and/or social graphs may be performed continuously, periodically, on-demand, and/or the like.
  • FIGURE 4 shows a data flow diagram illustrating an example search result aggregation procedure in some embodiments of the MMCDB.
  • the pay network server may obtain a trigger to perform a search.
  • the pay network server may periodically perform a search update of its aggregated search database, e.g., 410, with new information available from a variety of sources, such as the Internet.
  • a request for on-demand search update may be obtained as a result of a user wishing to enroll in a service, for which the pay network server may facilitate data entry by providing an automated web form filling system using information about the user obtained from the search update.
  • the pay network server may parse the trigger to extract keywords using which to perform an aggregated search.
  • the pay network server may generate a query for application programming interface (API) templates for various search engines (e.g., GoogleTM, Bing®, AskJeeves, market data search engines, etc.) from which to collect data for aggregation.
  • the pay network server may query, e.g., 412, a pay network database, e.g., 407, for search API templates for the search engines.
  • the pay network server may utilize PHP/SQL commands similar to the examples provided above.
  • the database may provide, e.g., 413, a list of API templates in response. Based on the list of API templates, the pay network server may generate search requests, e.g., 414.
  • the pay network server may issue the generated search requests, e.g., 4i5a-c, to the search engine servers, e.g., 40ia-c.
  • the pay network server may issue PHP commands to request the search engine for search results.
  • An example listing of commands to issue search requests 4i5a-c, substantially in the form of PHP commands, is provided below:
  • the search engine servers may query, e.g., 4i7a-c, their search databases, e.g., 402a-c, for search results falling within the scope of the search keywords.
  • the search databases may provide search results, e.g., 4i8a-c, to the search engine servers.
  • the search engine servers may return the search results obtained from the search databases, e.g., 4i9a-c, to the pay network server making the search requests.
  • An example listing of search results 4i9a-c, substantially in the form of JavaScript Object Notation (JSON)-formatted data, is provided below: ⁇ " responseData" : ⁇
  • responseDetails null
  • responseStatus 200 ⁇
  • the pay network server may store the aggregated
  • 11 search results e.g., 420, in an aggregated search database, e.g., 410a.
  • FIGURE 5 shows a logic flow diagram illustrating example aspects of
  • the pay network server 14 Aggregation (“SRA") component 500.
  • the pay network server 14 Aggregation (“SRA") component 500.
  • the pay network server 14 Aggregation (“SRA") component 500.
  • the pay network server 15 may obtain a trigger to perform a search, e.g., 501.
  • a trigger to perform a search e.g., 501.
  • a request for on-demand search update may be obtained as a result of a user
  • the pay network server may facilitate data entry
  • the pay network server 21 obtained from the search update.
  • the pay network server 21 obtained from the search update.
  • the 22 may parse the trigger, e.g., 502, to extract keywords using which to perform an
  • the pay network server may determine the search engines to search,
  • the pay network server may generate a
  • API application programming interface
  • the pay network server may query, e.g., 505, a
  • 29 pay network server may utilize PHP/SQL commands similar to the examples provided
  • the database may provide, e.g., 505, a list of API templates in response.
  • the pay network server may generate search requests, e.g.,
  • the pay network server may issue the generated search requests to the search engine servers.
  • the search engine servers may parse the obtained search results(s), e.g., 507, and query, e.g., 508, their search databases for search results falling within the scope of the search keywords.
  • the search databases may provide search results, e.g., 509, to the search engine servers.
  • the search engine servers may return the search results obtained from the search databases, e.g., 510, to the pay network server making the search requests.
  • the pay network server may generate, e.g., 511, and store the aggregated search results, e.g., 512, in an aggregated search database.
  • FIGURES 6A-D show data flow diagrams illustrating an example card- based transaction execution procedure in some embodiments of the MMCDB.
  • a user e.g., 601
  • the user may desire to purchase a product, service, offering, and/or the like ("product"), from a merchant.
  • the user may communicate with a merchant server, e.g., 603, via a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 602).
  • the user may provide user input, e.g., purchase input 611, into the client indicating the user's desire to purchase the product.
  • the user input may include, but not be limited to: keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.), mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like.
  • a browser application executing on the client device to a website of the merchant, and may select a product from the website via clicking on a hyperlink presented to the user via the website.
  • the client may obtain track 1 data from the user's card (e.g., credit card, debit card, prepaid card, charge card, etc.), such as the example track 1 data provided below:
  • the client may generate a purchase order message, e.g., 612, and provide, e.g., 613, the generated purchase order message to the merchant server.
  • HTTP(S) Secure Hypertext Transfer Protocol
  • XML extensible Markup Language
  • HTTP(S) GET message including an XML-formatted purchase order message for the merchant server:
  • the merchant server may obtain the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user.
  • the merchant server may generate a card query request, e.g., 614 to determine whether the transaction can be processed. For example, the merchant server may attempt to determine whether the user has sufficient funds to pay for the purchase in a card account provided with the purchase order.
  • the merchant server may provide the generated card query request, e.g., 615, to an acquirer server, e.g., 604.
  • the acquirer server may be a server of an acquirer financial institution ("acquirer") maintaining an account of the merchant. For example, the proceeds of transactions processed by the merchant may be deposited into an account maintained by the acquirer.
  • the card query request may include details such as, but not limited to: the costs to the user involved in the transaction, card account details of the user, user billing and/or shipping information, and/or the like.
  • the merchant server may provide a HT P(S) POST message including an XML-formatted card query request similar to the example listing provided below:
  • the acquirer server may generate a card
  • 9 card authorization request e.g., 617
  • a pay network server e.g., 605.
  • the pay network server e.g., 605.
  • the pay network server may determine whether
  • the user has enrolled in value-added user services.
  • the pay network server For example, the pay network server
  • a database e.g., pay network database 407, for user service enrollment
  • the server may utilize PHP/SQL commands similar to the example
  • the pay network database 16 16 provided above to query the pay network database.
  • the pay network database 16 16 provided above to query the pay network database.
  • the 17 database may provide the user service enrollment data, e.g., 619.
  • the user enrollment is data may include a flag indicating whether the user is enrolled or not, as well as
  • network server may redirect the client to a value-add server (e.g., such as a social network).
  • a value-add server e.g., such as a social network
  • the pay network server may provide payment information extracted from the card authorization request to the value-add server as part of a value add service request, e.g., 620.
  • the pay network server may provide a HTTP(S) POST message to the value-add server, similar to the example below:
  • the value-add server may provide a service
  • the value-add server may provide a
  • the client may display, e.g., 622, the login form
  • the user may provide login input into the client,
  • the client may generate a service input response, e.g., 624, for the value-
  • the value-add server may provide value-add
  • the value-add server may generate a value-add service response, e.g.,
  • server may provide a HTTP(S) POST message similar to the example below:
  • the pay network server may extract the enrollment service
  • the pay network server may forward the card authorization request to an appropriate pay network server, e.g., 628, which may parse the card authorization request to extract details of the request. Using the extracted fields and field values, the pay network server may generate a query, e.g., 629, for an issuer server corresponding to the user's card account.
  • an issuer financial institution such as a banking institution, which issued the card account for the user.
  • An issuer server e.g., 6o8a-n, of the issuer may maintain details of the user's card account.
  • a database e.g., pay network database 607
  • the database may be a relational database responsive to Structured Query Language ("SQL") commands.
  • the pay network server may execute a hypertext preprocessor ("PHP") script including SQL commands to query the database for details of the issuer server.
  • PHP/SQL command listing illustrating substantive aspects of querying the database, is provided below:
  • $query "SELECT issuer name issuer address issuer id ip address mac address auth key port num security settings list FROM
  • $result mysql query ( $query) ; // perform the search query
  • the pay network database may provide, e.g., 630, the requested issuer server data to the pay network server.
  • the pay network server may utilize the issuer server data to generate a forwarding card authorization request, e.g., 631, to redirect the card authorization request from the acquirer server to the issuer server.
  • the pay network server may provide the card authorization request, e.g., 632, to the issuer server.
  • the issuer server may parse the card authorization request, and based on the request details may query 633 a database, e.g., user profile database 609, for data of the user's card account.
  • the issuer server may issue PHP/SQL commands similar to the example provided below:
  • $query "SELECT user id user name user balance account type FROM UserTable WHERE account_num LIKE '%' $accountnum" ;
  • $result mysql query ( $query) ; // perform the search query
  • the issuer server may determine whether the user can pay for the transaction using funds available in the account, e.g., 635. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like. If the issuer server determines that the user can pay for the transaction using the funds available in the account, the server may provide an authorization message, e.g., 636, to the pay network server. For example, the server may provide a HTTP(S) POST message similar to the examples above.
  • the pay network server may obtain the authorization message, and parse the message to extract authorization details. Upon determining that the user possesses sufficient funds for the transaction, the pay network server may generate a transaction data record from the card authorization request it received, and store, e.g., 639, the details of the transaction and authorization relating to the transaction in a database, e.g., pay network database 607. For example, the pay network server may issue PHP/SQL commands similar to the example listing below to store the transaction data in a database:
  • account name account type, account num, billing addres, zipcode, phone, sign, merchant params list, merchant id, merchant name, merchant auth key
  • VALUES timeO, $purchase summary list, $num products
  • $account_params_list $account_name, $account_type , $account_num, $billing addres, $zipcode, $phone, $sign, $merchant params list, $merchant id, $merchant name, $merchant auth key)"); // add data to table in database
  • the pay network server may forward the authorization message, e.g., 640, to the acquirer server, which may in turn forward the authorization message, e.g., 640, to the merchant server.
  • the merchant may obtain the authorization message, and determine from it that the user possesses sufficient funds in the card account to conduct the transaction.
  • the merchant server may add a record of the transaction for the user to a batch of transaction data relating to authorized transactions.
  • the merchant may append the XML data pertaining to the user transaction to an XML data file comprising XML data for transactions that have been authorized for various users, e.g., 641, and store the XML data file, e.g., 642, in a database, e.g., merchant database 604.
  • a batch XML data file may be structured similar to the example XML data structure template provided below:
  • the server may also generate a purchase receipt, e.g., 643, and provide the purchase receipt to the client.
  • the client may render and display, e.g., 644, the purchase receipt for the user.
  • the client may render a webpage, electronic message, text / SMS message, buffer a voicemail, emit a ring tone, and/or play an audio message, etc., and provide output including, but not limited to: sounds, music, audio, video, images, tactile feedback, vibration alerts (e.g., on vibration- capable client devices such as a smartphone etc.), and/or the like.
  • the merchant server may initiate clearance of a batch of authorized transactions.
  • the merchant server may generate a batch data request, e.g., 645, and provide the request, e.g., 646, to a database, e.g., merchant database 604.
  • the merchant server may utilize PHP/SQL commands similar to the examples provided above to query a 1 relational database.
  • the database may provide the
  • the server may generate a batch clearance request, e.g.,
  • the merchant server may
  • the acquirer server may generate, e.g., 650, a batch
  • the pay network server may parse
  • the pay network server may store the
  • 11 transaction data e.g., 653, for each transaction in a database, e.g., pay network database
  • the pay network server may query, e.g., 654-655, a
  • database e.g., pay network database 607, for an address of an issuer server.
  • the pay network server may utilize PHP/SQL commands similar to the
  • the pay network server may generate an individual payment
  • 17 provide the individual payment request, e.g., 657, to the issuer server, e.g., 608.
  • the issuer server e.g., 608.
  • the pay network server may provide a HTTP(S) POST request similar to the
  • the issuer server may generate a payment
  • the issuer server may issue a command to deduct
  • 25 issuer server may issue a payment command, e.g., 659, to a database storing the user's payment command.
  • a payment command e.g., 659
  • the issuer server may provide a
  • the acquirer server may parse the funds transfer message, and correlate the transaction (e.g., using the request_ID field in the example above) to the merchant. The acquirer server may then transfer the funds specified in the funds transfer message to an account of the merchant, e.g., 662.
  • FIGURES 7A-E show logic flow diagrams illustrating example aspects of card-based transaction execution, resulting in generation of card-based transaction data and service usage data, in some embodiments of the MMCDB, e.g., a Card-Based Transaction Execution ("CTE") component 700.
  • a user may provide user input, e.g., 701, into a client indicating the user's desire to purchase a product from a merchant.
  • the client may generate a purchase order message, e.g., 702, and provide the generated purchase order message to the merchant server.
  • the merchant server may obtain, e.g., 703, the purchase order message from the client, and may parse the purchase order message to extract details of the purchase order from the user.
  • Example parsers that the merchant client may utilize are discussed further below with reference to FIGURE 49.
  • the merchant may generate a product data query, e.g., 704, for a merchant database, which may in response provide the requested product data, e.g., 705.
  • the merchant server may generate a card query request using the product data, e.g., 704, to determine whether the transaction can be processed. For example, the merchant server may process the transaction only if the user has sufficient funds to pay for the purchase in a card account provided with the purchase order.
  • the merchant server may optionally provide the generated card query request to an acquirer server.
  • the acquirer server may generate a card authorization request using the obtained card query request, and provide the card authorization request to a pay network server. 1 [o o 96]
  • the pay network server may determine whether
  • the user has enrolled in value-added user services.
  • the pay network server For example, the pay network server
  • a database e.g., 707
  • user service enrollment data e.g., 707
  • 4 server may utilize PHP/SQL commands similar to the example provided above to query
  • the database may provide the user
  • the user enrollment data may include a flag
  • the pay network server may redirect
  • a value-add server e.g., such as a social network server where the value-add
  • 11 service is related to social networking) by providing a HTTP(S) REDIRECT 300
  • the pay network server may provide payment
  • the value-add server may provide a service
  • the client may display, e.g., 712, the input request
  • the user may provide input into the client, e.g., is 713, and the client may generate a service input response for the value-add server.
  • the client may generate a service input response for the value-add server.
  • the value-add server may provide value-add services according to
  • the value-add server may generate a value-add service response, e.g., 717, and
  • 25 server may extract the enrollment service data from the response for addition to a
  • 28 server may obtain the card authorization request from the acquirer server, and may
  • the pay network server may generate a query, e.g.,
  • the pay network database may provide, e.g., 722, the requested issuer server data to the pay network server.
  • the pay network server may utilize the issuer server data to generate a forwarding card authorization request, e.g., 723, to redirect the card authorization request from the acquirer server to the issuer server.
  • the pay network server may provide the card authorization request to the issuer server.
  • the issuer server may parse, e.g., 724, the card authorization request, and based on the request details may query a database, e.g., 725, for data of the user's card account.
  • the database may provide the requested user data.
  • the issuer server may determine whether the user can pay for the transaction using funds available in the account, e.g., 726. For example, the issuer server may determine whether the user has a sufficient balance remaining in the account, sufficient credit associated with the account, and/or the like, but comparing the data from the database with the transaction cost obtained from the card authorization request. If the issuer server determines that the user can pay for the transaction using the funds available in the account, the server may provide an authorization message, e.g., 727, to the pay network server. [0099] In some implementations, the pay network server may obtain the authorization message, and parse the message to extract authorization details.
  • the pay network server may extract the transaction card from the authorization message and/or card authorization request, e.g., 733, and generate a transaction data record using the card transaction details.
  • the pay network server may provide the transaction data record for storage, e.g., 734, to a database.
  • the pay network server may forward the authorization message, e.g., 735, to the acquirer server, which may in turn forward the authorization message, e.g., 736, to the merchant server.
  • the merchant may obtain the authorization message, and parse the authorization message o extract its contents, e.g., 737.
  • the merchant server may determine whether the user possesses sufficient funds in the card account to conduct the transaction. If the merchant server determines that the user possess sufficient funds, e.g., 738, option "Yes,” the merchant server may add the record of the transaction for the user to a batch of transaction data relating to authorized transactions, e.g., 739-740. The merchant server may also generate a purchase receipt, e.g., 741, for the user. If the merchant server determines that the user does not possess sufficient funds, e.g., 738, option "No,” the merchant server may generate an "authorization fail” message, e.g., 742. The merchant server may provide the purchase receipt or the "authorization fail" message to the client.
  • the merchant server may add the record of the transaction for the user to a batch of transaction data relating to authorized transactions, e.g., 739-740.
  • the merchant server may also generate a purchase receipt, e.g., 741, for the user. If the merchant server determines that the user does not
  • the client may render and display, e.g., 743, the purchase receipt for the user.
  • the merchant server may initiate clearance of a batch of authorized transactions by generating a batch data request, e.g., 744, and providing the request to a database.
  • the database may provide the requested batch data, e.g., 745, to the merchant server.
  • the server may generate a batch clearance request, e.g., 746, using the batch data obtained from the database, and provide the batch clearance request to an acquirer server.
  • the acquirer server may generate, e.g., 748, a batch payment request using the obtained batch clearance request, and provide the batch payment request to a pay network server.
  • the pay network server may parse, e.g., 749, the batch payment request, select a transaction stored within the batch data, e.g., 750, and extract the transaction data for the transaction stored in the batch payment request, e.g., 751.
  • the pay network server may generate a transaction data record, e.g., 752, and store the transaction data, e.g., 753, the transaction in a database.
  • the pay network server may generate an issuer server query, e.g., 754, for an address of an issuer server maintaining the account of the user requesting the transaction.
  • the pay network server may provide the query to a database.
  • the database may provide the issuer server data requested by the pay network server, e.g., 755.
  • the pay network server may generate an individual payment request, e.g., 756, for the transaction for which it has extracted transaction data, and provide the individual payment request to the issuer server using the issuer server data from the database.
  • the issuer server may obtain the individual payment request, and parse, e.g., 757, the individual payment request to extract details of the request. Based on the extracted data, the issuer server may generate a payment command, e.g., 758. For example, the issuer server may issue a command to deduct funds from the user's account (or add a charge to the user's credit card account).
  • the issuer server may issue a payment command, e.g., 759, to a database storing the user's account information.
  • the database may update a data record corresponding to the user's account to reflect the debit / charge made to the user's account.
  • the issuer server may provide a funds transfer message, e.g., 760, to the pay network server after the payment command has been executed by the database.
  • the pay network server may check whether there are additional transactions in the batch that need to be cleared and funded. If there are additional transactions, e.g., 761, option "Yes," the pay network server may process each transaction according to the procedure described above.
  • the pay network server may generate, e.g., 762, an aggregated funds transfer message reflecting transfer of all transactions in the batch, and provide, e.g., 763, the funds transfer message to the acquirer server.
  • the acquirer server may, in response, transfer the funds specified in the funds transfer message to an account of the merchant, e.g., 764.
  • FIGURE 8 shows a data flow diagram illustrating an example procedure to aggregate card-based transaction data in some embodiments of the MMCDB.
  • the pay network server may determine a scope of data aggregation required to perform the analysis, e.g., 811.
  • the pay network server may initiate data aggregation based on the determined scope.
  • the pay network server may generate a query for addresses of server storing transaction data within the determined scope.
  • the pay network server may query, e.g., 812, a pay network database, e.g., 807a, for addresses of pay network servers that may have stored transaction data within the determined scope of the data aggregation.
  • the pay network server may utilize PHP/SQL commands similar to the examples provided above.
  • the database may provide, e.g., 813, a list of server addresses in response to the pay network server's query.
  • the pay network server may generate transaction data requests, e.g., 814.
  • the pay network server may issue the generated transaction data requests, e.g., 8isa-c, to the other pay network servers, e.g., 8osb-d.
  • the other pay network servers may query, e.g., 8i7a-c, their pay network database, e.g., 8o7a-d, for transaction data falling within the scope of the transaction data requests.
  • the pay network databases may provide transaction data, e.g., 8i8a-c, to the other pay network servers.
  • the other pay network servers may return the transaction data obtained from the pay network databases, e.g., 8i9a-c, to the pay network server making the transaction data requests, e.g., 805a.
  • the pay network server e.g., 805a, may store the aggregated transaction data, e.g., 820, in an aggregated transactions database, e.g., 810a.
  • FIGURE 9 shows a logic flow diagram illustrating example aspects of aggregating card-based transaction data in some embodiments of the MMCDB, e.g., a Transaction Data Aggregation ("TDA") component 900.
  • TDA Transaction Data Aggregation
  • a pay network server may obtain a trigger to aggregate transaction data, e.g., 901.
  • the server may be configured to initiate transaction data aggregation on a regular, periodic, basis (e.g., hourly, daily, weekly, monthly, quarterly, semi-annually, annually, etc.).
  • the server may be configured to initiate transaction data aggregation on obtaining information that the U.S. Government (e.g., Department of Commerce, Office of Management and Budget, etc) has released new statistical data related to the U.S. business economy.
  • the server may be configured to initiate transaction data aggregation on-demand, upon obtaining a user investment strategy analysis request for processing.
  • the pay network server may determine a scope of data aggregation required to perform the analysis, e.g., 902. For example, the scope of data aggregation may be pre-determined.
  • the scope of data aggregation may be determined based on a received user investment strategy analysis request.
  • the pay network server may initiate data aggregation based on the determined scope.
  • the pay network server may generate a query for addresses of server storing transaction data within the determined scope, e.g., 903.
  • the pay network server may query a database for addresses of pay network servers that may have stored transaction data within the determined scope of the data aggregation.
  • the database may provide, e.g., 904, a list of server addresses in response to the pay network server's query. Based on the list of server addresses, the pay network server may generate transaction data requests, e.g., 905.
  • the pay network server may issue the generated transaction data requests to the other pay network servers.
  • the other pay network servers may obtain and parse the transaction data requests, e.g., 906. Based on parsing the data requests, the other pay network servers may generate transaction data queries, e.g., 907, and provide the transaction data queries to their pay network databases. In response to the transaction data queries, the pay network databases may provide transaction data, e.g., 908, to the other pay network servers. The other pay network servers may return, e.g., 909, the transaction data obtained from the pay network databases to the pay network server making the transaction data requests. The pay network server may generate aggregated transaction data records from the transaction data received from the other pay network servers, e.g., 910, and store the aggregated transaction data in a database, e.g., 911.
  • a database e.g., 911.
  • FIGURE 10 shows a data flow diagram illustrating an example social data aggregation procedure in some embodiments of the MMCDB.
  • the pay network server may obtain a trigger to perform a social data search.
  • the pay network server may periodically perform an update of its aggregated social database, e.g., 1010, with new information available from a variety of sources, such as the social networking services operating on the Internet.
  • a request for on-demand social data update may be obtained as a result of a user wishing to enroll in a service, for which the pay network server may facilitate data entry by providing an automated web form filling system using information about the user obtained from the social data update.
  • the pay network server may parse the trigger to extract keywords using which to perform an aggregated social data update.
  • the pay network server may generate a query for application programming interface (API) templates for various social networking services (e.g., Facebook®, TwitterTM, etc.) from which to collect social data for aggregation.
  • API application programming interface
  • the pay network server may query, e.g., 1012, a pay network database, e.g., 1007, for social network API templates for the social networking services.
  • the pay network server may utilize PHP/SQL commands similar to the examples provided above.
  • the database may provide, e.g., 1013, a list of API templates in response.
  • the pay network server may generate social data requests, e.g., 1014.
  • the pay network server may issue the generated social data requests, e.g., ioi5a-c, to the social network servers, e.g., looia-c.
  • the pay network server may issue PHP commands to request the social network servers for social data.
  • An example listing of commands to issue social data requests ioi5a-c, substantially in the form of PHP commands, is provided below: ⁇ ? PH P
  • $result mysql_query (' SELECT * FROM content WHERE uid IN ('
  • the social network servers may query, e.g., ioi7a-c, their databases, e.g., i002a-c, for social data results falling within the scope of the social keywords.
  • the databases may provide social data, e.g., ioi8a-c, to the search engine servers.
  • the social network servers may return the social data obtained from the databases, e.g., ioi9a-c, to the pay network server making the social data requests.
  • An example listing of social data ioi9a-c, substantially in the form of JavaScript Object Notation (JSON)-formatted data, is provided below: [ "data": [
  • the pay network server may store the aggregated
  • search results e.g., 1020
  • an aggregated search database e.g., 1010a.
  • FIGURE 11 shows a logic flow diagram illustrating example aspects of
  • the pay network 9 Aggregation (“SDA") component 1100.
  • the pay network 9 Aggregation (“SDA") component 1100.
  • the pay network 9 Aggregation (“SDA") component 1100.
  • 10 server may obtain a trigger to perform a social search, e.g., 1101. For example, the pay
  • 11 network server may periodically perform an update of its aggregated social database
  • a request for on-demand social data update may be obtained as a
  • the pay network server may parse the trigger, e.g., 1102, to extract
  • the pay network server may determine the social networking services to search, e.g., Facebook, Twitter, etc.
  • the pay network server 20 1103, using the extracted keywords and/or user ID(s). Then, the pay network server
  • API application programming interface
  • the pay network server may query, e.g.,
  • the pay network server may utilize PHP/SQL commands similar to the pay network server.
  • the database may provide, e.g., 1105, a list of API
  • the pay network server may
  • the pay network server may issue the
  • the social network 29 generated social data requests to the social networking services.
  • 30 servers may parse the obtained search results(s), e.g., 1107, and query, e.g., 1108, their
  • the databases may provide social data, e.g., 1109, to the social networking servers.
  • the social networking servers may return the social data obtained from the databases, e.g., 1110, to the pay network server making the social data requests.
  • the pay network server may generate, e.g., 1111, and store the aggregated social data, e.g., 1112, in an aggregated social database.
  • FIGURE 12 shows a data flow diagram illustrating an example procedure for enrollment in value-add services in some embodiments of the MMCDB.
  • a user e.g., 1201
  • the user desires to enroll in social network authenticated purchase payment as a value-added service. It is to be understood that any other value- added service may take the place of the below-described value-added service.
  • the user may communicate with a pay network server, e.g., 1203, via a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 1202).
  • the user may provide user input, e.g., enroll input 1211, into the client indicating the user's desire to enroll in social network authenticated purchase payment.
  • the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch- sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like.
  • the user may swipe a payment card at the client 1202.
  • the client may obtain track 1 data from the user's card as enroll input 1211 (e.g., credit card, debit card, prepaid card, charge card, etc.), such as the example track 1 data provided below:
  • the client may generate an enrollment request, e.g., 1212, and provide the enrollment request, e.g., 1213, to the pay network server.
  • the client may provide a (Secure) Hypertext Transfer Protocol ("HTTP(S)”) POST message including data formatted according to the extensible Markup Language (“XML").
  • HTTP(S) POST message including an XML-formatted enrollment request for the pay network server:
  • the pay network server may obtain the enrollment request from the client, and extract the user's payment detail (e.g., XML data) from the enrollment request.
  • the pay network server may utilize a parser such as the example parsers described below in the discussion with reference to FIGURE 49.
  • the pay network server may query, e.g., 1214, a pay network database, e.g., 1204, to obtain a social network request template, e.g., 1215, to process the enrollment request.
  • the social network request template may include instructions, data, login URL, login API call template and/or the like for facilitating social network authentication.
  • the database may be a relational database responsive to Structured Query Language ("SQL”) commands.
  • the merchant server may execute a hypertext preprocessor ("PHP") script including SQL commands to query the database for product data.
  • PHP/SQL command listing illustrating substantive aspects of querying the database, e.g., 1214-1215, is provided below:
  • $query "SELECT template FROM EnrollTable WHERE network LIKE '%' $socialnet"
  • $result mysql query ( $query) ; // perform the search query
  • the pay network server may redirect the client to a social network server by providing a HTTP(S) REDIRECT 300 message, similar to the example below:
  • the pay network server may provide payment information extracted from the card authorization request to the social network server as part of a social network authentication enrollment request, e.g., 1217.
  • the pay network server may provide a HTTP(S) POST message to the social network server, similar to the example below:
  • the social network server may provide a social
  • the social network server 19 network login request, e.g., 1218, to the client.
  • the social network server 19 network login request, e.g., 1218, to the client.
  • the social network server 19 network login request, e.g., 1218, to the client.
  • the social network server 19 network login request, e.g., 1218, to the client.
  • the social network server 19 network login request, e.g., 1218.
  • the client 20 may provide a HTML input form to the client.
  • the client may display, e.g., 1219, the
  • the user may provide login input into
  • the client e.g., 1220
  • the client may generate a social network login response, e.g.,
  • the social network server 23 1221, for the social network server.
  • the social network server 23 1221, for the social network server.
  • the social network server may generate an
  • the pay network server may generate, e.g., 1225, a user enrollment data record, and store the enrollment data record in a pay network database, e.g., 1226, to complete enrollment.
  • the enrollment data record may include the information from the enrollment notification 1224.
  • FIGURE 13 shows a logic flow diagram illustrating example aspects of enrollment in a value-added service in some embodiments of the MMCDB, e.g., a Value- Add Service Enrollment ("VASE") component 1300.
  • VASE Value- Add Service Enrollment
  • a user e.g., 1201
  • a user may desire to enroll in a value-added service.
  • the user desires to enroll in social network authenticated purchase payment as a value-added service. It is to be understood that any other value-added service may take the place of the below-described value-added service.
  • the user may communicate with a pay network server via a client. For example, the user may provide user input, e.g., 1301, into the client indicating the user's desire to enroll in social network authenticated purchase payment.
  • the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC enabled hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch- sensitive interface, touching user interface elements on a touch-sensitive display, and/or the like.
  • the client may generate an enrollment request, e.g., 1302, and provide the enrollment request to the pay network server.
  • the MMCDB may provide an enrollment button which may take the user to an enrollment webpage where account info may be entered into web form fields.
  • the pay network server may obtain the enrollment request from the client, and extract the user's payment detail from the enrollment request.
  • the pay network server may utilize a parser such as the example parsers described below in the discussion with reference to FIGURE 49.
  • the pay network server may query, e.g., 1304, a pay network database to obtain a social network request template, e.g., 1305, to process the enrollment request.
  • the social network request template may include instructions, data, login URL, login API call template and/or the like for facilitating social network authentication.
  • the pay network server may provide payment information extracted from the card authorization request to the social network server as part of a social network authentication enrollment request, e.g., 1306.
  • the social network server may provide a social network login request, e.g., 1307, to the client.
  • the social network server may provide a HTML input form to the client.
  • the client may display, e.g., 1308, the login form for the user.
  • the user may provide login input into the client, e.g., 1309, and the client may generate a social network login response for the social network server.
  • the social network server may authenticate the login credentials of the user, and access payment account information of the user stored within the social network, e.g., in a social network database.
  • the social network server may generate an authentication data record for the user, e.g., 1311, and provide an enrollment notification to the pay network server, e.g., 1313.
  • the pay network server may generate, e.g., 1314, a user enrollment data record, and store the enrollment data record in a pay network database, e.g., 1315, to complete enrollment.
  • the pay network server may provide an enrollment confirmation, and provide the enrollment confirmation to the client, which may display, e.g., 1317, the confirmation for the user.
  • FIGURES 14A-B show flow diagrams illustrating example aspects of normalizing aggregated search, enrolled, service usage, transaction and/or other aggregated data into a standardized data format in some embodiments of the MMCDB, e.g., a Aggregated Data Record Normalization ("ADRN") component 1400.
  • a pay network server may attempt to convert any aggregated data records stored in an aggregated records database it has access to in a normalized data format.
  • the database may have a transaction data record template with predetermined, standard fields that may store data in pre-defined formats (e.g., long integer / double float / 4 digits of precision, etc.) in a pre-determined data structure.
  • pre-defined formats e.g., long integer / double float / 4 digits of precision, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne des systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples (MMCDB) qui transforment des données agrégées provenant de diverses ressources informatiques à l'aide de composants de MMCDB en graphiques sociaux et/ou profils d'entrées mis à jour. La MMCDB agrège les enregistrements de données, comprenant des résultats de recherche, des données de transaction d'achats, des données d'utilisation de service, des données d'inscription à des services et des données sociales. Elle identifie les types de champs de données dans les enregistrements de données et leurs valeurs de données associées. D'après les types de champs de données et leurs valeurs de données associées, la MMCDB identifie une entité. La MMCDB génère des corrélations de l'entité avec d'autres entités pouvant être identifiées d'après les types de champs de données et leurs valeurs de données associées. Elle associe des attributs à l'entité en tirant des conclusions par rapport à l'entité, d'après les types de champs de données et les valeurs de données associées. Grâce aux corrélations générées et aux attributs associés, la MMCDB génère un graphique social et un profil mis à jour de l'entité. Elle produit le graphique social et le profil à jour pour une requête de remplissage de formulaire Web automatique.
EP13742884.3A 2012-02-02 2013-02-02 Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples Withdrawn EP2810242A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261594063P 2012-02-02 2012-02-02
US13/520,481 US10223691B2 (en) 2011-02-22 2012-02-22 Universal electronic payment apparatuses, methods and systems
PCT/US2013/024538 WO2013116806A1 (fr) 2012-02-02 2013-02-02 Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples

Publications (2)

Publication Number Publication Date
EP2810242A1 true EP2810242A1 (fr) 2014-12-10
EP2810242A4 EP2810242A4 (fr) 2016-02-24

Family

ID=48905934

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13742884.3A Withdrawn EP2810242A4 (fr) 2012-02-02 2013-02-02 Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples

Country Status (3)

Country Link
EP (1) EP2810242A4 (fr)
SG (1) SG11201404555WA (fr)
WO (1) WO2013116806A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140278731A1 (en) * 2013-03-15 2014-09-18 Cresco Ag, Llc System and Method for Agricultural Risk Management
US10242351B1 (en) 2014-05-07 2019-03-26 Square, Inc. Digital wallet for groups
US10026083B1 (en) 2014-05-11 2018-07-17 Square, Inc. Tab for a venue
US9626408B2 (en) 2014-06-09 2017-04-18 International Business Machines Corporation Adapting a relational query to accommodate hierarchical data
US10796238B2 (en) * 2016-04-07 2020-10-06 Cognitive Scale, Inc. Cognitive personal assistant
US10733518B2 (en) * 2016-04-07 2020-08-04 Cognitive Scale, Inc. Cognitive personal procurement assistant
CN107679868B (zh) * 2017-09-15 2020-02-21 平安科技（深圳）有限公司 权益信息管理方法、装置、设备及计算机可读存储介质
CN109918639B (zh) * 2018-12-13 2024-02-13 北京海致星图科技有限公司 一种基于深度学习技术和规则库的银行授信文本解析方法
CN111429218B (zh) * 2020-03-22 2024-05-24 沈阳林科信息技术有限公司 一种基于新零售电商商品汇聚与开放的方法
CN111581498A (zh) * 2020-04-21 2020-08-25 北京龙云科技有限公司 一种广告用户偏好分析方法及装置
CN113094441A (zh) * 2021-04-29 2021-07-09 支付宝(杭州)信息技术有限公司 数据同步方法以及装置
CN113127413B (zh) * 2021-05-12 2024-03-01 北京红山信息科技研究院有限公司 一种运营商数据处理方法、装置、服务器及存储介质
CN113395269B (zh) * 2021-06-04 2023-02-17 上海浦东发展银行股份有限公司 一种数据交互方法、装置
CN113643090B (zh) * 2021-07-09 2024-03-19 上海瀚之友信息技术服务有限公司 一种进行卡密批量发放的系统和方法
US20230052480A1 (en) * 2021-08-12 2023-02-16 International Business Machines Corporation System and method for reducing feature calculations
CN115018473A (zh) * 2022-08-03 2022-09-06 平安银行股份有限公司 一种业务处理方法、装置、存储介质及设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002355530A1 (en) * 2001-08-03 2003-02-24 John Allen Ananian Personalized interactive digital catalog profiling
US7047251B2 (en) * 2002-11-22 2006-05-16 Accenture Global Services, Gmbh Standardized customer application and record for inputting customer data into analytic models
US20040111698A1 (en) * 2002-12-06 2004-06-10 Anew Technology Corporation System and method for design, development, and deployment of distributed applications that share data from heterogeneous and autonomous sources over the Web
US20080288889A1 (en) * 2004-02-20 2008-11-20 Herbert Dennis Hunt Data visualization application
US20070106627A1 (en) * 2005-10-05 2007-05-10 Mohit Srivastava Social discovery systems and methods
US8494978B2 (en) * 2007-11-02 2013-07-23 Ebay Inc. Inferring user preferences from an internet based social interactive construct
US20090307060A1 (en) * 2008-06-09 2009-12-10 Merz Christopher J Methods and systems for determining a loyalty profile for a financial transaction cardholder
US20100057548A1 (en) * 2008-08-27 2010-03-04 Globy's,Inc. Targeted customer offers based on predictive analytics
US20110099507A1 (en) * 2009-10-28 2011-04-28 Google Inc. Displaying a collection of interactive elements that trigger actions directed to an item

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system

Also Published As

Publication number Publication date
WO2013116806A1 (fr) 2013-08-08
SG11201404555WA (en) 2014-08-28
EP2810242A4 (fr) 2016-02-24

Similar Documents

Publication Publication Date Title
US10983960B2 (en) Multi-source, multi-dimensional, cross-entity, multimedia centralized personal information database platform apparatuses, methods and systems
US11727392B2 (en) Multi-purpose virtual card transaction apparatuses, methods and systems
EP2810242A1 (fr) Systèmes, procédés et appareils pour plate-forme de base de données multimédia, à entrées croisées, dimensions multiples et sources multiples
US20130290234A1 (en) Intelligent Consumer Service Terminal Apparatuses, Methods and Systems
US20190244192A1 (en) Universal electronic payment apparatuses, methods and systems
US20130159081A1 (en) Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems
US20170017936A1 (en) Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20130024364A1 (en) Consumer transaction leash control apparatuses, methods and systems
US20170017955A1 (en) Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20110218838A1 (en) Econometrical investment strategy analysis apparatuses, methods and systems
WO2013192443A1 (fr) Systèmes, procédés et appareils de terminal de service de consommateur intelligent
WO2014011691A1 (fr) Appareils, procédés et systèmes de transactions par cartes virtuelles multi-usages
WO2013009660A1 (fr) Appareils, procédés et systèmes de plate-forme d'incitation ciblée et à notifications réduisant la largeur de bande bidirectionnelle
WO2013044175A1 (fr) Appareils, procédés et systèmes de contrôle et de limitation des transactions des consommateurs
US20170249684A1 (en) Systems and methods for search term prioritization
US11138238B2 (en) Method, system, and computer program product for managing source identifiers of clustered records
US20230205743A1 (en) Security control framework for an enterprise data management platform
US20230205742A1 (en) Data quality control in an enterprise data management platform
US20230205741A1 (en) Enterprise data management platform
WO2023121934A1 (fr) Contrôle de qualité de données dans une plate-forme de gestion de données d'entreprise

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140901

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 30/06 20120101ALI20151001BHEP

Ipc: G06Q 10/00 20120101AFI20151001BHEP

RA4 Supplementary search report drawn up and despatched (corrected)

Effective date: 20160125

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 10/00 20120101AFI20160119BHEP

Ipc: G06Q 30/06 20120101ALI20160119BHEP

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160823