WO2013192443A1 - Systèmes, procédés et appareils de terminal de service de consommateur intelligent - Google Patents

Systèmes, procédés et appareils de terminal de service de consommateur intelligent Download PDF

Info

Publication number
WO2013192443A1
WO2013192443A1 PCT/US2013/046875 US2013046875W WO2013192443A1 WO 2013192443 A1 WO2013192443 A1 WO 2013192443A1 US 2013046875 W US2013046875 W US 2013046875W WO 2013192443 A1 WO2013192443 A1 WO 2013192443A1
Authority
WO
WIPO (PCT)
Prior art keywords
solution
service request
remote terminal
service
data
Prior art date
Application number
PCT/US2013/046875
Other languages
English (en)
Inventor
Theodore Harris
Patrick Faith
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
Priority claimed from PCT/US2013/024538 external-priority patent/WO2013116806A1/fr
Priority claimed from US13/758,900 external-priority patent/US20130204886A1/en
Application filed by Visa International Service Association filed Critical Visa International Service Association
Priority to AU2013277083A priority Critical patent/AU2013277083A1/en
Publication of WO2013192443A1 publication Critical patent/WO2013192443A1/fr

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • 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/085—Payment architectures involving remote charge determination or related payment 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network 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/306—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using TV related infrastructures
    • 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/308—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using the Internet of Things
    • 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
    • G06Q20/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable 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/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
    • G06Q20/322—Aspects of commerce using mobile devices [M-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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • 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/384—Payment protocols; Details thereof using social networks
    • 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
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • 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]
    • G06Q30/0639—Item locations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • the present innovations are directed generally to financial service terminal apparatuses, and more particularly, to INTELLIGENT CONSUMER SERVICE TERMINAL APPARATUSES, METHODS AND SYSTEMS.
  • autonomous technology has been developed to assist humans in a variety of task operations.
  • autonomous robots may be designed to perform tasks in dangerous environments, such as space probes and roadside bombs diffusion.
  • robots are also designed for home use to perform vacuum cleaning, floor washing and lawn mowing.
  • FIGURES 1A-1G show block diagrams illustrating example applications of ICST robots within various embodiments of the ICST;
  • FIGURES 2A-2B provide data flow diagrams illustrating data flows between ICST entities within various embodiments of the ICST;
  • FIGURE 2C provides a block diagram illustrating infrastructure of the ICST within various embodiments of the ICST;
  • FIGURES 3A-3C show logic flow diagrams illustrating various embodiments of the ICST
  • FIGURES 4A-4C provide exemplary user interface diagrams illustrating providing solutions to a consumer via the ICST within embodiments of the ICST;
  • FIGURES 5A-5B provide example block diagrams illustrating example component structure of ICST components in the form of ICST wearable jewelry within embodiments of the ICST;
  • FIGURES 6A-6B provide example block diagrams illustrating example component structure and use cases of ICST quadrocopter examples within embodiments of the ICST;
  • FIGURES 6C-6D provide example block diagrams illustrating example component structure of ICST robot cleaners within embodiments of the ICST;
  • FIGURE 7 shows a block diagram illustrating example aspects of a centralized personal information platform in some embodiments of the ICST
  • FIGURES 8A-F show block diagrams illustrating example aspects of data models within a centralized personal information platform in some embodiments of the ICST;
  • FIGURE 9 shows a block diagram illustrating example ICST component configurations in some embodiments of the ICST.
  • FIGURE 10 shows a data flow diagram illustrating an example search result aggregation procedure in some embodiments of the ICST
  • FIGURE 11 shows a logic flow diagram illustrating example aspects of aggregating search results in some embodiments of the ICST, e.g., a Search Results Aggregation ("SRA") component 500;
  • SRA Search Results Aggregation
  • FIGURES 12A-D show data flow diagrams illustrating an example card- based transaction execution procedure in some embodiments of the ICST;
  • FIGURES 13A-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 ICST, e.g., a Card-Based Transaction Execution ("CTE") component 1300;
  • CTE Card-Based Transaction Execution
  • FIGURE 14 shows a data flow diagram illustrating an example procedure to aggregate card-based transaction data in some embodiments of the ICST;
  • FIGURE 15 shows a logic flow diagram illustrating example aspects of aggregating card-based transaction data in some embodiments of the ICST, e.g., a Transaction Data Aggregation ("TDA") component 1500;
  • TDA Transaction Data Aggregation
  • FIGURE 16 shows a data flow diagram illustrating an example social data aggregation procedure in some embodiments of the ICST
  • FIGURE 17 shows a logic flow diagram illustrating example aspects of aggregating social data in some embodiments of the ICST, e.g., a Social Data Aggregation (“SDA”) component 1700;
  • SDA Social Data Aggregation
  • FIGURE 18 shows a data flow diagram illustrating an example procedure for enrollment in value-add services in some embodiments of the ICST;
  • FIGURE 19 shows a logic flow diagram illustrating example aspects of social network payment authentication enrollment in some embodiments of the ICST, e.g., a Value-Add Service Enrollment ("VASE") component 1900;
  • VASE Value-Add Service Enrollment
  • FIGURES 20A-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 ICST, e.g., a Aggregated Data Record Normalization ("ADRN") component 2000;
  • ADRN Aggregated Data Record Normalization
  • FIGURE 21 shows a logic flow diagram illustrating example aspects of recognizing data fields in normalized aggregated data records in some embodiments of the ICST, e.g., a Data Field Recognition ("DFR") component 2100;
  • DFR Data Field Recognition
  • FIGURE 22 shows a logic flow diagram illustrating example aspects of classifying entity types in some embodiments of the ICST, e.g., an Entity Type Classification ("ETC") component 2200;
  • ETC Entity Type Classification
  • FIGURE 23 shows a logic flow diagram illustrating example aspects of identifying cross-entity correlation in some embodiments of the ICST, e.g., a Cross- Entity Correlation ("CEC") component 2300;
  • CEC Cross- Entity Correlation
  • FIGURE 24 shows a logic flow diagram illustrating example aspects of associating attributes to entities in some embodiments of the ICST, e.g., an Entity Attribute Association (“EAA”) component 2400;
  • EAA Entity Attribute Association
  • FIGURE 25 shows a logic flow diagram illustrating example aspects of updating entity profile-graphs in some embodiments of the ICST, e.g., an Entity Profile- Graph Updating ("EPGU") component 2500;
  • EPGU Entity Profile- Graph Updating
  • FIGURE 26 shows a logic flow diagram illustrating example aspects of generating search terms for profile-graph updating in some embodiments of the ICST, e.g., a Search Term Generation ("STG") component 2600;
  • STG Search Term Generation
  • FIGURES 27A-E show user interface diagrams illustrating example features of user interfaces for an electronic virtual wallet in some embodiments of the ICST;
  • FIGURE 28 shows a block diagram illustrating example aspects of a merchant analytics platform in some embodiments of the ICST
  • FIGURES 29A-B show data flow diagrams illustrating an example procedure to provide a user and/or merchant offers for products, services and/or the like, using user behavior patterns derived from card-based transaction data in some embodiments of the ICST;
  • FIGURE 30 shows a logic flow diagram illustrating example aspects of providing a user and/or merchant offers for products, services and/or the like, using user behavior patterns derived from card-based transaction data in some embodiments of the ICST, e.g., a Merchant Analytics ("MA") component;
  • MA Merchant Analytics
  • FIGURE 31 shows a logic flow diagram illustrating example aspects of generating a user behavior pattern analysis in some embodiments of the ICST, e.g., a User Behavioral Pattern Analytics ("UBPA”) component;
  • UBA User Behavioral Pattern Analytics
  • FIGURE 32 shows a logic flow diagram illustrating example aspects of identifying user behavioral patterns from aggregated card-based transaction data in some embodiments of the ICST, e.g., a User Patten Identification (“UPI”) component;
  • UPI User Patten Identification
  • FIGURES 33A-B show block diagrams illustrating example aspects of merchant analytics in a second set of embodiments of the ICST;
  • FIGURES 34A-C show data flow diagrams illustrating an example procedure for econometrical analysis of a proposed investment strategy based on card- based transaction data in some embodiments of the ICST;
  • FIGURE 35 shows a logic flow diagram illustrating example aspects of normalizing raw card-based transaction data into a standardized data format in some embodiments of the ICST, e.g., a Transaction Data Normalization ("TDN”) component;
  • TDN Transaction Data Normalization
  • FIGURE 36 shows a logic flow diagram illustrating example aspects of generating classification labels for card-based transactions in some embodiments of the ICST, e.g., a Card-Based Transaction Classification ("CTC") component;
  • CTC Card-Based Transaction Classification
  • FIGURE 37 shows a logic flow diagram illustrating example aspects of filtering card-based transaction data for econometrical investment strategy analysis in some embodiments of the ICST, e.g., a Transaction Data Filtering ("TDF") component;
  • TDF Transaction Data Filtering
  • FIGURE 38 shows a logic flow diagram illustrating example aspects of anonymizing consumer data from card-based transactions for econometrical investment strategy analysis in some embodiments of the ICST, e.g., a Consumer Data Anonymization ("CDA") component;
  • CDA Consumer Data Anonymization
  • FIGURES 39A-B show logic flow diagrams illustrating example aspects of econometrically analyzing a proposed investment strategy based on card-based transaction data in some embodiments of the ICST, e.g., an Econometrical Strategy Analysis ("ESA”) component;
  • ESA Econometrical Strategy Analysis
  • FIGURE 40 shows a logic flow diagram illustrating example aspects of reporting business analytics derived from an econometrical analysis based on card- based transaction data in some embodiments of the ICST, e.g., a Business Analytics Reporting ("BAR") component;
  • BAR Business Analytics Reporting
  • FIGURE 41 shows a logic flow diagram illustrating example aspects of sharing an analytical model generated using data acquired using the centralized personal information platform in some embodiments of the ICST, e.g., an Analytical Model Sharing ("AMS") component;
  • AMS Analytical Model Sharing
  • FIGURE 42 shows a logic flow diagram illustrating example aspects of a metadata based interpretation engine of the ICST that generates standardized encryptmatics XML from structured data obtained from various sources via the centralized personal information platform, e.g., an Encryptmatics XML Converter ("EXC”) component;
  • EXC Encryptmatics XML Converter
  • FIGURE 43 shows a data flow diagram illustrating an example email data aggregation procedure, in one embodiment of the ICST
  • FIGURE 44 shows a block diagram illustrating an example distributed linking node mesh, in one embodiment of the ICST
  • FIGURES 45A-F show a block diagram illustrating an example distributed linking node mesh search, in one embodiment of the ICST;
  • FIGURES 46A-C show a block diagram illustrating an example distributed linking node mesh index creation, in one embodiment of the ICST;
  • FIGURE 47 shows a logic flow illustrating an example Encryptmatics XML Converter component, in one embodiment of the ICST;
  • FIGURE 48 shows a logic flow illustrating input language loading by an Encryptmatics XML Converter component, in one embodiment of the ICST;
  • FIGURES 49A-B show a logic flow illustrating input model conversion by an Encryptmatics XML Converter component, in one embodiment of the ICST;
  • FIGURE 50 shows a block diagram illustrating aspects of a tumblar data source manipulation / anonymization component, e.g., a TDS component, in one embodiment of the ICST;
  • a tumblar data source manipulation / anonymization component e.g., a TDS component
  • FIGURE 51 shows a logic flow diagram illustrating an example tumblar data source manipulation / anonymization component, in one embodiment of the ICST;
  • FIGURE 52 shows an example data flow illustrating mesh aggregation and cluster querying, in one embodiment of a ICST
  • FIGURE 53 shows an example logic flow illustrating cluster response analysis and transaction triggering, in one embodiment of a ICST
  • FIGURE 54A-C illustrate an example ICST application embodiment, in one embodiment of the ICST
  • FIGURE 55 shows a block diagram illustrating example embodiments of the ICST
  • FIGURE 56 shows a data flow diagram illustrating collecting information for predictive shopping lists in some embodiments of the ICST
  • FIGURE 57 shows a data flow diagram illustrating collecting receipt information for predictive shopping lists in some embodiments of the ICST
  • FIGURES 58a-c show logic flow diagrams illustrating parsing receipts and generating predictive shopping lists in some embodiments of the ICST;
  • FIGURE 59 shows a logic flow diagram illustrating obtaining electronic receipts in some embodiments of the ICST
  • FIGURE 60 shows a data flow diagram illustrating collecting code information for predictive shopping lists in some embodiments of the ICST
  • FIGURE 61 shows a logic flow diagram illustrating collecting code information for predictive shopping lists in some embodiments of the ICST
  • FIGURE 62 shows a data flow diagram illustrating collecting snap purchase information for predictive shopping lists in some embodiments of the ICST
  • FIGURE 63 shows a logic flow diagram illustrating collecting snap purchase information for predictive shopping lists in some embodiments of the ICST
  • FIGURE 64 shows a block diagram illustrating using predictive shopping lists with a smart shopping cart in some embodiments of the ICST;
  • FIGURES 65a-b show data flow diagrams illustrating using predictive shopping lists with a smart shopping cart in some embodiments of the ICST;
  • FIGURES 66a-b show logic flow diagrams illustrating using predictive shopping lusts with a smart shopping cart in some embodiments of the ICST;
  • FIGURE 67 shows a data flow diagram illustrating providing predictive shopping list feedback in some embodiments of the ICST
  • FIGURE 68 shows a data flow diagram illustrating receiving predictive shopping list feedback from other users in some embodiments of the ICST
  • FIGURE 69 shows a logic flow diagram illustrating receiving feedback for predictive shopping list in some embodiments of the ICST
  • FIGURE 70 shows a block diagram illustrating notifying users of nearby merchants with items on predictive shopping list in some embodiments of the ICST;
  • FIGURE 71 shows a data flow diagram illustrating notifying users of nearby merchants with items on predictive shopping list in some embodiments of the ICST;
  • FIGURES 72a-b show logic flow diagrams illustrating notifying users of nearby merchants with items on predictive shopping list in some embodiments of the ICST;
  • FIGURE 73 shows a block diagram illustrating a PoS checkout code in some embodiments of the ICST.
  • FIGURE 74 shows a block diagram illustrating embodiments of a ICST controller
  • the INTELLIGENT CONSUMER SERVICE TERMINAL APPARATUSES, METHODS AND SYSTEMS provides a learning mechanism for intelligent consumer service terminals to automatically download knowledge from a cloud database to build new solutions.
  • robots and other autonomous systems may have confined memory and processing unit tied to their physical unit, wherein the processing systems, memory and software kit of such robot systems are pre-configured and static.
  • the power and memory of the control unit may be restricted by the size, weight and power limitations; when a robot malfunctions or becomes obsolete, a new robots may be required to replace the old one.
  • the ICST may provide cloud services to provide shared memory, processing and control system to robots and other autonomous systems (e.g., intelligent service terminals, etc.).
  • the ICST may enable autonomous learning systems to access a far more powerful computation engine, share knowledge and solution with other terminals and access a larger amount of data then they could store locally.
  • the ICST may be customizable so that each user may define what services are consumed and how they are consumed.
  • the ICST may expose shared data storage, learning algorithms and other systems as cloud services that can be accessed remotely by distributed devices and/or intelligent consumer service terminals, such as robots, ATM terminals, POS terminals, Kiosks, and/or the like.
  • the ICST may include a configurable rules engine (e.g., including a graph based learning engine, a graph database and links to other data sources). It may provide solutions (sets of commands) to problems generate by a robot or autonomous system. An example problem would be how to open a door that the robot has not seen before. The solution would be the optimal configuration and movement of the robot's hand to open the door.
  • ICST may provide solutions (sets of commands) to problems generate by a robot or autonomous system. An example problem would be how to open a door that the robot has not seen before. The solution would be the optimal configuration and movement of the robot's hand to open the door.
  • FIGURE lA shows a diagram illustrating an example of robot obtaining and installing SDK solution packages from an ICST cloud within implementations of the ICST.
  • a robot 110 may comprise a programmable component and a vacuum cleaning component, such as but not limited to a iRobot Create® Roomba®, Scooba®, and/or the like.
  • a user 102 may desire to configure the robot 110 to perform different tasks 101a that the robot 110 may not be preprogrammed to accomplish.
  • the user 102 may want the robot 110 to perform customized tasks such as automatically steaming all the carpet area and brushing all the wood floor areas in a particular three bedroom home, e.g., 101a.
  • the user 102 may enter such task requests via a user device 103, e.g., a user laptop, a desktop, a personal digital assistant (PDA), a smart phone (e.g., an Apple® iPhone, a BlackBerry®, a Google Android®, etc.), a table computer, and/or the like.
  • a user device 103 e.g., a user laptop, a desktop, a personal digital assistant (PDA), a smart phone (e.g., an Apple® iPhone, a BlackBerry®, a Google Android®, etc.), a table computer, and/or the like.
  • the user may upload a picture of his floor plan 134 along with his requests, indentifying carpet area and wood area in the floor plan.
  • the user may or may not provide floor plan 134 or specifying carpet/wood areas but seeking for a solution so that the robot 110 could automatically identify the carpet or wood area.
  • the robot 110 may comprise a user input/output interface such as a touch screen, a key board, a LCD screen, and/or the like, so that a user 102 may directly submit a service request to the robot 110 via the user interface.
  • a user input/output interface such as a touch screen, a key board, a LCD screen, and/or the like
  • the user device 103 may communicate with the robot 110 via a wireless network such as but not limited to WiFi, Bluetooth, and/or the like, and obtain robot information 132, e.g., robot type, robot manufacturer, robot physical address, robot OS version, robot SDK version, robot hardware identifier, and/or the like.
  • robot information 132 e.g., robot type, robot manufacturer, robot physical address, robot OS version, robot SDK version, robot hardware identifier, and/or the like.
  • the user 102 may submit a solution request 131 via the user device 103, e.g., by accessing a web-based portal, etc., and upload the request 131 to an ICST cloud 100.
  • the robot 110 which may be equipped with an intelligent component may directly upload such request 131 to the ICST cloud loo.
  • the ICST cloud 100 may query for a SDK package 135 for the robot 110 based on the submitted robot information 132, e.g., based on compatibility of OS, hardware, and/or the like.
  • the robot 110 may then download and install the SDK for carpet/wood cleaning solutions 135, which may enable the robot 110 to determine a carpet 141 area or a wood floor area 142, and perform cleaning tasks accordingly.
  • FIGURE lB provides a diagram illustrating another example of intelligent robots uploading and sharing traffic information with the ICST cloud within implementations of the ICST.
  • an intelligent robot 110 may be installed with a vehicle lisa-b to collect road information.
  • the robot 110 may comprise an Escort® smart detector, and/or the like.
  • a user e.g., the driver of a vehicle 115a, may request the robot, e.g., the smart detector, to detect whether there is a police car 101b.
  • the robot 110 may submit a solution request 132 to the ICST cloud 100.
  • ICST cloud 100 may then provide a police car SDK 136 for download, and provide a synchronized update 107 indicating the police car detection information to a social network of robots 110.
  • FIGURE lC shows a diagram illustrating another example of intelligent terminal learning mechanism within implementations of the ICST.
  • a user 102 may submit a request for service 101 to an intelligent terminal 110.
  • the intelligent terminal 110 may be a smart wallet assistant robot, an ATM machine, a smart wallet mobile robot application (e.g., an Apple Siri-like smart mobile application, etc.), and/or the like.
  • the user 102 may demand service from the intelligent terminal 110, wherein the service content may not be already preprogrammed with the terminal 110.
  • the user may ask the terminal to determine who has stolen his gaming points from his mobile wallet account 101.
  • the intelligent terminal no may form a query in the local instruction pool to determine whether such service request has been submitted before and whether there exists a solution. If not, the intelligent terminal no may submit a request to a ICST cloud loo, seeking for advice on how to find out who stolen the user's gaming points 103.
  • the ICST cloud 100 may in turn query for a set of rules, e.g., via a rule engine, and return a set of instructions/rules 104 to the intelligent terminal 110, who may receive and load the instructions 104 for execution.
  • the instructions/rules 104 may comprise a software update kit, patches, such as
  • the instructions 104 may comprise a set of rules for the intelligent terminal 110 to investigate the user's 102 smart wallet transaction history and find out the time, date, source of IP, transferee account, etc. of the suspicious gaming points transfer, e.g., at 105.
  • the intelligent terminal 110 may install and save the instructions 104, and build a new service type responding to the request 101. In this way, the intelligent terminal 110 may progressively build new solutions and expand its skill set in response to user's new service requests.
  • FIGURE lD provides an exemplary diagram illustrating aspects of an ICST terminal in the form of a camera equipped quadrocopter within embodiments of the ICST, e.g., for example the Parrot AR.Drone 2.0 and accompanying ADRONE open API (see projects.adrone.org) may be employed for remote access and control.
  • a user 102 may employ a device as a smart ICST assistant to perform a plurality of tasks, e.g., via smartphone API, such as, but not limited to scanning bar code during purchase, performing price check, and/or the like.
  • the ICST smart assistant may take a form to a wearable device, such as glasses, a hat, a headband, a watch, a pin, a button, and/or the like.
  • a wearable device such as glasses, a hat, a headband, a watch, a pin, a button, and/or the like.
  • the ICST smart assistant may take a form to a quadrocopter 140, which may be configured to move from one destination to another in the air.
  • a user 102 may remotely control the ICST quadrocopter via a remote control component installed at a mobile device (e.g., a Smartphone, etc.).
  • the ICST quadrocopter 140 may be installed with multiple cameras on facing different directions so that the quadrocopter may take photos from different angles while moving around.
  • a user 102 may utilize the ICST quadrocopter as a shopping assistant at a physical store.
  • the user may operate a remote control mobile device to request the ICST quadrocopter 140 to take a photo of "Aisle 3, Stack 002" 141a.
  • the ICST quadrocopter 140 may not be preprogrammed with the specific direction and floormap of the storefront to execute the user instructions.
  • the ICST quadrocopter 140 may submit an instruction query 141b to the ICST cloud 100, with its GPS location 142.
  • the ICST cloud 100 may query the database and find a store scanning solution firmware package 144 for the quadrocopter.
  • the ICST could 100 may retrieve a store floor layout map 143 based on the GPS location 142, and provide the movement instructions within the store to the ICST quadrocopter 140.
  • the ICST cloud 100 may provide a store scanning solution 144 to a docking station 145, wherein the docking station 145 may provide the store map 143.
  • the ICST quadrocopter 140 may move to the docking station 145 to receive a store scanning solution package 144 including instructions with regard to the store layout information 143 ⁇
  • the store scanning solution 144 may indicate the locations in the physical store where a, e.g., 4x4 inch, QR code may be found in store, e.g., I47a-c.
  • the ICST quadrocopter 140 may locate the QR codes I47a-c while roaming in store, and obtain information with regard to inventory, store map and/or direction by scaning the QR codes I47a-c.
  • FIGURE lE provides an alternative embodiment of the ICST quadrocopter providing patrol service of a residential place within embodiments for the ICST.
  • the ICST quadrocopter may be used for security surveillance, e.g., by taking video/photos of a residential area, etc.
  • a user 102 may request an ICST quadrocopter to "patrol" a residential house 148a.
  • the ICST quadrocopter 140 may obtain the user command 148a, and implement the command by obtaining the GPS location of the place, and taking video/photos of the place, e.g., via an initialpath (by flying over the lawn of the residential area, see red arrow at 149a) around the street address.
  • This initial path may be supplied by an individual providing an initial flight path by remote control via control pad, e.g., the AR.FREEFLIGHT controls via a smartphone. This path may be saved and repeated in a cycle and the video maybe streamed for ananlysis.
  • the user may turn on the quadrocopter at the user's residential address, which may automatically put the quadrocopter to the "patrol" mode; and the quadrocopter may upload a GPS location to the ICST cloud indicating a query for instructions as to how to patrol the place related to the GPS coordinates.
  • the quadropcopter may upload video and/or photos captured at the residential place to the ICST while performing the "patrol," wherein the uploaded visual content may serve as a request to update patrol instructions based on the conditions of the place in real-time.
  • the user 102 may manually input a request to the ICST cloud to provide and/or update "patrol" solutions for the quadrocopter, e.g., via textual input at a user interface (e.g., a Smartphone, etc.), audio command (e.g., a Siri like Smartphone app., etc.), uploading an image/video, and/or the like.
  • a user interface e.g., a Smartphone, etc.
  • audio command e.g., a Siri like Smartphone app., etc.
  • uploading an image/video e.g., via textual input at a user interface (e.g., a Smartphone, etc.), audio command (e.g., a Siri like Smartphone app., etc.), uploading an image/video, and/or the like.
  • the quadropcopter may already have installed a solution to perform the user requested task, e.g., to "patrol" a residential address, etc.
  • the quadrocopter may submit identifying information of the existing solution (e.g., an application number, a version number, etc.) to the ICST cloud as supplemental identifying information of the user requested solution query.
  • the ICST solution may parse the obtained existing solution information to query for any updates on related solution.
  • the quadrocopter provided information as to the existing solution may be stored at the ICST cloud as part of the data aggregation. Such data aggregation may be performed with an encryptimatic XML converter, e.g., see FIGURE 42.
  • the quadrocopter 140 may upload a query 148b for surveillance/patrol solutions to the ICST cloud 100, which may indicate the GPS location of the place to be patrolled.
  • the ICST patrol solution 144b may obtain a street view photo of the residential area, and a roaming path 149c for the quadrocopter to patrol.
  • the patrol solution 144b may indicate that at the street address "1355 palm St, Dream City, CA," the quadrocopter may roll on the lane across the lawn (e.g., yellow arrows 149c) and fly over the bush (e.g., red arrow 149b).
  • FIGURE lF provides alternative examples of ICST quadrcopter patrol solutions 144b within embodiments of the ICST.
  • the ICST cloud 100 may query for instructions to patrol a residential place based on the GPS location of the residential house.
  • the quadrocopter may obtain instructions to patrol the residential house, e.g., by a "zigzag" type movement above the house 161a (e.g., see the red arrows, etc.).
  • Such moving/patrolling pattern may be repeated and requires the quadrocopter to return to its starting point (e.g., see the white arrow 162a ) when a "zigzag" routine (e.g., see the red arrows 161a) is finished.
  • a "zigzag" routine e.g., see the red arrows 161a
  • the quadrocopter may obtain updated patrol solution 163 from the ICST cloud.
  • an update may be generated by the ICST cloud by patrol patterns adopted and uploaded by other patrolling terminals. Flight paths ranked and assessed to be superior may then be integrated and provided as updates to all participating devices.
  • update 163 may be generated and/or modified by the ICST cloud 100 based on user feedback, e.g., the user 102 may comment the patrol routine 161a may not be able to scan the entire region of the lawn/yard, and the returning/restarting path 162a is long and thus inefficient.
  • such user feedback may be reflected as a user rating (e.g., see 387 in FIGURE 3C) score, and/or another query request from the user (e.g., see 392 in FIGURE 3C).
  • a user rating e.g., see 387 in FIGURE 3C
  • another query request from the user e.g., see 392 in FIGURE 3C
  • the user and/or the quadrocopter may query for "swirling + patrol + path" and indicate a user desired solution.
  • the ICST cloud 100 may provide an update 163 for the quadrocopter's patrol solution 144b.
  • the updated patrol solution may determine a path in a swirling manner, which may allow the quadrocopter to cover more area of the residential area, and the returning/restarting path 162b is shorter.
  • FIGURE lG provides another example illustrating aspects of an ICST terminal in the form of a multiple access security camera within embodiments of the ICST.
  • the ICST terminals may comprise multiple access cameras 150, e.g., cameras with a flexible turnable support so that the camera 150 may be turned to face different directions 154.
  • a user 102 may request the security camera 150 to provide surveillance of a residential house 151a, e.g., via a mobile phone turned remote control, similar to that described in FIGURE lC.
  • the multiple access security camera 150 may provide its GPS information 152 to the ICST cloud 100, which may determine that it is a residential address 151b, and determine that the solution requested is surveillance instructions. For example, if it is a residential address, the ICST cloud 100 may search for surveillance instructions related to a residential place, including the frequency of multi-angle scanning (e.g., every 30 minutes, etc.).
  • the camera 150 may download the surveillance solution package 153 from the cloud.
  • the surveillance solution 153 may comprise a street map of the residential area, and provide the vision scope of the multiple access security camera 150 based on the position of the camera I55a-i55b.
  • Such vision scopes may indicate a series of motion instructions for the camera to turn and move.
  • FIGURE 2A shows a block diagram illustrating data flows between ICST server and affiliated entities within various embodiments of the ICST.
  • one or more consumers user(s) 202, intelligent terminal(s) 210, ICST server 230, ICST database(s) 219, Internet resource(s) 224 and/or the like are shown to interact via various communication network 213.
  • the ICST facilitates connections through the communication network 213 based on a broad range of protocols that include WiFi, Bluetooth, 3G cellular, Ethernet, physical tethers (e.g., iPhone Video AV to Dock Connector Cable, which allows for connection to a monitor or TV), and/or the like.
  • the communication network 213 may be the Internet, a Wide Area Network (WAN), a telephony network, a Local Area Network (LAN), a Peer-to-Peer (P2P) connection, and/or the like.
  • WAN Wide Area Network
  • LAN Local Area Network
  • P2P Peer-to-Peer
  • the user 202 may operate with a user device having a user interface 207a/i07b to communicate with an intelligent terminal 210.
  • the user interface may comprise a mobile application UI 207a, a web based UI 207b, an ATM based UI, and/or the like.
  • the intelligent terminal 210 may comprise an ATM terminal, a POS terminal, a mobile wallet application, and/or the like, which facilitates financial transaction.
  • the intelligent terminal 210 may comprise home use robots such as autonomous vacuum cleaner, floor washer, and/or the like.
  • the intelligent terminal 210 may comprise security surveillance systems such as cameras, detectors, sensors, and/or the like.
  • the intelligent terminals 200 may further comprise a variety of robots, autonomous systems, and/or the like.
  • the intelligent terminal 210 and the UI 207a/b may be integrated.
  • the user 202 may directly interact with an intelligent terminal 210, which may comprise a smart wallet manager application instantiated on a user's mobile phone.
  • the intelligent terminal 210 may be remotely accessed by the user 202 via the UI 207a/b.
  • the user 202 may submit service request 206a via the UI 207a/b, which may in turn forward the user service request 206b to an intelligent terminal 210.
  • the user 202 may enter a textual request, e.g., by typing "what is the weather now?" etc.
  • the user 202 may "speak" to a UI 207a asking "what is the weather now," wherein the UI 207a/b may adopt a verbal conversation tool to convert the submitted verbal request into text.
  • the intelligent terminal 210 may analyze the request by extracting key terms and determine whether a solution is available in the local database.
  • a service request may be automatically detected or generated by the intelligent terminal 210.
  • a cleaning robot e.g., see 110 in FIGURE lA
  • a vehicle smart detector e.g., see 110 in FIGURE lB
  • the intelligent terminal 210 may perform local intelligent query 208 in its local software stack to determine whether a solution to such service request has been previously stored. For example, the intelligent terminal 210 may issue PHP/SQL commands to query a database table (such as FIGURE 74, Solution table 7419 ⁇ ) for a solution.
  • a database table such as FIGURE 74, Solution table 7419 ⁇
  • $result mysql query ( $query) ; // perform the search query
  • HTTP(S) Hypertext Transfer Protocol
  • XML extensible Markup Language
  • HTTP(S) POST message including an XML-formatted user service request 2o6a/b and/or 209 for solution in the cloud:
  • the ICST server 230 may dissect the received request to extract query terms 208, and submit the query terms to the ICST database 219.
  • the ICST server 230 may provide a HTTPS POST message including a query request 208 in the form of data formatted according to XML.
  • HTTP(S) POST message including an XML-formatted user service request 2o6a/b and/or 207 for solution in the cloud:
  • the ICST database 219 may send query result 212 to the ICST server 230, which may in turn return the queried results 225 to the intelligent terminal.
  • the ICST server 230 may provide a HTTPS POST message including the query result 212 and/or the downloadable instructions 225 in a similar form in the form of data formatted according to XML.
  • HTTP(S) POST message including an XML-formatted query result 212 or instructions 225:
  • meta data " . / fModels/robotExample . meta"
  • the above exemplary XML-formatted query results 212 include instructions to determine the current weather, comprising steps to "determine location,” “determine weather,” load “weather data,” load “user settings,” and/or the like.
  • the intelligent terminal 210 may execute the instructions, e.g., to determine the current weather at the user's location, and provide the service solution (e.g., the current weather) 226a/b to the user via UIs 207a/b.
  • the user 202 may receive response at a screen after submitting his weather inquiry, showing "Weather 56 °F DC 20036.”
  • the ICST server 230 and database 219 may comprise distributed databases which may be integrated in-house with the ICST server 230.
  • the ICST entities may access a remote ICST database 219 via the communication network 213.
  • the IPDT entities may send data to the database 219 for storage, such as, but not limited to user account information, application data, protocol data, application history, query instructions, service requests, and/or the like.
  • the ICST server 230 and the ICST database 219 may comprise a cloud platform, infrastructure, servers, and/or the like.
  • the cloud platform may comprise one or more online database connected to a variety of data vendors, such as hardware vendors (e.g. Apple Inc., Intel, Sony, etc.), service vendors (e.g. Visa Network, Google, Apple Inc., etc.) and/or the like.
  • the ICST cloud e.g., the ICST database 219 and the ICST server 230
  • the information updates 2i6a/b may comprise updated hardware driver information, new application packages, services, and/or the like.
  • the information updates may be performed upon request from the ICST cloud, e.g., when a user service request could not be identified within the ICST database 219.
  • the information updates may be performed on a periodic basis (e.g., daily, weekly, etc.).
  • the ICST server 230 and/or the ICST database 219 may constantly, intermittently, and/or periodically download updates, such as updated software programs, updated command instructions, and/or the like, from the Internet resources via a variety of connection protocols, such as Telnet FTP, HTTP transfer, P2P transmission and/or the like.
  • an Internet cloud may provide a HTTPS PUT message including information updates 2i6a/b in the form of data formatted according to XML.
  • HTTP(S) PUT message including an XML-formatted information updates :
  • FIGURE 2B provides a data flow diagram illustrating data flows for cloud sharing among the ICST server and affiliated entities within alternative embodiments of the ICST.
  • the intelligent terminal 210a may generate solution data and/or SDK updates 233 to the ICST cloud.
  • the SDK update may include current versions of the SDK package, user configuration of the SDK package, and/or the like.
  • the solution data may include robot generated responses to a service request, e.g., a detected police car location with a timestamp as shown at 133 in FIGURE lB.
  • the robot/intelligent terminal 210 may generate a HTTPS POST message including the solution data and SDK updates 233 in a similar form in the form of data formatted according to XML.
  • HTTP(S) POST message including an XML-formatted SDK updates and solution data 233:
  • the ICST server 230 may create data records for solution/status data and SDK update 235, e.g., by generating separate data record 236a/b for storage in an ICST database 219.
  • the ICST database 219 may query for related solution/status data from a social robot network (e.g., police car detection data from other smart detectors, etc.) 238.
  • the ICST database 219 may generate a query in the form of PHP/SQL commands, an example of which is provided below:
  • the ICST database 219 may provide a solution data updates from other robots 237a (which may take a similar form to that of 233) to the ICST server 230, which may provide such data 237b to the intelligent terminal 210.
  • the robots e.g., vehicle detectors as discussed in FIGURE iB, may build a real time knowledge cloud of police car location information shared among a social network of smart detectors.
  • FIGURE 2C provides a block diagram illustrating an example infrastructure of the ICST within embodiments of the ICST.
  • the ICST may comprise and/or be coupled to one or more interface components and/or modules.
  • various user terminals including end user laptops 255, telephones 253, mobile devices 252, intelligent terminals/robots 205 and other autonomous systems 205 may be connected to Internet 213 resources via routers, gateways, base stations 251, and/or the like.
  • ICST may be coupled to a user interface (UI) (e.g., 252, 253, 255, etc.), which may be configured to receive user inputs (e.g., service request 106a in FIGURE iB, etc.) and display application states and/or other outputs.
  • UI user interface
  • the UI may, for example, allow a user to adjust ICST system settings, select communication methods and/or protocols, submit service requests, engage mobile device application features, and/or the like.
  • the user interface may include, but not limited to devices such as, keyboard(s), mouse, stylus(es), touch screen(s), digital display(s), and/or the like.
  • the ICST user terminals may access a cloud data interface 250 via the Internet 213.
  • the interface 250 may comprise components facilitating transmission of electronic communications via a variety of different communication protocols and/or formats as coordinated with and/or by the communications interface 250.
  • Communication interface 250 may, for example, contain ports, slots, antennas, amplifiers, and/or the like to facilitate transmission of display instructions, such as may instruct a remote display what and/or how to display aspects of a mobile device application state, via any of the aforementioned methods.
  • Communication protocols and/or formats for which the communications interface 250, and varies databases/engines may be compatible may include, but are not limited to, GSM, GPRS, W-CDMA, CDMA, CDMA2000, HSDPA, Ethernet, WiFi, Bluetooth, USB, and/or the like.
  • the communication interface 250 may, for example, serve to configure data into application, transport, network, media access control, and/or physical layer formats in accordance with a network transmission protocol, such as, but not limited to FTP, TCP/IP, SMTP, Short Message Peer-to-Peer (SMPP) and/or the like.
  • the communications interface 250 may further be configurable to implement and/or translate Wireless Application Protocol (WAP), VoIP and/or the like data formats and/or protocols.
  • WAP Wireless Application Protocol
  • the communications interface 250 may further house one or more ports, jacks, antennas, and/or the like to facilitate wired and/or wireless communications with and/or within the IPDT system.
  • the interface 250 may receive data from Internet 213 and load it to a variety of components, such as the rules engine 230, performance feedback engine 240, analytics engine 220, learning engine 210, and/or the like.
  • the communications interface 250 may comprise web server software equipped to configure application state data for publication on the World Wide Web. Published application state data may, in one implementation, be represented as an integrated video, animation, rich internet application, and/or the like configured in accordance with a multimedia plug-in such as Adobe Flash.
  • the communications interface 250 may comprise remote access software, such as Citrix, Virtual Network Computing (VNC), and/or the like equipped to configure application state data for viewing on a remote client (e.g., an intelligent terminal, etc.).
  • VNC Virtual Network Computing
  • the rule engine 230 may control how a machine can learn, what it can learn and what actions it is allowed to undertake.
  • This rule engine may be configurable by end users to meet the needs of their robot or autonomous system.
  • an intelligent terminal, robot or autonomous system may have a dedicated learning procedure and may also have access to a centralized learning rule engine that may pool the knowledge gained from the local learners.
  • the ICST may query for rules associated with iPhone app based on the application ID, wherein the rules may restrict solution query to specific vendors, programming modules, development types, and/or the like.
  • the rules may specify system requirements, hardware requirements, security requirements, and/or the like for solutions to a service request.
  • the rules engine may further specify rules per user devices, Email servers, user telephony devices, CPEs, gateways, routers, user terminals, transmission protocols, data formats, and/or the like suitable for communicating with a type of intelligent terminals 205 and/or any ICST affiliated entities.
  • the performance feedback engine may provide feedbacks on the success or failure of the provided solutions.
  • an intelligent terminal 205 may receive instructions from the cloud to perform a new task, and may provide task status as "accomplished,” “in progress,” “failed,” “aborted,” and/or the like to the performance feedback engine 240.
  • the knowledge gained from all participating robots may be pooled in a shared memory and all robots may access.
  • Such feedbacks may be analyzed to improve learning at a centralized personal information platform, as further illustrated in FIGURES 7-54C.
  • outside data may be used to enhance decision making processes, e.g., user rating, etc.
  • the ICST may build solutions in response to a service request at a learning engine 210.
  • the learning engine 210 may receive a service request (e.g., 107 in FIGURE lB) via the interface 250, and apply rules from the rules engine 230 to query for solutions to the service request in a shared data store 215.
  • the shared data store 215 may comprise robot history 219a, robot profiles 219b, shared history 219c, linked robots 2i9d and/or the like.
  • the robot history 219a may comprise service request that have been received by an intelligent terminal, solutions provided, status of the solution implementations, and/or the like.
  • the robot profile 219b may comprise information to each intelligent terminal, robot and/or other autonomous systems.
  • An exemplary XML-formatted robot history data record may take a form similar to the following:
  • the shared history 219c may comprise records of shared solutions between intelligent terminals; and the linked robots 2i9d records may comprise robots that are tagged as "similar” or “sharable” by the analytics engine 220.
  • linked robots 2i9d may comprise a graph linking intelligent terminals so that a query for solutions may be performed along the graph of "similar" or “sharable” robot history to improve search efficiency.
  • the analytics engine 220 may provide analytics report to the service request-query match history, robot history, and/or the like.
  • analytics engine 220 may perform statistical analysis to identify popular inquiries, popular applications, popular intelligent terminal types, and/or the like.
  • the analytics engine 220 may link intelligent terminals that frequently receive similar service requests, compatible to similar solutions, and/or the like.
  • the analytics engine 220 may further categorize intelligent terminals that receive similar service requests to facilitate correlated search for solutions.
  • the analytics engine 220 may receive performance feedbacks from 240 to provide quality of service (QoS) reports, and/or the like.
  • QoS quality of service
  • the ICST may enable intelligent terminals, robots and other autonomous system to find solutions to problems not encountered before or better solutions to existing problems; access a vast amount of structured data to process in the cloud or locally; communicate with other robots to enhance solution generation and cooperation; use the dedicated cloud based learner to optimize its own solution set, and/or the like.
  • the ICST may enable users to create configurable learning machines in a cloud setting; monitor and control robots and autonomous systems remotely; upgrade or switch robots without losing gained knowledge, and/or the like.
  • FIGURES 3A-3C provide logic flows illustrating intelligent solution matching within embodiments of the ICST.
  • a user may submit a service request (e.g., io6a/b in FIGURE lB) via a user interface 305.
  • the user may send a textual request describing the desired service, e.g., via email, text messages, instant online messages, dedicated user interface of an intelligent terminal (e.g., ATM, mobile wallet application, etc.) and/or the like.
  • the user may engage in an artificial intelligent conversational tool (e.g., Apple Siri, MSN Robot, etc.) and "speak" to the intelligent terminal about a service request.
  • an artificial intelligent conversational tool e.g., Apple Siri, MSN Robot, etc.
  • the intelligent terminal may determine whether there exists a solution in the local database 308. For example, in one implementation, the user may have clicked an option button via a user interface, which may in turn trigger an existing solution to the option. When there exists a local solution to the service request 310, the intelligent terminal may execute the existing solution to provide service 311 to the user, who may in turn receive service results via the user interface 312.
  • the intelligent terminal may send the service request (e.g., 107 in FIGURE lA) to an ICST cloud (e.g., an ICST server 130 and/or ICST database 119 in FIGURE lA).
  • an ICST cloud e.g., an ICST server 130 and/or ICST database 119 in FIGURE lA.
  • the ICST cloud may parse the service request to form a query in the cloud 315, as further illustrated in FIGURE 3B. If a solution is not found from the query 320, the ICST cloud may notify the intelligent terminal that the solution is not available, and the intelligent terminal may generate a service denial message via the user interface 317, e.g., by displaying a message "Sorry, unable to process" 320 to the user. If a solution is found from the query 320, the ICST cloud may proceed to determine whether the queried solution is compatible with solution rules and requirements 323. For example, in one implementation, requirement parameters may be included in the received service request, such as version requirements, development environment requirement, compatibility requirements, and/or the like.
  • the application ID from the service request may indicate compatibility requirement, e.g., a service request originated from an Apple iPhone app may inherently exclude solutions that must be executed under a Windows OS.
  • the ICST cloud may incorporate the requirement parameters into search logics at 315.
  • the ICST may send service denial messages, e.g., at 317.
  • the ICST may generate a downloadable instruction package 330 for the intelligent terminal to download, install and execute the instruction package 333 (e.g., an ".exe” file, a ".dmg” file, etc.).
  • the intelligent terminal successfully installs and runs the downloaded instructions 335, the intelligent terminal may generate a status report 337 to the ICST cloud to indicate the solution is executable, wherein the ICST cloud may generate a record of the service request and solution match for analytics engine 338, as further illustrated in FIGURE 3C.
  • the downloaded instructions can not be installed or executed 335, the ICST may proceed with 320 to notify the user of failure.
  • FIGURE 3B provides a logic flow illustrating a solution query in the cloud within embodiments of the ICST.
  • the ICST may receive a service query request (e.g., 107 in FIGURE 3A) from an intelligent terminal 340, and then may parse the servicer request to extract request source information and key terms 342.
  • the request source information may comprise a device type, an application ID 345, application type, application version information associated with the requested service, and/or the like; and the key terms may be extracted from the user description of the service request, e.g., "Weather," "Current” as the key terms from a user request of the current local weather.
  • the ICST may form a query based on the key terms and the application information 348.
  • the query may be performed in a progressive manner. For example, if the application ID indicates the request is originated from an iPhone App, the ICST may query on a database of iPhone compatible solutions. In one implementation, if a solution is located 352, the ICST may generate and store a record of service request - solution match 372. In another implementation, if no solution is found 352, the ICST may expand the query progressively in the database when relaxed query restrictions. For example, if a query on "Weather + current + iPhone OS + Visa wallet" does not return a solution, the ICST may form a second round search on "weather + current + iPhone OS.”
  • the ICST may progressively search solution history of linked intelligent terminals/robots 354.
  • the linked intelligent terminals may be defined by the analytics engine (e.g., 220 in FIGURE 2).
  • the analytics engine e.g., 220 in FIGURE 2.
  • a Visa electronic wallet running on an iPhone may be linked with other Visa electronic wallet engaged iPhones as related intelligent terminals.
  • the linked intelligent terminals may form a social network of the robots.
  • ICST robots/terminals may be linked and/or categorized based on their types, e.g., robot cleaners, robot detectors, robot jewelry, robot surveillance camera, wallets, and/or the like.
  • the ICST robots/terminals may be linked and/or grouped based on the service request (e.g., key terms, instruction type, etc.), e.g., robots that have searched for "auto weather update" may be grouped and linked, etc.
  • the ICST robots/terminals may be linked and/or grouped based on the application type, application identifier, e.g., mobile devices that have a wallet application instantiated thereon may be linked, etc.
  • the ICST robots social network may facilitate solution query, sharing, and updates.
  • the ICST cloud may query on solution history of linked social robots in response to a solution query, e.g., see 354-374 in FIGURE 3B.
  • the ICST cloud may share the feedback, solution updates from an ICST robot to the robot's social group so that other robots in the social group may obtain feedback on a solution, and/or solution updates.
  • an ICST robot cleaner e.g., see 110 in FIGURE lA
  • the ICST cloud may send such updates to other ICST robot cleaners linked to the ICST robot cleaner.
  • the ICST may retrieve a list of linked intelligent terminal profiles 355, and form a query on the service request history of the linked intelligent terminals, using similar query rules as that at 348. If a solution is located 360, the ICST may proceed to generate the record of solution match 372, and send the queried solution to a rule engine 374 to determine whether it is compatible. Otherwise, the ICST may progressively search a database of linked intelligent terminals by expanding the query to second, third, etc. degree linked intelligent terminal profiles 362. Within implementations, the ICST may configure the progressive query mechanism so that the degrees of search may be pre-determined.
  • the ICST may generate a notification of "solution not found" 370 and flag the service request as "unsolved” 373.
  • the ICST may send the unsolved service request to a service vendor 375 (e.g., Apple, Google, etc.).
  • FIGURE 3C provides a logic flow illustrating user feedback performance analysis within implementations of the ICST.
  • the ICST may retrieve a list of unprocessed service request solution history associated with an intelligent terminal 378. For every record 380, the ICST may determine whether there is a solution matched to the service request 382. If yes, the ICST may determine whether there is any user feedback 383 to include in the feedback performance analysis. In one implementation, the ICST may determine a type of the feedback 385. If it is an indicating of user satisfaction of a provided solution (e.g., a user rating of the solution, a response to a satisfaction survey, etc.), the ICST may determine a user satisfaction level with the solution 387.
  • a provided solution e.g., a user rating of the solution, a response to a satisfaction survey, etc.
  • a user may submit a rating of the solution, e.g., see 445 in FIGURE 4A.
  • the ICST may then store the solution as a match to the service request when the user rating indicates the user is satisfied (e.g., a 4 star or 5 star rating, etc.).
  • the ICST may label the solution as a non-match to the service request when the user rating indicates the user is not satisfied 390, and may exclude the labeled solution in future query of the service request.
  • the ICST may parse the further request to key terms 392.
  • the ICST may revise the query formula based on the updated query conditions 395 based on the user submitted further inquiry, and re-query the database 398 for solutions.
  • the ICST may return the result of a current weather in Miami after querying for a solution; the user may then refine the service request by stating "what is the weather in Miami during the dates of my purchased Miami vacation package," the ICST may then refine the search so that the solution may include the feature to determine the dates of a purchased travel package and retrieve weather information.
  • FIGURE 4A provides an exemplary screen shot illustrating a cloud enabled intelligent mobile wallet service within implementations of the ICST.
  • the user may use his mobile wallet to purchase a Miami beach 4 days golden package for the dates 5/20 - 5/23, e.g., at 405.
  • the wallet may provide options for the user to call agent to confirm 410a, cancel the order 410b. If the user wants additional services, he may indicate a desired service is not shown 410c.
  • the user may type a request "what is the weather in Miami during my stay?" 430.
  • the intelligent mobile wallet may provide a voice enabled user interface so that the user may speak out his desired service.
  • the mobile wallet may then process 435 the received service request.
  • the mobile wallet may provide the option to install a "Smart Weather Agent" 440 to the mobile wallet.
  • the mobile wallet may also receive user feedbacks on the performance of the provided solution by requesting the user to submit a rating 445.
  • An exemplary data structure of the instructions for determining the weather at the location of a user is provided at 712 in FIGURE 7, wherein a centralized personal information platform may harvest and aggregate data from different ICST terminals and provide a solution (e.g., the weather, etc.) based on the received query.
  • FIGURE 4B provides exemplary screen user interfaces illustrating using a mobile device to submit robot service requests within embodiments of the ICST.
  • a user may operate a camera enabled mobile device, such as an Apple iPhone, a Google Android, and/or the like, to capture an image of a room 452.
  • the user may email the photo to an ICST cloud 453 to request a cleaning solution based on the type of floor of the captured room photo.
  • the user may request to browse a list of available SDK 454, enter cleaning parameters (e.g., vacuum or brush, mop, etc.) 455, upload a floor plan picture 456, and/or the like.
  • the robot terminal may download a SDK package 450 showing the status of downloading via a robot LCD screen 450.
  • FIGURE 4C provides exemplary screen user interfaces illustrating using a smart detector installed on a vehicle to share police car detection information among the ICST cloud within embodiments of the ICST.
  • a robot e.g., the smart detector may detect a police car location 460 on a GPS alike screen user interface, showing the location of the police car 267. The user may elect to upload such information for sharing among the cloud 461, and/or to synchronize with the ICST cloud to obtain police car locations captured by other detectors 462.
  • the smart detector may upload the detected police car location with a timestamp to the ICST cloud 463.
  • the smart detector may download police car locations detected by other detectors from the ICST cloud around its location 464, e.g., showing another police car location 466 on a GPS map alike screen.
  • the ICST cloud 100 may obtain various human behavioral information, such as but not limited to mobile device location coordinate information transmissions, real-time reality visual capturing, mixed gesture capturing, bio-sensor data, ICST robot queries for solutions, real-time behavior-sensitive product purchase related information, shopping purchase transaction notifications, and electronic receipts, and/or the like, and serve as a consumer personal information aggregation platform (e.g., see FIGURES 7-54C).
  • the ICST robot terminals in various forms may facilitate collecting and uploading such human behavioral data to the ICST cloud.
  • the ICST robot terminals may serve as originators 711 (e.g., see FIGURE 7) to obtain consumer purchase, product preference related information and upload it to the consolidated database 704a.
  • ICST robot terminals may take various different forms such as, but not limited to an ICST robot cleaner, ICST wearable devices (e.g., a hat, a badge, a brooch, electronic jewelry, etc.), ICST smart assistant (e.g., a quadrocopter, etc.), sand/or the like.
  • the ICST cloud may obtain various data from the ICST robots and perform data mining on the obtained data to determine consumer interests, preferences in future shopping.
  • an ICST solution query from an ICST robot cleaner e.g., see 101a in FIGURE lA
  • an ICST solution query to inquire about the location of a police car may provide updated GPS location information of the consumer to the cloud (e.g., see 101b, 132 in FIGURE lB); and the ICST cloud may determine the regular area of driving scope of the consumer based on a plurality of geo-locations.
  • an ICST solution query to inquire about surveillance instructions may provide GPS information of the consumer's home address, which may be used as a second-factor confirmation of the consumer's billing/shipping address, and/or the like.
  • the ICST robots may capture visual and/or audio content of the surroundings of a consumer, which may be used as part of personal information of the consumer.
  • the robot cleaner may submit a captured photo by its installed camera (e.g., see 622a in FIGURE 6C) to the ICST cloud, wherein the ICST cloud may obtain an indoor view of the consumer's residence, and make relevant product suggestions, cleaning instructions, offers, rewards, and/or the like.
  • the ICST terminals may be employed to capture consumer behavioral data for gamification.
  • the consumer may obtain reward points, offers, e.g., sponsored by a merchant, if the consumer has browsed more lanes within a merchant store, scanned for price check for a product, upload traffic information via thr police car detectors, and/or the like.
  • the consumer may receive a message notification (e.g., via SMS, phone calls, email, wallet push messages, instant message, etc.) for the rewards points.
  • the consumer when a consumer uploads a police car location via the robot (e.g., see 110 in FIGURE lB) to the ICST cloud, the consumer may receive a notification, e.g., "thank you for providing the information! You have earned 5 ICST points.”
  • a consumer may engage the rewards ICST points to "purchase" solutions and/or knowledge from the ICST cloud.
  • the ICST terminals may take various forms for a consumer to wear, carry and/or place nearby, so that the ICST robot terminals may capture personal information related to the consumer.
  • the various apparatuses of ICST robots may comprise a processor and a memory to process and upload the obtained personal information related to the consumer, e.g., the robot base 621a in FIGURE 6C.
  • FIGURES 5A-5B provide example block diagrams illustrating example component structure of ICST components in the form of ICST wearable jewelry within embodiments of the ICST.
  • a user 202 may wear a piece of ICST electronic jewelry 501, e.g., a Pin, a badge, a brooch, etc.
  • the ICST jewelry 501 may comprise various "layers/bars" 503a-d which are interchangeable and replaceable.
  • a camera bar 503a comprises one or more cameras 505; communication bar 503b may include wireless antenna 507a for Wifi connection, Bluetooth 507c, and a microphone 507b for capturing audio recording, etc.; bar /layer 503c may comprise a decorative element 508a for the badge, e.g., crystal, gem stones, etc., and may comprise a radar element 508b; the power layer /bar 503d may comprise a power element 509, e.g., a winder, a solar cell, a button battery, and/or the like.
  • the layer 503b may further include a GPS element.
  • the layers/bars 502a-d may be connected via wires 506.
  • Such wires 506 may be clasped 511 at the back of the bar, and/or fixed by screws 512 to prevent the wire movement.
  • the camera layer 503c may further comprise an identifiable gem stone 513.
  • the gem stone 513 may comprise a unique graphic pattern to identify the wearer of the electronic jewelry.
  • such identifiable gem stone 513 may be captured by a camera at a merchant store, and serve as a two-factor identity authentication for payment. Further discussion of such identification via gem stone patterns are discussed in U.S. Patent No. 8,434,675, issued May 7, 2013, entitled “Crack embossing using diamond technology,” which is herein expressly incorporated by reference. .
  • the power layer 503d may comprise a battery plane 510, which may be powered by solar cells, a button battery, and/or the like.
  • the ICST electronic jewelry may be powered by a winder, e.g., via the spin 514, which may be connected to a motor 516 to convert the motion of the spin to energy.
  • the motor 516 may be connected to a battery via battery connectors 517.
  • FIGURES 6A-6B provide example block diagrams illustrating example component structure and use cases of ICST quadrocopter examples within embodiments of the ICST.
  • the user 602 may operate a mobile device 603 (e.g., a Smartphone, etc.) to operate an ICST quadrocopter 605a, which may have cameras 604 installed at the side of its base plate, wherein the base plate may rotate for the cameras to capture video/photos from different angles.
  • a mobile device 603 e.g., a Smartphone, etc.
  • cameras 604 installed at the side of its base plate, wherein the base plate may rotate for the cameras to capture video/photos from different angles.
  • FIGURE 6A provides an example structure 605b of an ICST quadrocopter.
  • the quadrocopter may have wings 606 to facilitate movement in the air; a microphone layer 607; a camera layer 608, a tilting plane 609 to position the camera/microphone at different angles.
  • the quadrocopter may be powered/charged via a magnetic power adaptor 613, e.g., the MagSafe power adaptor, and/or the like.
  • the quadrocopter may comprise landing clasps 611 at its bottom to interface a landing area and support landing of the quadrocopter.
  • the various layers 607-609 of the quadrcopter may be removed, replaced, interchanged by a consumer according to consumer preferences.
  • the ICST quadrocopter robot may be provided in different shape and size.
  • the quadrcopter that comes in a large size e.g., a quadrocopter "dragon" 615a, which may be placed in a car; a medium sized robot, e.g., a "lizard” 615b, which may be clipped to the rear-view mirror inside the car, as a decoration; a small sized robot, e.g., a "brooch" 615a, which may be pinned to the consumer's chest.
  • the three ICST robots 6i5a-c placed at different places within a vehicle 616 may be able to capture different visual content, GPS location information, user behavioral data such as driving patterns, movements, etc., from different angles; such captured user behavioral data may be uploaded to ICST cloud (e.g., a centralized personal information platform, etc.) for data mining, e.g., as further discussed in FIUGRES 7-54C.
  • ICST cloud e.g., a centralized personal information platform, etc.
  • FIGURES 6C-6D provide example block diagrams illustrating example component structure of ICST robot cleaners within embodiments of the ICST.
  • a robot cleaner 620 may comprise a robot base 621a atop rollers/legs 621b for movement.
  • the robot may comprise various layers for different functional modules, e.g., for camera 622a, Bluetooth 622b, microphone 622c, phone 622d, speaker, GPS, and/or the like.
  • the robot cleaner may have a "lego" like structure, e.g., the different layers/disks 623a-e such as but not limited to the cover 623a, "hearing” (microphone) 623b, "eyes” (camera”) 623c, base 623d, power 623e, etc., may be dissembled, removed, replaced, rearranged, and/or the like 624.
  • a consuemr may assemble the robot cleaner by removing, rearranging, and/or replacing one or more layer components 623a-d based on the consumer's preferences.
  • 625a-b provide two alternative assembly of the robot cleaner.
  • the layers may comprise magnetic connectors 626 to connect with each other.
  • the consumer may add a customized new layer element (e.g., a digital gemprature meter, humidity meter, sound level meter, air quality meter, etc.) to the robot cleaner in a similar fashion, e.g., by using the magnetic connectors 626 of a layer element.
  • a customized new layer element e.g., a digital gemprature meter, humidity meter, sound level meter, air quality meter, etc.
  • the ICST robot cleaner may automatically query and obtain instructions in a solution cloud for operating the newly added elements (e.g., a digital gemprature meter, humidity meter, sound level meter, air quality meter, etc.), e.g., as discussed in FIGURES 3A-3C.
  • FIGURE 6D provides an alternative view of the robot cleaner disk within embodiments of the ICST.
  • the robot cleaner "lego" disk may have a USB 631a, infrared chip 63id, wireless 631c, Bluetooth 63id, and/or the like installed, and may have magnetic connector 630 at its top and bottom surfaces.
  • the top/bottom surfaces of the disk may comprise power bus 631 to connect to a power cord, and/or a serial bus 632 for data connection (e.g., to connect with a digital device, etc.).
  • a user may connect the robot cleaner to a computer via the serial bus 632 to download/upload instructions, log data, configuration parameters, and/or the like.
  • FIGURE 7 shows a block diagram illustrating example aspects of a centralized personal information platform in some embodiments of the ICST.
  • originators 711 such as merchants 711b, consumers 711c (including, e.g., social networking sites), account issuers, acquirers 711a, 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 705 may aggregate and store such inputs in consolidated database 704b.
  • social network interactions 7iid e.g., emails, reviews, text posts, photos, audio/video/multimedia, conversations, chats, etc.
  • financial institution activity 711a e.g., acquirers, authorizations, denials, issuers, fraud detection, etc.
  • merchant activities 711b e.g., offers, coupons, redemptions, etc.
  • the mesh server 705 may aggregate and store such inputs in consolidated database 704b.
  • 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.
  • a feed of financial transactions e.g., if the mesh server is also a pay network server
  • complete feed access e.g., firehose feeds
  • social networks e.g., Facebook, Twitter, etc.
  • publically available data API's e.g., Google seach API
  • 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., 705) 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. 7990; 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 7991; 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 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.
  • FIG. 712 Features that entities may desire include application services 712 such as alerts 712a, offers 712c, money transfers 712 ⁇ , fraud detection 712b, and/or the like.
  • application services 712 such as alerts 712a, offers 712c, money transfers 712 ⁇ , fraud detection 712b, 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 701.
  • the originators may submit complex queries to the ICST 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 (e.g., see 430 in FIGURE 4A, etc.), perform analyses on the weather data, and provide an exploded graphical view of the results of the analysis:
  • meta data " . / fModels/robotExample . meta"
  • ⁇ /vault> [00181]
  • a non-limiting, example listing of data that the ICST may return based on a query is provided below.
  • a user may log into a website via a computing device.
  • the computing device may provide a IP address, and a timestamp to the ICST.
  • the ICST may identify a profile of the user from its database, and based on the profile, return potential merchants for offers or coupons: Use Case 3
  • Test case 2 IP 148 : 181 : 75 Hour:4 Day:5
  • OrderedDict [(' ISACTIVE ' , 'True'), ('BASEUUID', ' 4fbea328b9fflle0a5f833b5d7c45677 ' ) , ( ' TOKENENTITYKEY ' ,
  • PARCLOJASINSINUANTE WALMARTCONTAGEM FOOTLOCKER
  • PARCRAMSONS PARCGREGORY GREMIOFBPA WALMARTSJC
  • the ICST may provide access to information on a need-to-know basis to ensure the security of data of entities on which the ICST 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 ICST 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 ICST may generate, update, maintain, store and/or provide profile information on entities, as well as a social graph that maintains and updates interrelationships between each of the entities stored within the ICST.
  • the ICST may store profile information on an issuer bank 702a (see profile 703a), a acquirer bank 702b (see profile 703b), a consumer 702c (see profile 703c), a user 702d (see profile 703d), a merchant 702e (see profile 703 ⁇ ), a second merchant 702f (see profile 703f).
  • the ICST may also store relationships between such entities.
  • the ICST may store information on a relationship of the issuer bank 702a to the consumer 702c shopping at merchant 702e, who in turn may be related to user 702d, who might bank at the back 702b that serves as acquirer for merchant 702f.
  • FIGURES 8A-F show block diagrams illustrating example aspects of data models within a centralized personal information platform in some embodiments of the ICST.
  • the ICST may store a variety of attributes of entities according to various data models. A few non-limiting example data models are provided below.
  • the ICST may store user profile attributes.
  • a user profile model may store user identifying information 801, user aliases 802, email addresses 803, phone numbers 804, addresses 805, email address types 806, address types 807, user alias types 808, notification statuses 809, ISO country 810, phone number types 811, contract information with the ICST 812, user authorization status 813, user profile status 814, security answer 815, security questions 816, language 817, time zone 818, and/or the like, each of the above field types including one or more fields and field values.
  • a user financial attributes model may store user identifying information 820, user financial account information 821, account contract information 822, user financial account role 823, financial account type 824, financial account identifying information 825, contract information 826, financial account validation 827, financial account validation type 828, and/or the like.
  • a user payment card attributes data model may include field types such s, but not limited to: user identifying information 830, user financial account information 831, user financial account role 832, account consumer applications 833, user consumer application 834, financial account type 835, financial account validation type 836, financial account information 837, consumer application information 838, consumer application provider information 839, and/or the like.
  • a user services attributes data model may include field types such as, but not limited to: user identifying information 840, user alias 841, consumer application user alias status 842, user alias status 843, status change reason code 844, user contract 845, contract information 846, user service attribute value 847, consumer application attributes 848, account service attribute value, account contract 850, user profile status 861, contract business role 852, contract business 853, client information 854, contract role 855, consumer application 856, user activity audit 857, login results 858, and/or the like.
  • field types such as, but not limited to: user identifying information 840, user alias 841, consumer application user alias status 842, user alias status 843, status change reason code 844, user contract 845, contract information 846, user service attribute value 847, consumer application attributes 848, account service attribute value, account contract 850, user profile status 861, contract business role 852, contract business 853, client information 854, contract role 855, consumer application 856, user activity audit 8
  • a user services usage attributes data model may include field types such as, but not limited to: user identifying information 860, user alias 861, consumer application user alias status 862, status change reason code 863, user alias status 864, user consumer application 865, user login audit 866, login result 867, account service attribute value 868, account consumer application 869, consumer application 870, consumer application provider 871, login result 872, and/or the like.
  • a user graph attributes data model may include field types such as, but not limited to: user identifying information 880, user contact 881, consumer application user alias status 882, relationship 883, and/or the like.
  • the ICST may store each object (e.g., user, merchant, issuer, acquirer, IP address, household, etc.) as a node in graph database, and store data with respect to each node in a format such as the example format provided below:
  • the ICST may store data in a JavaScript Object Notation ("JSON") format.
  • the stored information may include data regarding the object, such as,
  • TOKENENTITIESRELATIONSHIPS' ['MERCHANT'], 'ATTRIBUTES':
  • VALUE' VALUE
  • 'COUPONNAME' (4, 'STRING', 0, 'VALUE'), ' CREATIONDT ' : 8, 'DATETIME', 0, 'VALUE'), ' STARTDT ' : (12, 'DATETIME', 0, VALUE'), 'ISACTIVE': (0, 'BOOL', 1, 'VALUE') ⁇ 'MEMBERSHIP': ⁇ ' TYPEOFTYPES ' : ['MEMBERSHIPS'], 'FUNCTIONS': ' ENTITYCREATION ' : ' putNet ork ' ⁇
  • TOKENENTITIESRELATIONSHIPS' ['MERCHANT'], 'ATTRIBUTES':
  • MEMBERSHI PNAME ' (4, 'STRING', 0, 'VALUE'), ' STARTDT ' : (5, DATETIME ' , 0, 'VALUE'), ' EXPDT ' : (6, ' DATETIME ' , 0, 'VALUE'), ISACTIVE': (0, 'BOOL', 1, 'VALUE'), ⁇ ': (1, 'STRING', , ' VALUE ' ) ⁇
  • TOKENENTITIESRELATIONSHIPS' ['USER'], 'ATTRIBUTES': ⁇ 'STATUS': 2, 'STRING', 0, 'VALUE'), 'EXPDT': (6, 'DATETIME', 0, 'VALUE'), USERSECURITYNAME ' : (4, 'STRING', 0, 'VALUE'), 'USER': (3,
  • TOKENENTITIESRELATIONSHIPS' ['MCCSEG'], 'ATTRIBUTES':
  • 'MCCSEG' (4, 'STRING', 0, 'VALUE'), 'MCC: (2, 'STRING', 0, VALUE'), 'MCCNAME': (3, 'STRING', 0, 'VALUE'), 'ISACTIVE': (0, BOOL', 1, 'VALUE'), ⁇ ': (1, 'STRING', 0, 'VALUE') ⁇
  • POPULATION' (3, 'STRING', 0, 'VALUE'), 'ZIPCODE': (2, 'STRING', , 'VALUE'), 'ISACTIVE': (0, 'BOOL', 1, 'VALUE'), ⁇ ': 1, 'STRING', 0, 'VALUE') ⁇ ' PAYMENTCARD ' : ⁇ ' TYPEOFTYPES ' : [ ' PAYMENTCARDS ' ] , 'FUNCTIONS': ' ENTITYCREATION ' : ' putNet ork ' ⁇
  • TOKENENTITIESRELATIONSHIPS' ['USER'], 'ATTRIBUTES': ⁇ ' EXPDATE ' : 5, ' DATETIME ' , 0, 'VALUE'), ⁇ ': (1, 'STRING', 0,
  • VALUE' VALUE'
  • 'CARDTYPE' (4, 'STRING', 0, 'VALUE'), 'CARDNUMBER': 2, 'STRING', 0, 'VALUE'), 'USER': (3, 'STRING', 0, 'VALUE'), ISACTIVE': (0, 'BOOL', 1, 'VALUE') ⁇
  • TOKENENTITIESRELATIONSHIPS' ['MERCHANT'], 'ATTRIBUTES':
  • VALUE' VALUE'
  • STARTDT ' (12, 'DATETIME', 0, 'VALUE'), ' CREATIONDT ' : 8, 'DATETIME', 0, 'VALUE'), ' GENERICTOKENNAME ' : (4, 'STRING', 0, VALUE'), 'ISACTIVE': (0, 'BOOL', 1, 'VALUE') ⁇
  • VALUE' VALUE'
  • 'RawTweet' 5, 'STRING', 0, 'VALUE'
  • 'DATETIME' 3, 'STRING', 0, 'VALUE'
  • CLEANEDTWEET ' (6, 'STRING', 0, 'VALUE')
  • ⁇ ' (1, 'STRING', 0, 'VALUE')
  • 'TWEETID' (2, 'STRING',
  • FIGURE 9 shows a block diagram illustrating example ICST component configurations in some embodiments of the ICST.
  • the ICST 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 ICST may utilize search results aggregation component(s) 901 (e.g., such as described in FIGS. 10-11) to aggregate search results from across a wide range of computer networked systems, e.g., the Internet.
  • the ICST may utilize transaction data aggregation component(s) 902 (e.g., such as described in FIGS.
  • the ICST may utilize service usage data aggregation component(s) 903 (e.g., such as described in FIGS. 12-15) to aggregate data on user's usage of various services associated with the ICST.
  • the ICST may utilize enrollment data component(s) 904 (e.g., such as described in FIGS. 18-19) to aggregate data on user's enrollment into various services associated with the ICST.
  • the ICST may utilize email data component(s) 905a (e.g., such as described in FIG. 43) to aggregate data regarding the user's email correspondence history into various services associated with the ICST.
  • the ICST may utilize social data aggregation component(s) 905 (e.g., such as described in FIGS. 16-17) to aggregate data on user's usage of various social networking services accessible by the ICST.
  • 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.
  • the ICST may acquire the aggregated data, and normalize the data into formats that are suitable for uniform storage, indexing, maintenance, and/or further processing via data record normalization component(s) 906 (e.g., such as described in FIGS. 20A-B).
  • the ICST may extract data from the normalized data records, and recognize data fields, e.g., the ICST may identify the attributes of each field of data included in the normalized data records via data field recognition component(s) 907 (e.g., such as described in FIG. 21).
  • the ICST may identify names, user ID(s), addresses, network addresses, comments and/or specific words within the comments, images, blog posts, video, content within the video, and/or the like from the aggregated data.
  • the ICST may classify entity types associated with the field of data, as well as entity identifiers associated with the field of data, e.g., via component(s) 908 (e.g., such as described in FIG. 22).
  • the ICST may identify an Internet Protocol (IP) address data field to be associated with a user ID john.q.public (consumer entity type), a user John Q.
  • IP Internet Protocol
  • the ICST may utilize the entity types and entity identifiers to correlate entities across each other, e.g., via cross-entity correlation component(s) 909 (e.g., such as described in FIG. 23). For example, the ICST may identify, from the aggregated data, that a household entity with identifier H123 may include a user entity with identifier John Q.
  • the ICST may utilize the entity identifiers, data associated with each entity and/or correlated entities to identify associations to other entities, e.g., via entity attribute association component(s) 910 (e.g., such as described in FIG.
  • the ICST 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. Based on such correlations and associations, the ICST 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) 911 (e.g., such as described in FIGS. 25, 46, 47A-E and 48A-C).
  • entity profile-graph updating component(s) 911 e.g., such as described in FIGS. 25, 46, 47A-E and 48A-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) 913-314 (e.g., such as described in FIG. 26).
  • 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 10 shows a data flow diagram illustrating an example search result aggregation procedure in some embodiments of the ICST.
  • 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., 1010, 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., 1012, a pay network database, e.g., 1007, 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., 1013, a list of API templates in response. Based on the list of API templates, the pay network server may generate search requests, e.g., 1014.
  • the pay network server may issue the generated search requests, e.g., ioi5a-c, to the search engine servers, e.g., looia-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 ioi5a-c, substantially in the form of PHP commands, is provided below:
  • the search engine servers may query, e.g., ioi7a-c, their search databases, e.g., i002a-c, for search results falling within the scope of the search keywords.
  • the search databases may provide search results, e.g., ioi8a-c, to the search engine servers.
  • the search engine servers may return the search results obtained from the search databases, e.g., ioi9a-c, to the pay network server making the search requests.
  • JSON JavaScript Object Notation
  • responseDetails null
  • responseStatus 200 ⁇
  • the pay network server may store the aggregated search results, e.g., 1020, in an aggregated search database, e.g., 1010a.
  • FIGURE 11 shows a logic flow diagram illustrating example aspects of aggregating search results in some embodiments of the ICST, e.g., a Search Results Aggregation ("SRA") component 1100.
  • the pay network server may obtain a trigger to perform a search, e.g., 1101.
  • the pay network server may periodically perform a search update of its aggregated search database 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, e.g., 1102, to extract keywords using which to perform an aggregated search.
  • the pay network server may determine the search engines to search, e.g., 1103, using the extracted keywords.
  • the pay network server may generate a query for application programming interface (API) templates for the various search engines (e.g., GoogleTM, Bing®, AskJeeves, market data search engines, etc.) from which to collect data for aggregation, e.g., 1104.
  • the pay network server may query, e.g., 1105, a pay network database 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., 1105, a list of API templates in response. Based on the list of API templates, the pay network server may generate search requests, e.g., 1106.
  • 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., 1107, and query, e.g., 1108, their search databases for search results falling within the scope of the search keywords.
  • the search databases may provide search results, e.g., 1109, to the search engine servers.
  • the search engine servers may return the search results obtained from the search databases, e.g., 1110, to the pay network server making the search requests.
  • the pay network server may generate, e.g., 1111, and store the aggregated search results, e.g., 1112, in an aggregated search database.
  • FIGURES 12A-D show data flow diagrams illustrating an example card- based transaction execution procedure in some embodiments of the ICST.
  • a user e.g., 1201
  • 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., 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., purchase input 1211, 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., 1212, and provide, e.g., 1213, the generated purchase order message to the merchant server.
  • a browser application executing on the client may provide, on behalf of the user, a (Secure) Hypertext Transfer Protocol ("HTTP(S)”) GET message including the product order details for the merchant server in the form of data formatted according to the extensible Markup Language (“XML").
  • 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., 1214 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., 1215, to an acquirer server, e.g., 1204.
  • 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 HTTP(S) POST message including an XML-formatted card query request similar to the example listing provided below:
  • the acquirer server may generate a card authorization request, e.g., 1216, using the obtained card query request, and provide the card authorization request, e.g., 1217, to a pay network server, e.g., 1205.
  • the acquirer server may redirect the HTTP(S) POST message in the example above from the merchant server to the pay network server.
  • the pay network server may determine whether the user has enrolled in value-added user services.
  • the pay network server may query 1218 a database, e.g., pay network database 1207, for user service enrollment data.
  • the server may utilize PHP/SQL commands similar to the example provided above to query the pay network database.
  • the database may provide the user service enrollment data, e.g., 1219.
  • the user enrollment data may include a flag indicating whether the user is enrolled or not, as well as instructions, data, login URL, login API call template and/or the like for facilitating access of the user-enrolled services.
  • the pay network server may redirect the client to a value-add server (e.g., such as a social network server where the value-add service is related to social networking) 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 value-add server as part of a value add service request, e.g., 1220.
  • 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 input request, e.g., 1221, to the client.
  • the value-add server may provide a HTML input/login form to the client.
  • the client may display, e.g., 1222, the login form for the user.
  • the user may provide login input into the client, e.g., 1223, and the client may generate a service input response, e.g., 1224, for the value- add server.
  • the value-add server may provide value-add services according to user value-add service enrollment data, user profile, etc., stored on the value-add server, and based on the user service input.
  • the value-add server may generate a value-add service response, e.g., 1226, and provide the response to the pay network server.
  • the value-add server may provide a HT P(S) POST message similar to the example below:
  • the pay network server may extract the enrollment service data from the response for addition to a transaction data record.
  • the pay network server may forward the card authorization request to an appropriate pay network server, e.g., 1228, which may parse the card authorization request to extract details of the request.
  • the pay network server may generate a query, e.g., 1229, for an issuer server corresponding to the user's card account.
  • the user's card account may be linked to an issuer financial institution ("issuer"), such as a banking institution, which issued the card account for the user.
  • issuer such as a banking institution
  • An issuer server e.g., i2o8a-n
  • An issuer server e.g., i2o8a-n
  • a database e.g., pay network database 1207
  • 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., 1230, 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., 1231, 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., 1232, to the issuer server.
  • the issuer server may parse the card authorization request, and based on the request details may query 1233 a database, e.g., user profile database 1209, 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
  • $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., 1235. 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., 1236, to the pay network server. For example, the server may provide a HT P(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., 1239, the details of the transaction and authorization relating to the transaction in a database, e.g., pay network database 1207. 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., 1240, to the acquirer server, which may in turn forward the authorization message, e.g., 1240, 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., 1241, and store the XML data file, e.g., 1242, in a database, e.g., merchant database 1204.
  • 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., 1243, and provide the purchase receipt to the client.
  • the client may render and display, e.g., 1244, 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., 1245, and provide the request, e.g., 1246, to a database, e.g., merchant database 1204.
  • the merchant server may utilize PHP/SQL commands similar to the examples provided above to query a relational database.
  • the database may provide the requested batch data, e.g., 1247.
  • the server may generate a batch clearance request, e.g., 1248, using the batch data obtained from the database, and provide, e.g., 1241, the batch clearance request to an acquirer server, e.g., 1210.
  • the merchant server may provide a HTTP(S) POST message including XML-formatted batch data in the message body for the acquirer server.
  • the acquirer server may generate, e.g., 1250, a batch payment request using the obtained batch clearance request, and provide the batch payment request to the pay network server, e.g., 1251.
  • the pay network server may parse the batch payment request, and extract the transaction data for each transaction stored in the batch payment request, e.g., 1252.
  • the pay network server may store the transaction data, e.g., 1253, for each transaction in a database, e.g., pay network database 1207.
  • the pay network server may query, e.g., 1254-655, a database, e.g., pay network database 1207, for an address of an issuer server.
  • the pay network server may utilize PHP/SQL commands similar to the examples provided above.
  • the pay network server may generate an individual payment request, e.g., 1256, for each transaction for which it has extracted transaction data, and provide the individual payment request, e.g., 1257, to the issuer server, e.g., 1208.
  • the pay network server may provide a HTTP(S) POST request similar to the example below:
  • the issuer server may generate a payment command, e.g., 1258.
  • 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., 1259, to a database storing the user's account information, e.g., user profile database 1208.
  • the issuer server may provide a funds transfer message, e.g., 1260, to the pay network server, which may forward, e.g., 1261, the funds transfer message to the acquirer server.
  • An example HTTP(S) POST funds transfer message is provided below:

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computing Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention porte sur des systèmes, des procédés et des appareils de terminal de service de consommateur intelligent (ICST). Le ICST transforme des entrées de requête de service d'utilisateur par l'intermédiaire de composants ICST en une solution de service exécutable par un terminal intelligent. Dans un mode de réalisation, un procédé est présenté, comprenant : la réception d'une demande de requête de service en provenance d'un terminal distant ; l'analyse de la demande de requête de service pour obtenir des informations d'identification de service ; l'interrogation d'un nuage de solutions sur la base des informations d'identification de service obtenues ; l'extraction d'une solution du nuage de solutions à partir de l'interrogation ; la génération d'un paquet d'instructions téléchargeables comprenant la solution extraite sur la base d'informations de source du terminal distant ; et la fourniture du paquet d'instructions téléchargeables au terminal distant.
PCT/US2013/046875 2012-02-22 2013-06-20 Systèmes, procédés et appareils de terminal de service de consommateur intelligent WO2013192443A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2013277083A AU2013277083A1 (en) 2012-02-22 2013-06-20 Intelligent consumer service terminal apparatuses, methods and systems

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US13/520,481 US10223691B2 (en) 2011-02-22 2012-02-22 Universal electronic payment apparatuses, methods and systems
US201261661899P 2012-06-20 2012-06-20
US61/661,899 2012-06-20
US13/520,481 2012-07-03
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
USPCT/US2013/024538 2013-02-02
US13/758,900 2013-02-04
US13/758,900 US20130204886A1 (en) 2012-02-02 2013-02-04 Multi-Source, Multi-Dimensional, Cross-Entity, Multimedia Encryptmatics Database Platform Apparatuses, Methods and Systems
US201361774571P 2013-03-07 2013-03-07
US61/774,571 2013-03-07

Publications (1)

Publication Number Publication Date
WO2013192443A1 true WO2013192443A1 (fr) 2013-12-27

Family

ID=49769392

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/046875 WO2013192443A1 (fr) 2012-02-22 2013-06-20 Systèmes, procédés et appareils de terminal de service de consommateur intelligent

Country Status (2)

Country Link
AU (1) AU2013277083A1 (fr)
WO (1) WO2013192443A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10366416B2 (en) 2015-04-30 2019-07-30 Kellogg Company Beacon based campaign management
CN110336665A (zh) * 2019-07-11 2019-10-15 成都卫士通信息产业股份有限公司 一种大数据消息加密方法、装置
RU2713761C1 (ru) * 2019-06-14 2020-02-07 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система поиска принадлежности ip-адреса территориальному кластеру на основе данных транзакций
CN111586172A (zh) * 2020-05-07 2020-08-25 支付宝(杭州)信息技术有限公司 数据处理方法、装置、设备及介质
US10904200B2 (en) 2016-10-11 2021-01-26 Talla, Inc. Systems, apparatus, and methods for platform-agnostic message processing
CN112286674A (zh) * 2019-07-24 2021-01-29 广东知业科技有限公司 一种基于边缘计算的行转列方法及***
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system
CN113656572A (zh) * 2021-08-26 2021-11-16 支付宝(杭州)信息技术有限公司 一种对话处理方法和***
US20230410216A1 (en) * 2014-10-17 2023-12-21 Myver Holding Aps Method and system for handling and storing purchase transactions

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106254401B (zh) * 2015-06-08 2022-02-25 腾讯科技（深圳）有限公司 网络通信中的社交关系建立方法、终端设备、智能设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030195659A1 (en) * 2000-02-09 2003-10-16 Sony Corporation Robotic device management system and method, and information management apparatus
US20060075235A1 (en) * 2004-09-30 2006-04-06 Martin Renkis Wireless video surveillance system and method with security key
US20060195598A1 (en) * 2003-03-28 2006-08-31 Masahiro Fujita Information providing device,method, and information providing system
US20100138026A1 (en) * 2008-03-08 2010-06-03 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
WO2010148704A1 (fr) * 2009-12-30 2010-12-29 中兴通讯股份有限公司 Systeme informatique en nuage de services et procede de realisation de services
US20110109737A1 (en) * 2008-10-08 2011-05-12 Sjoerd Aben Navigation apparatus and method for recording image data
US20110221692A1 (en) * 2010-03-11 2011-09-15 Parrot Method and an appliance for remotely controlling a drone, in particular a rotary wing drone

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030195659A1 (en) * 2000-02-09 2003-10-16 Sony Corporation Robotic device management system and method, and information management apparatus
US20060195598A1 (en) * 2003-03-28 2006-08-31 Masahiro Fujita Information providing device,method, and information providing system
US20060075235A1 (en) * 2004-09-30 2006-04-06 Martin Renkis Wireless video surveillance system and method with security key
US20100138026A1 (en) * 2008-03-08 2010-06-03 Tokyo Electron Limited Method and apparatus for self-learning and self-improving a semiconductor manufacturing tool
US20110109737A1 (en) * 2008-10-08 2011-05-12 Sjoerd Aben Navigation apparatus and method for recording image data
WO2010148704A1 (fr) * 2009-12-30 2010-12-29 中兴通讯股份有限公司 Systeme informatique en nuage de services et procede de realisation de services
US20110221692A1 (en) * 2010-03-11 2011-09-15 Parrot Method and an appliance for remotely controlling a drone, in particular a rotary wing drone

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230410216A1 (en) * 2014-10-17 2023-12-21 Myver Holding Aps Method and system for handling and storing purchase transactions
US10366416B2 (en) 2015-04-30 2019-07-30 Kellogg Company Beacon based campaign management
US10991006B2 (en) 2015-04-30 2021-04-27 Kellogg Company Beacon based campaign management
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system
US10904200B2 (en) 2016-10-11 2021-01-26 Talla, Inc. Systems, apparatus, and methods for platform-agnostic message processing
RU2713761C1 (ru) * 2019-06-14 2020-02-07 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система поиска принадлежности ip-адреса территориальному кластеру на основе данных транзакций
CN110336665A (zh) * 2019-07-11 2019-10-15 成都卫士通信息产业股份有限公司 一种大数据消息加密方法、装置
CN110336665B (zh) * 2019-07-11 2022-06-14 成都卫士通信息产业股份有限公司 一种大数据消息加密方法、装置
CN112286674A (zh) * 2019-07-24 2021-01-29 广东知业科技有限公司 一种基于边缘计算的行转列方法及***
CN112286674B (zh) * 2019-07-24 2023-12-19 广东知业科技有限公司 一种基于边缘计算的行转列方法及***
CN111586172A (zh) * 2020-05-07 2020-08-25 支付宝(杭州)信息技术有限公司 数据处理方法、装置、设备及介质
CN113656572A (zh) * 2021-08-26 2021-11-16 支付宝(杭州)信息技术有限公司 一种对话处理方法和***

Also Published As

Publication number Publication date
AU2013277083A1 (en) 2015-01-22

Similar Documents

Publication Publication Date Title
US10983960B2 (en) Multi-source, multi-dimensional, cross-entity, multimedia centralized personal information database platform apparatuses, methods and systems
US20130290234A1 (en) Intelligent Consumer Service Terminal Apparatuses, Methods and Systems
US11354723B2 (en) Smart shopping cart with E-wallet store injection search
WO2013192443A1 (fr) Systèmes, procédés et appareils de terminal de service de consommateur intelligent
US20220012767A1 (en) Real-time digital asset sampling apparatuses, methods and systems
WO2013116806A1 (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
US20150356610A1 (en) Realtime Realworld and Online Activity Correlation and Inventory Management Apparatuses, Methods and Systems
US20130159081A1 (en) Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems
US20140164167A1 (en) Commerce facilitation apparatuses, methods and systems
US20220005108A1 (en) Ad Hoc Item Geo Temporal Location and Allocation Apparatuses, Methods and Systems
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
US20180276702A1 (en) Eco Advantage Mediation Apparatuses, Methods and Systems
US20150170186A1 (en) Eco Advantage Mediation Apparatuses, Methods and Systems
US11720555B1 (en) Multidimensional machine learning data and user interface segment tagging engine apparatuses, methods and systems
US11676070B1 (en) Multidimensional machine learning data and user interface segment tagging engine apparatuses, methods and systems
US10565632B1 (en) Transaction control system and method
US11188966B1 (en) Catalog enablement data for supplier systems based on community activities
AU2013264948A1 (en) Eco advantage mediation aparatuses, methods and systems
JP2015524953A (ja) エコ・アドバンテージ仲介装置、方法、及びシステム

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: 13807410

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2013277083

Country of ref document: AU

Date of ref document: 20130620

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 13807410

Country of ref document: EP

Kind code of ref document: A1