HK1254467B - Distributed, decentralized data aggregation - Google Patents

Description

Distributed, decentralized data aggregation

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. patent application No. 15/167,650, filed on May 27, 2016, to John Ryan Caldwell, entitled “DISTRIBUTED, DECENTRALIZED DATA AGGREGATION,” U.S. Provisional Patent Application No. 62/254,708, filed on November 12, 2015, to John Ryan Caldwell, entitled “DISTRIBUTED DATA AGGREGATION,” and U.S. Provisional Patent Application No. 62/280,070, filed on January 18, 2016, to Ryan Caldwell, entitled “DISTRIBUTED, DECENTRALIZED DATA AGGREGATION,” each of which is hereby incorporated by reference herein in its entirety.

Technical Field

The present invention relates to the ownership and collection of user data, and more particularly to the distributed and/or decentralized aggregation of data from multiple users of hardware devices associated with the users.

Background Art

As more and more user data moves to the cloud, it becomes increasingly difficult for users to control, download, and/or use their own personal data. It can be particularly difficult for users to export data from a service provider's walled garden, as service providers may implement various technical measures to prevent users from accessing user data outside of the service provider's ecosystem. A service provider may block one or more Internet Protocol (IP) addresses of a third party (e.g., an aggregator service) from accessing user data from the service provider, even if the third party has the user's authorization and login credentials.

Summary of the Invention

A method for distributed and/or decentralized data aggregation is presented. In one embodiment, the method includes determining electronic credentials of a user for a plurality of third-party service providers. In another embodiment, the method includes using the user's determined electronic credentials to access each of the third-party service providers via a hardware device associated with the user to download data associated with the user from the third-party service providers. In certain embodiments, the method includes aggregating the downloaded data from the third-party service providers and providing one or more communications to the user on the hardware device based on the aggregated downloaded data.

A system for distributed and/or decentralized data aggregation is proposed. In one embodiment, multiple aggregation modules are located on hardware devices of different users. In some embodiments, the multiple aggregation modules receive electronic credentials for multiple different third-party service providers from the different users. In one embodiment, the multiple aggregation modules use the received electronic credentials to download data associated with the different users from the different third-party service providers. In another embodiment, a back-end server receives downloaded data associated with the different users from the different third-party service providers. In some embodiments, the back-end server separately aggregates data for each of the different users from the multiple different third-party service providers. In one embodiment, the back-end server separately provides one or more communication messages based on the separately aggregated data to the different users via one or more communication channels.

A device for distributed and/or decentralized data aggregation is presented. In one embodiment, an authentication module is configured to determine an electronic credential of a user for a third-party service provider on a hardware device of the user. In some embodiments, a direct access module is configured to access a server of the third-party service provider through the hardware device of the user using the electronic credential of the user. In another embodiment, the direct access module is configured to download data associated with the user from the server of the third-party service provider to the hardware device of the user. In one embodiment, an interface module is configured to package the downloaded data from the hardware device of the user to a remote device independent of the third-party service provider. In another embodiment, the interface module is configured to provide the downloaded data to the remote device.

In another embodiment, a device includes means for performing various steps and operations described in accordance with the disclosed methods, apparatus, and systems. A computer program product including a computer-readable storage medium is also provided. In certain embodiments, the computer-readable storage medium stores computer-usable program code that is executable to perform one or more operations described in accordance with the disclosed methods, apparatus, and systems.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the present invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof that are illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, additional features and details of the invention will be described and explained through the use of the accompanying drawings, in which:

FIG1 is a schematic block diagram illustrating one embodiment of a system for distributed/decentralized data aggregation;

FIG2 is a schematic block diagram of one embodiment of an aggregation module;

FIG3 is a schematic block diagram of another embodiment of an aggregation module;

FIG4A is a schematic block diagram illustrating an additional embodiment of a system for distributed/decentralized data aggregation;

FIG4B is a schematic block diagram illustrating another embodiment of a system for distributed/decentralized data aggregation;

FIG4C is a schematic block diagram illustrating an embodiment of a system for distributed/decentralized data aggregation;

FIG5A is a schematic block diagram illustrating one embodiment of a user interface;

FIG5B is a schematic block diagram illustrating another embodiment of a user interface;

FIG6 is a schematic flow chart illustrating one embodiment of a method for distributed/decentralized data aggregation;

FIG7 is a schematic flow chart illustrating another embodiment of a method for distributed/decentralized data aggregation; and

FIG8 is a schematic flow chart illustrating yet another embodiment of a method for distributed/decentralized data aggregation.

DETAILED DESCRIPTION

Throughout this specification, reference to "one embodiment," "an embodiment," or similar language indicates that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the phrases "in one embodiment," "in an embodiment," and similar language appearing throughout this specification may, but do not necessarily, refer to the same embodiment, and unless expressly specified otherwise, refer to "one or more but not all embodiments." Unless expressly specified otherwise, the terms "including," "comprising," "having," and variations thereof mean "including but not limited to." Unless expressly specified otherwise, an enumerated list of items does not mean that any or all items are mutually exclusive and/or mutually inclusive. Unless expressly specified otherwise, the terms "a," "an," and "the" also refer to "one or more."

Furthermore, the features, advantages, and characteristics of the described embodiments may be combined in any suitable manner. Those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of the specific features or advantages of a particular embodiment. In other cases, additional features and advantages may be realized in certain embodiments that may not be present in all embodiments.

These features and advantages of the embodiments will become more apparent from the following description and the appended claims, or they can be understood by implementing the embodiments described below. As will be appreciated by those skilled in the art, aspects of the present invention may be embodied as systems, methods and/or computer program products. Therefore, aspects of the present invention may take the form of complete hardware embodiments, complete software embodiments (including firmware, resident software, microcode, etc.), or embodiments of combined software and hardware aspects, which are generally referred to herein as "circuits," "modules," or "systems." Additionally, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media having program code thereon.

Many of the functional units described in this specification have been labeled as modules to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips, transistors, or other discrete components). A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like.

Modules can also be implemented in software for execution by various types of processors. An identified module of program code may, for example, comprise one or more physical or logical blocks of computer instructions, which may be organized, for example, into objects, procedures, or functions. Nevertheless, the executable files of an identified module need not be physically located together, but may comprise different instructions stored in different locations that, when logically connected together, constitute the module and achieve the stated purpose of the module.

In practice, a program code module can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data can be identified and shown within a module, and the operational data can be embodied in any suitable form and can be organized within any appropriate type of data structure. The operational data can be collected as a single data set, or the operational data can be distributed across different locations including different storage devices, and the operational data can exist, at least in part, only as electronic signals on a system or network. Where a module or a portion of a module is implemented in software, the program code can be stored and/or transmitted to one or more computer-readable media.

The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a static random access memory ("SRAM"), a portable compact disc read-only memory ("CD-ROM"), a digital versatile disk ("DVD"), a memory stick, a floppy disk, a mechanically encoded device (e.g., a punched card or raised structure in a groove on which instructions are recorded), and any suitable combination of the foregoing. The computer-readable storage medium used herein should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing/processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and/or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmission devices, routers, firewalls, switches, gateway computers, and/or edge servers. The network adapter card or network interface in each computing/processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing/processing device.

The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and conventional procedural programming languages such as "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, can be executed partly on the user's computer, as an independent software package, can be executed partly on the user's computer, partly on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, by using the Internet of an Internet service provider). In certain embodiments, the electronic circuit comprising, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions with personalized electronic circuits by using the state information of the computer-readable program instructions, so as to perform various aspects of the present invention.

Various aspects of the present invention are described herein with reference to flowcharts and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block in the flowcharts and/or block diagrams, and combinations of blocks in the flowcharts and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions/actions specified in one or more blocks of the flowchart and/or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct the computer, programmable data processing device, and/or other equipment to operate in a specific manner, such that the computer-readable storage medium having the instructions stored therein comprises an article of manufacture, which includes instructions for implementing various aspects of the functions/actions specified in one or more blocks of the flowchart and/or block diagram.

Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions/actions specified in one or more blocks of the flowchart and/or block diagram.

Many of the functional units described in this specification have been labeled as modules to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips, transistors, or other discrete components). A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like.

Modules can also be implemented in software for execution by various types of processors. An identification module of program instructions may, for example, comprise one or more physical or logical blocks of computer instructions, which may be organized into, for example, objects, procedures, or functions. Nevertheless, the executable files of the identification modules need not be physically located together, but may comprise different instructions stored in different locations that, when logically connected together, constitute the module and achieve the stated purpose of the module.

The schematic flow charts and/or schematic block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the apparatus, system, method, and computer program product according to various embodiments of the present invention. In this regard, each block in the schematic flow charts and/or schematic block diagrams may represent a module, segment, or portion of code including one or more executable instructions of a program code for implementing a specific logical function.

It should also be noted that, in some alternative implementations, the functions indicated in the blocks may occur out of the order indicated in the figures. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods are contemplated that are equivalent in function, logic, or effect to one or more blocks, or portions thereof, of the figures shown.

Although various arrow types and line types may be employed in the flowcharts and/or block diagrams, they are to be understood as not limiting the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the described embodiments. For example, arrows may indicate wait or monitoring periods of unspecified duration between enumerated steps of the illustrated embodiments. It will also be noted that each block in the block diagrams and/or flowcharts, and combinations of blocks in the block diagrams and/or flowcharts, may be implemented by a dedicated hardware-based system that performs a specific function or action, or by a combination of dedicated hardware and program code.

FIG1 illustrates one embodiment of a system 100 for distributed and/or decentralized data aggregation. In one embodiment, the system 100 includes one or more hardware devices 102, one or more aggregation modules 104 (e.g., a backend aggregation module 104b and/or multiple aggregation modules 104a disposed on one or more hardware devices 102), one or more data networks 106 or other communication channels, one or more third-party service providers 108 (e.g., one or more servers 108 of one or more service providers 108; one or more cloud or network service providers, etc.), and/or one or more backend servers 110. In some embodiments, even though a specific number of hardware devices 102, aggregation modules 104, data networks 106, third-party service providers 108, and/or backend servers 110 are depicted in FIG1 , those skilled in the art, based on the teachings of this disclosure, will recognize that any number of hardware devices 102, aggregation modules 104, data networks 106, third-party service providers 108, and/or backend servers 110 may be included in the system 100 for distributed data aggregation.

In one embodiment, system 100 includes one or more hardware devices 102. Hardware devices 102 (e.g., computing devices, information processing devices, etc.) may include one or more of a desktop computer, a laptop computer, a mobile device, a tablet computer, a smartphone, a set-top box, a gaming console, a smart TV, a smartwatch, a fitness tracker, an optical head-mounted display (e.g., a virtual reality headset, smart glasses, etc.), an HDMI or other electronic display dongle, a personal digital assistant, and/or another computing device including a processor (e.g., a central processing unit (CPU)), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), volatile memory, and/or non-volatile storage media. In some embodiments, as described below, hardware devices 102 communicate with one or more servers 108 and/or one or more backend servers 110 of one or more third-party service providers 108 via a data network 106. In another embodiment, hardware devices 102 are capable of executing various programs, program codes, applications, instructions, functions, and the like.

In one embodiment, the aggregation module 104 is configured to determine and/or receive the user's electronic credentials (e.g., a username and password, a fingerprint scan, a retinal scan, a digital certificate, a personal identification number (PIN), a challenge response, a security token, a hardware token, a software token, a DNA sequence, a signature, facial recognition, voice pattern recognition, bioelectric signals, two-factor authentication credentials, etc.) from one or more third-party service providers 108. In some embodiments, the aggregation module 104 uses the user's electronic credentials to access a server 108 of the third-party service provider 108 to download data related to the user from the server 108, such as the user's photos, the user's social media posts, the user's medical records, the user's financial transaction records or other financial data, and/or other data 108 related to and/or owned by the user but stored by the third-party service provider's server 108 (e.g., data stored by hardware but not owned, maintained, and/or controlled by the user). In various embodiments, the aggregation module 104 can provide the downloaded data locally to the user (e.g., display the data on an electronic display of the hardware device 102); can provide the downloaded data from the user's hardware device 102 and/or package the data and send it to a remote server 110 (e.g., the back-end aggregation module 104b) or other remote device (e.g., another hardware device 102 of the user, a hardware device 102 of a different user, etc.) that can be independent of the third-party service provider 108; can provide one or more alerts, messages, advertisements, or other communication messages to the user (e.g., on the hardware device 102) based on the downloaded data; and so on.

In certain embodiments, the system 100 includes multiple aggregation modules 104 disposed/located on hardware devices 102 of multiple different users (e.g., hardware comprising one or more hardware devices 102 and/or executable code running on one or more hardware devices 102). The multiple aggregation modules 104 can function as a distributed and/or decentralized system 100, executing on multiple hardware devices 102 that are geographically dispersed and utilize different IP addresses, each of which downloads and/or aggregates data (e.g., photos, social media posts, medical records, financial transaction records, other financial data, and/or other user data) in a distributed and/or decentralized manner. While third-party service providers 108 (e.g., financial institutions, banks, credit unions, and/or other online banking providers; social media websites; medical providers; photo hosting sites, etc.) can block data aggregation services or other entities from accessing data of multiple users from a single location (e.g., a single IP address, a single block of IP addresses, etc.), in certain embodiments, a distributed and/or decentralized cluster of many aggregation modules 104 can be more difficult for third-party service providers 108 to block.

In one embodiment, the hardware device 102 may include and/or execute an internet browser that the user may use to access the servers 108 of the third-party service provider 108 (e.g., by loading a webpage of the third-party service provider 108 in the internet browser). In some embodiments, at least a portion of the aggregation module 104 may include a plug-in and/or extension for the internet browser of the user's personal hardware device 102, so that the third-party service provider 108 does not block the aggregation module 104 from accessing the servers 108 of the third-party service provider 108, nor does it block the user from accessing the servers 108 using the internet browser. For example, when the user accesses the servers 108 of the third-party service provider 108 through the internet browser, the aggregation module 104 may use the same cookies, IP address, saved credentials, etc. as the user. In some embodiments, the aggregation module 104 may support integration with multiple different types of internet browsers (e.g., on different hardware devices 102).

In some embodiments, the aggregation module 104 may mimic or replicate the behavior patterns of a user when accessing the server 108 of the third-party service provider 108 to reduce the likelihood that the third-party service provider 108 can distinguish between the aggregation module 104 accessing the server 108 and the user accessing the server 108. For example, the aggregation module 104 may access one or more locations (e.g., web pages) of the server 108 of the third-party service provider 108 even if the aggregation module 104 does not intend to download data from each of the one or more locations, may wait for a certain delay time between accessing different locations, may use a certain scrolling pattern, etc., to disguise that the aggregation module 104 is downloading and/or aggregating the user's data, thereby reducing the chance of being detected and/or blocked by the third-party service provider 108.

In one embodiment, at least a portion of the aggregation module 104 can be integrated with or be part of another application executed on the hardware device 102, for example, the other application is a personal financial management application (e.g., computer executable code for displaying a user's financial transactions at multiple financial institutions, determining and/or displaying a user's financial budget and/or financial goals, determining and/or displaying a user's account balance, determining and/or displaying a user's net worth, etc.), a photo viewer, a medical application, an insurance application, an accounting application, a social media application, etc., and the other application can use the data downloaded by the aggregation module 104 from the server 108 of the third-party service provider 108.

In one embodiment, the aggregation modules 104a comprise a distributed system 100 in which the aggregation modules 104a and/or associated hardware devices 102 download and/or aggregate data substantially independently (e.g., downloading data simultaneously or asynchronously, without a global clock, with independent success and/or failure of components). The distributed aggregation modules 104a can pass messages to each other and/or to a backend aggregation module 104b to coordinate their distributed aggregation of the user's data. In one embodiment, the aggregation modules 104a are decentralized (e.g., the hardware devices 102 associated with the user perform one or more aggregation functions (e.g., downloading data)), rather than relying solely on a central server or other device to perform one or more aggregation functions.

In the distributed and/or decentralized system 100, the central entity (e.g., the backend aggregation module 104b and/or the backend server 110) may, in some embodiments, still provide one or more messages including instructions for accessing the server 108 of the third-party service provider 108 using the user's credentials, etc., to one or more aggregation modules 104a. For example, the backend aggregation module 104b may provide one or more sets of instructions for accessing the server 108 of the third-party service provider 108 to one or more aggregation modules 104a of one or more hardware devices 102, such as a location for entering the user's electronic credentials (e.g., a text box, field, label, coordinates, etc.), instructions for submitting the user's electronic credentials (e.g., pressing a button, clicking a link, etc.), one or more locations of data associated with the user (e.g., a row in a table or chart, a column in a table or chart, a uniform resource locator (URL) or other address, coordinates, label, etc.), and/or other instructions or information that the aggregation module 104a may use to access and download the user's data.

In yet another embodiment, one or more aggregation modules 104a may communicate messages to each other in a peer-to-peer manner, such as instructions for accessing the server 108 of the third-party service provider 108 using the user's credentials, etc. In another embodiment, a central entity (e.g., a backend aggregation module 104b) may initially send one or more sets of instructions for accessing the server 108 of the third-party service provider 108 using the user's credentials to one or more aggregation modules 104a, and one or more aggregation modules 104a may send the one or more sets of instructions to other aggregation modules 104a.

However, in some embodiments, the instructions for accessing user data may change over time, may vary for different users of the third-party service provider 108, etc. (e.g., due to upgrades, different service levels for different users or servers 108, acquisition and/or integration of different third-party service providers 108, etc.), causing certain instructions to fail over time and/or for certain users, thereby preventing the aggregation module 104 from accessing and downloading the user's data. In one embodiment, the back-end aggregation module 104b may provide one or more aggregation modules 104a with a hierarchical list of multiple sets of instructions known to enable access to user data from the servers 108 of the third-party service provider 108. The aggregation module 104a on the hardware device 102 may try the different sets of instructions in a hierarchical order until the aggregation module 104a is able to access the user's data.

In some embodiments, the aggregation module 104 may provide an interface to the user that allows the user to repair or modify failed instructions for accessing user data by graphically identifying the location where the user's electronic credentials were entered, instructions for submitting the user's electronic credentials, the location of data associated with the user, etc. In one embodiment, the aggregation module 104 may highlight or otherwise suggest (e.g., by bolding, coloring, illustrating intuitive annotations or labels, etc.) an estimate of where the aggregation module 104 has determined the user's electronic credentials were entered, the instructions for submitting the user's electronic credentials, the location of data associated with the user, etc. For example, the aggregation module 104 may process a web page on a server 108 of a third-party service provider 108 (e.g., by parsing and/or searching a hypertext markup language (HTML) file) to estimate the location where the user's electronic credentials were entered, the instructions for submitting the user's electronic credentials, the location of data associated with the user, etc.

In some embodiments, the aggregation module 104 may provide a user with an advanced interface to graphically repair interrupted and/or failed instructions for accessing user data from a server 108 of a third-party service provider 108, the advanced interface allowing the user to view the code of a webpage (e.g., HTML, etc.) and identify within the code of the webpage the location where the user's electronic credentials were entered, the instructions for submitting the user's electronic credentials, the location of data associated with the user, etc. In one embodiment, the aggregation module 104 may provide a basic interface to graphically repair interrupted and/or failed instructions for accessing user data from a server 108 of a third-party service provider 108 by overlaying the basic interface on a webpage or other location on the server 108, wherein the user may graphically identify the location where the user's electronic credentials were entered, the instructions for submitting the user's electronic credentials, the location of data associated with the user, etc. (e.g., without requiring the user to view the HTML or other code of the webpage). In some embodiments, the aggregation module 104 may provide an interface including a selectable list of interrupted and/or missing instructions, locations, etc., and may highlight and/or graphically display suggestions in response to the user selecting an item from the list.

In one embodiment, the aggregation module 104 may test the instructions provided by the user (e.g., using a test set) before allowing each aggregation module 104a to use the provided instructions (e.g., to prevent abuse by users providing false or incorrect instructions). The aggregation module 104 may score or rate users based on the success rate of the instructions provided by the users, and may expedite (e.g., provide to a greater number of aggregation modules 104a and/or users) the use of instructions from users with higher scores or ratings. In certain embodiments, the distributed network of aggregation modules 104 may be self-healing and/or self-testing to allow continued access and/or aggregation of a user's data through one or more third-party service providers 108 even if access instructions change or are interrupted.

In certain embodiments, one or more aggregation modules 104 may provide an interface (e.g., an application programming interface (API)) for providing downloaded and/or aggregated user data from one or more third-party service provider servers 108 to one or more other entities (e.g., a remote server 110 independent of the third-party service provider 108 or other hardware devices 102, a back-end aggregation module 104b, etc.). In one embodiment, the interface comprises a dedicated interface between the aggregation module 104a of the user's hardware device 102 and the one or more back-end aggregation modules 104b. For example, this may enable the back-end aggregation module 104b to provide the user with access to download and/or aggregate user data in multiple locations, on multiple hardware devices 102, through multiple channels, etc., even if the user's hardware device 102 downloading the data is turned off, has a dead battery, is not connected to the data network 106, etc. In another embodiment, the interface comprises a secure, public, and/or open interface that allows the user to share the user data downloaded from the aggregation module 104 with one or more other tools, services, and/or other entities for storage, processing, and/or other use of the data.

In various embodiments, the aggregation module 104 may be embodied as hardware, software, or some combination of hardware and software. In one embodiment, the aggregation module 104 may include executable program code stored on a non-transitory computer-readable storage medium, which is executed on a processor of the hardware device 102, the backend server 110, or the like. For example, the aggregation module 104 may be embodied as executable program code that is executed on one or more of the hardware device 102, the backend server 110, one or more combinations of the foregoing, or the like. In this embodiment, the various modules (described below) that perform the operations of the aggregation module 104 may be located on the hardware device 102, the backend server 110, a combination of the foregoing, or the like.

In various embodiments, the aggregation module 104 may be embodied as a device that may be installed or deployed on a backend server 110, on a user's hardware device 102 (e.g., a dongle for the phone 102 or tablet 102, a protective case comprising one or more semiconductor integrated circuit devices within the housing that communicate with the phone 102 or tablet 102 wirelessly and/or via a data port such as a USB or dedicated communication port or another peripheral device), or on a data network 106 and/or collocated with the user's hardware device 102. In some embodiments, the aggregation module 104 may include a hardware device, such as a secure hardware dongle or other hardware application device (e.g., a set-top box, a network device, etc.), which is attached to another hardware device 102 (e.g., a laptop, server, tablet, smartphone, etc.) via a wired connection (e.g., a USB connection) or a wireless connection (e.g., near field communication (NFC), etc.), which is attached to an electronic display device (e.g., a television or monitor using an HDMI port, a DisplayPort port, a Mini DisplayPort port, a VGA port, a DVI port, etc.), which operates substantially independently over the data network 106, etc. The hardware device of the aggregation module 104 may include a power interface, a wired and/or wireless network interface, a graphics interface for output to a display device (e.g., a graphics card and/or GPU having one or more display ports), and/or a semiconductor integrated circuit device as described below, which is configured to perform the functions described herein with respect to the aggregation module 104.

In this embodiment, the aggregation module 104 may include a semiconductor integrated circuit device (e.g., one or more chips, dies, or other discrete logic hardware), such as a field programmable gate array (FPGA) or other programmable logic, firmware for the FPGA or other programmable logic, microcode executed on a microcontroller, an application specific integrated circuit (ASIC), a processor, a processor core, etc. In one embodiment, the aggregation module 104 may be mounted on a printed circuit board having one or more wires or connections (e.g., to volatile memory, non-volatile storage media, a network interface, peripheral devices, or a graphics/display interface). The hardware device may include one or more pins, pads, or other electrical connections configured to send and receive data (e.g., communicating with one or more wires on a printed circuit board), as well as one or more hardware circuits and/or other circuits configured to perform the various functions of the aggregation module 104.

In some embodiments, the semiconductor integrated circuit device or other hardware application of the aggregation module 104 includes and/or is communicatively coupled to one or more volatile storage media, which may include, but is not limited to, random access memory (RAM), dynamic RAM (DRAM), cache, etc. In one embodiment, the semiconductor integrated circuit device or other hardware device of the aggregation module 104 includes and/or is communicatively coupled to one or more non-volatile storage media, which may include, but is not limited to, NAND flash memory, NOR flash memory, nano random access memory (nanoRAM or NRAM), nanocrystal wire-based memory, silicon oxide-based sub-10 nm process memory, graphene memory, silicon oxynitride oxide silicon (SONOS), resistive (RRAM), programmable metallization cell (PMC), conductive bridging RAM (CBRAM), magnetoresistive RAM (MRAM), dynamic RAM (DRAM), phase change RAM (PRAM or PCM), magnetic storage media (e.g., hard disk, tape), optical storage media, etc.

In one embodiment, the data network 106 comprises a digital communication network for transmitting digital communications. The data network 106 may include a wireless network such as a wireless cellular network, a local wireless network such as a Wi-Fi network, a network, a near field communication (NFC) network, an ad hoc network, and/or the like. The data network 106 may include a wide area network (WAN), a storage area network (SAN), a local area network (LAN), a fiber optic network, the Internet, or other digital communication network. The data network 106 may include two or more networks. The data network 106 may include one or more servers, routers, switches, and/or other network devices. The data network 106 may also include one or more computer-readable storage media, such as a hard drive, an optical drive, a non-volatile memory, RAM, and the like.

In one embodiment, the one or more third-party service providers 108 may include one or more network-accessible computing systems, such as one or more web servers hosting one or more websites, corporate intranet systems, application servers, application programming interface (API) servers, authentication servers, and the like. The one or more third-party service providers 108 may include systems associated with various institutions or organizations. For example, the third-party service providers 108 may include systems that provide electronic access to a financial institution, a university, a government agency, a utility company, an email provider, a social media site, a photo sharing site, a video sharing site, a data storage site, a medical provider, or another entity storing data associated with a user. The third-party service provider 108 may allow a user to create a user account to upload, view, create, and/or modify data associated with the user. Thus, the third-party service provider 108 may include an authorization system, such as a login element or page on a website, application, or similar front-end, where a user may provide credentials (e.g., a username/password combination) to access the user's data.

In one embodiment, one or more backend servers 110 and/or one or more backend aggregation modules 104b provide centralized management of the aggregation modules 104a of the networked cluster. For example, one or more backend aggregation modules 104b and/or backend servers 110 may centrally store user data downloaded by the aggregation module 104a, may provide instructions to the aggregation module 104a to access user data from one or more third-party service providers 108 using user credentials, and so on. The backend servers 110 may include one or more servers located remotely from the hardware device 102 and/or the one or more third-party service providers 108. The backend servers 110 may include at least a portion of the modules or sub-modules described below with respect to the aggregation module 104 of Figures 2 and 3, may include the hardware of the aggregation module 104, may store executable program code of the aggregation module 104 in one or more non-transitory computer-readable storage media, and/or may otherwise perform one or more of the various operations of the aggregation module 104 described herein to aggregate user data from one or more third-party service providers in a distributed manner.

2 illustrates one embodiment of the aggregation module 104. In the illustrated embodiment, the aggregation module 104 includes an authentication module 202, a direct access module 204, and an interface module 206.

In one embodiment, the authentication module 202 receives the user's electronic credentials for the third-party service provider 108 from the user on the user's hardware device 102. In another embodiment, the authentication module 202 can receive electronic credentials of different users (e.g., from different hardware devices 102, from the backend aggregation module 104, etc.), and can encrypt and/or otherwise protect the electronic credentials of the different users so that the direct access module 204 can download data of different users (e.g., download data of multiple users from a single user's hardware device 102).

For example, in the distributed/decentralized system 100, if one user's hardware device 102 is turned off, in sleep mode, has a dead battery, is blocked by a third-party service provider 108, etc., then, in some embodiments, the aggregation module 202 on a different user's hardware device 102 and/or on the backend server 110 can download the one user's data using the one user's electronic credentials, and can send the data to the one user's hardware device 102, can send alerts and/or push notifications to the one user's hardware device 102, etc. In one embodiment, in this way, the user can continue to aggregate data, receive alerts and/or push notifications, etc., even if the user's own hardware device 102 is blocked, unavailable, etc. In some embodiments, in cooperation with one or more authentication modules 202, the aggregation modules 104a, 104b can communicate with each other using secure and/or encrypted protocols and/or can store electronic credentials in a secure and/or encrypted manner so that a user cannot see and/or have access to another user's electronic credentials, downloaded data, or other private and/or sensitive data.

In embodiments where the aggregation module 104 comprises hardware (e.g., a semiconductor integrated circuit device such as an FPGA, ASIC, etc.), the authentication module 202 may include dedicated secure hardware for storing and/or processing electronic credentials, downloaded data, and/or other sensitive and/or private data, such as a secure cryptographic processor (e.g., a dedicated computer on a chip or a microprocessor embedded in a package with one or more physical security measures) that does not output decrypted data to an unsecured bus or memory and stores encryption keys, a secure storage device; a Trusted Platform Module (TPM) such as a TPM chip and/or TPM security device; a secure boot ROM or other type of ROM; an authentication chip; etc. In another embodiment, the authentication module 202 may utilize software and/or hardware of the user's existing hardware device 102, with or without dedicated secure hardware, to store and/or process electronic credentials, downloaded data, and/or other sensitive data in a secure and/or encrypted manner (e.g., encrypted data in RAM, NAND, and/or other general-purpose memory). In some embodiments, the authentication module 202 can encrypt and/or protect data (e.g., electronic credentials, downloaded data) associated with a first user but received, processed, and/or stored by a second (e.g., different) user's hardware device 102 (e.g., from the first user's hardware device 102 via a data network 106, etc.) to prevent the second user from accessing the first user's data while still allowing the first user's data to be downloaded and/or aggregated from hardware devices 102 of different users.

In one embodiment, as described above, the electronic credential may include one or more of a username and password, a fingerprint scan, a retinal scan, a digital certificate, a personal identification number (PIN), a challenge response, a security token, a hardware token, a software token, a DNA sequence, a signature, facial recognition, voice pattern recognition, a bioelectric signal, a two-factor authentication credential, or other information, whereby the authentication module 202 may authenticate and/or verify the identity and/or authorization of the user.

In some embodiments, the authentication module 202 may receive from the user different credentials for different accounts of the user at different third-party service providers 108 (e.g., different social networks, different photo sharing websites, different financial institutions), so that the aggregation module 104 can download, aggregate, and/or combine the user's data from multiple different third-party service providers 108. In one embodiment, instead of and/or in addition to receiving one or more passwords or other electronic credentials from the user, the authentication module 202 may also manage and/or determine one or more passwords or other electronic credentials of the user for one or more third-party service providers 108, as described below with respect to the password manager module 306 of FIG3. For example, in some embodiments, the authentication module 202 may receive from the user a set of initial electronic credentials (e.g., a username and password) for the user's account at a third-party service provider 108, and the authentication module 202 may use the initial set of electronic credentials to access the user's account at the third-party service provider 108 to set a new password 202 determined by the authentication module. In one embodiment, the authentication module 202 can determine a password or other electronic credential that is more secure (e.g., longer, has more numbers, more variation between uppercase and lowercase letters, changes more frequently, etc.) than those typically created by a user and/or stored by a user.

In one embodiment, the direct access module 204 uses the user's electronic credentials from the authentication module 202 (e.g., the electronic credentials of the user associated with the hardware device 102, the electronic credentials of a different user, etc.) to access one or more servers 108 of one or more third-party service providers 108 via the user's hardware device 102 and/or the backend server 110. In some embodiments, instead of downloading the data directly to the user's hardware device 102 or in addition to downloading the data directly to the user's hardware device 102 (e.g., based on the availability of the user's hardware device 102, to back up the data in a secondary location, etc.), the direct access module 204 also downloads data associated with the user (e.g., the user's social media posts, the user's photos, the user's financial transactions, etc.) from the one or more servers 108 of the one or more third-party service providers 108 to the user's hardware device 102 (e.g., the user's hardware device 102 associated with the downloaded data; a different user's hardware device 102 that processes and/or transmits the downloaded data to the user's hardware device 102 associated with the downloaded data) and/or to the backend server 110 associated with the direct access module 204.

In some embodiments, the direct access module 204 can use a web page interface of the server 108 of the third-party service provider 108 to access the server 108 and/or download data associated with the user using the user's electronic credentials. For example, in some embodiments, the direct access module 204 can download/load a web page from the server 108 of the third-party service provider 108, enter the user's username and password or other electronic credentials into text boxes in a form on the web page, submit the username and password or other electronic credentials using a submit button or other interface element of the web page, and/or submit the electronic credentials in other ways using a website to obtain authorization to access data on the server 108 associated with the user. As described below, the mode module 308 can receive and/or provide instructions that enable the direct access module 204 to access the server 108 (e.g., the location or method for submitting the electronic credentials, etc.).

In response to successfully authenticating and accessing the server 108 of the third-party service provider 108 using the user's electronic credentials, the direct access module 204 can download data associated with the user (e.g., from the user's account, etc.) from the server 108 to a hardware device 102 associated with the user, a backend server 110, another user's hardware device 102 downloading data on behalf of the user, etc. As described below, in some embodiments, the schema module 308 can receive and/or provide instructions (e.g., a URL or other link indicating the location of the data, a tag or other identifier for locating the data within one or more web pages or other data structures, etc.) that enable the direct access module 204 to download the data associated with the user from the server 108 of the third-party service provider 108. In some embodiments, the direct access module 204 can authenticate and/or access data from one or more web pages of the server 108 in a screen scraping manner, pursuant to the instructions of the schema module 308, to locate input locations and/or submit electronic credentials by parsing the one or more web pages; to locate, download, and/or extract data associated with the user; etc.

In one embodiment, the direct access module 204 sends or otherwise submits electronic credentials and/or receives or otherwise downloads data using an API or other access protocol of the server 108 of the third-party service provider 108. For example, the direct access module 204 may send a request in a format specified by and/or compatible with the server 108 of the third-party service provider 108 (e.g., the API server 108). The sent request may include the user's electronic credentials or a portion thereof (e.g., a username and/or password), subsequent requests may include the user's electronic credentials or a portion thereof (e.g., in response to a confirmation received from the server 108 for the first request, etc.), and/or the direct access module 204 may use a different access protocol of the server 108.

In response to a request for data from the direct access module 204 (e.g., in response to the direct access module 204 authenticating the user using the server 108's access protocol), the server 108 of the third-party service provider 108 may send and/or return data related to the user (e.g., data in one or more messages, packets, payloads, as a URL or other pointer to a location from which the direct access module 204 can obtain the data, etc.). In various embodiments, the direct access module 204 may receive the data related to the user directly from the server 108 of the third-party service provider 108 over the data network 106; may receive a pointer, URL or other link to the location of the data related to the user from the server 108 of the third-party service provider 108; may receive the data related to the user from another entity on the data network 106 (e.g., in response to a request from the server 108 of the third-party service provider 108 to the other entity, etc.); or may otherwise receive the data related to the user in accordance with the access protocol of the third-party service provider 108.

In one embodiment, the third-party service provider 108 provides an API or other access protocol to the direct access module 204. In another embodiment, the direct access module 204 can act as a wrapper and/or plug-in or extension for an application (e.g., a mobile application) of the third-party service provider 108, and the application can access the API or other access protocol of the third-party service provider 108. In another embodiment, the direct access module 204 can be configured to use the API or other access protocol in the same manner as the application (e.g., mobile application) of the third-party service provider 108, by observing the application of the third-party service provider 108, etc. In some embodiments, the direct access module 204 can cooperate with the application of the third-party service provider 108, the web browser through which the user accesses the services of the third-party service provider 108, etc. to access data related to the user (e.g., access data that the application and/or user has downloaded, access a database or other data store of the application and/or web browser, scan and/or screen scrape the web pages of the third-party service provider 108 when the user accesses the web pages, etc.).

In some embodiments, the direct access module 204 can access different third-party service providers 108 in different ways. For example, a first third-party service provider 108 can grant the direct access module 204 access to an API or other access protocol, while the direct access module 204 can use a web interface (e.g., screen scraping) to access and download data from a second third-party service provider 108, and so on. In one embodiment, a remote backend server 110 can be associated with the first-party service provider 110 (e.g., a vendor and/or provider of the aggregation module 104), and the direct access module 204 can download data related to the user from the first-party service provider 110 and one or more third-party service providers 108, aggregating the data so that the user can access the data within a single interface and/or application. For example, as described below with respect to the interface module 206, the interface module 206 can provide the user with access to the user's photos across multiple third-party cloud storage providers 108 within a single photo application, can provide the user with access to the user's personal financial information within a single personal finance management application and/or online banking application, can provide the user with access to posts on multiple social networks within a single social networking application, and so on.

In some embodiments, the direct access module 204 can store the downloaded and/or aggregated data independently of one or more third-party service providers 108. For example, the direct access module 204 can store the user's downloaded and/or aggregated data on the user's hardware device 102, on a backend server 110 accessible to the user, etc. In this manner, in some embodiments, the user can control and/or access the user's data even if the third-party service provider 108 is down or unavailable, the user can use the user's data in any manner the user desires even if the third-party service provider 108 does not support its use, etc.

In one embodiment, in addition to and/or in lieu of downloading data from one or more third-party service providers 108, direct access module 204 may also upload data to one or more third-party service providers 108 and/or change one or more settings of one or more third-party service providers 108 in response to user input, etc. For example, in embodiments where the data includes photos, direct access module 204 may upload photos from the user's hardware device 102 to one or more third-party service providers 110 (e.g., downloaded photos that the user has edited on hardware device 102, etc.). In embodiments where the data includes social media posts or other content, direct access module 204 may receive input from the user (e.g., a photo, a text post, one or more emoticons, a video, a document or other file, etc.) and upload the received input to one or more third-party service providers 108 (e.g., a social media website, etc.). In embodiments where the data includes financial transactions or other financial data, direct access module 204 may arrange for a bill payment or other payment or funds transfer, remotely deposit a check (e.g., by uploading photos of the front and/or back of the check, etc.), and/or perform another action.

The direct access module 204 can update or change the user's account information with the third-party service provider 108, such as the account type or plan, credit card or other payment information associated with the account, phone number or address or other information associated with the account, a password or other electronic credentials for the account, and/or other account information of the user with the third-party service provider 108. The direct access module 204 can update and/or upload data in a manner substantially similar to that described herein for downloading data (e.g., determining the user's electronic credentials to the third-party service provider 108, accessing the server 108 of the third-party service provider 108, uploading and/or providing data to the third-party service provider 108, etc.).

In one embodiment, the interface module 206 provides the user data downloaded by the direct access module 204 from the user's hardware device 102 (e.g., the user's hardware device 102 associated with the downloaded data, a different user's hardware device 102) to another user entity, e.g., the user's hardware device 102 associated with the downloaded data (e.g., in response to a different user's hardware device 102 providing the data from one hardware device 102 of the user to another hardware device 102 of the same user), a remote server 110 or other remote device 102 that is not dependent on (e.g., not owned by, not operated by, not controlled by, etc.) the third-party service provider 108 from which the data was downloaded, etc. For example, the interface module 206 may provide an API or other interface to provide the user's downloaded and/or aggregated data to the user's hardware device 102, the backend aggregation module 104b, the backend server 110, a different third-party service provider 108, a different/second hardware device 102 of the user, etc.

In some embodiments, it can be transparent and/or substantially transparent (e.g., not obvious) to the user which hardware device 102, 110 has downloaded the data associated with the user. For example, the interface module 206 can provide the downloaded data associated with the user from one hardware device 102 of the user to another hardware device 102 of the user, from the user's hardware device 102 to the backend server 110 (e.g., the user can use a web browser, an application, etc. to access the data through the backend server 110), from the backend server 110 to the user's hardware device 102, etc., thereby allowing the user to access the data from a location different from the location from which the data was downloaded.

In some embodiments, the interface module 206 provides a graphical user interface (GUI) on the user's hardware device 102 and provides the downloaded data related to the user to the user through the GUI (e.g., allowing the user to directly view the data, providing the user with one or more notifications and/or recommendations based on the data, providing the user with one or more tables or charts based on the data, providing a summary or one or more statistics related to the data, etc.). In various embodiments, the interface module 206 can provide the GUI to the user on the same hardware device 102 as the hardware device 102 from which the data was downloaded, can provide the GUI to the user on a hardware device 102 different from the hardware device 102, 110 from which the data was downloaded, etc.

For example, in one embodiment, where the data associated with the user includes photos, the interface module 206 may provide a photo management interface, a photo editing interface, etc., where the user can view and/or otherwise access the user's downloaded and/or aggregated photos. In another embodiment, where the data associated with the user includes the user's financial transaction history (e.g., purchases and/or other financial transactions downloaded from one or more financial institutions 108 (e.g., banks, credit unions, lenders, etc.), the interface module 206 may provide a personal financial management interface having a transaction list, one or more budgets, one or more financial goals, a debt management interface, a net worth interface, and/or another personal financial management interface, where the user can view the user's downloaded and/or aggregated financial transaction history and/or alerts or recommendations based on the financial transaction history. In another embodiment, where the data associated with the user includes social media posts, the interface module 206 may provide a GUI that includes a feed, feed, and/or wall post of social media posts for the user to view (e.g., downloaded and/or aggregated social media posts from multiple social networks 108, from the user's different contacts or friends, etc.).

In some embodiments, the interface module 206 can provide one or more access controls to the user to allow the user to define which devices 102, users, third-party service providers 110, etc. can access which data. For example, the interface module 206 can provide the user with an interface to allow and/or restrict certain mobile applications, certain APIs for third-party services, certain plug-ins or extensions, certain users, certain hardware devices 102, and/or one or more other entities from accessing data downloaded from one or more third-party service providers 108 (e.g., access control by third-party service provider 108 or other data source, by data type, by entity requesting access, and/or another granularity). In this way, in some embodiments, the aggregation module 104 can include a local repository of aggregated data, where one or more other devices 102 and/or services can access and use the local repository with the user's permission.

3 illustrates another embodiment of the aggregation module 104. In the illustrated embodiment, the aggregation module 104 includes the authentication module 202, the direct access module 204, and the interface module 206, and also includes a routing module 314, a frequency module 316, and a testing module 318. In the illustrated embodiment, the authentication module 202 includes a local authentication module 302, a network authentication module 304, and a password manager module 306. In the illustrated embodiment, the direct access module 204 includes a mode module 308, an access repair module 310, and a hierarchy module 312.

In one embodiment, the local authentication module 302 authenticates and/or secures a user's access to downloaded data, stored passwords, and/or other data on, transmitted to, and/or from the user's hardware device 102, and/or the like. For example, the local authentication module 302 can collaborate with one or more security and/or authentication systems of the user's hardware device 102 (e.g., a PIN, password, fingerprint authentication, facial recognition, or other electronic credentials used by the user) to gain access to the hardware device 102. In another embodiment, the local authentication module 302 can authenticate a user before allowing the interface module 206 to provide the user with access to downloaded/aggregated data and/or alerts or other messages. For example, the local authentication module 302 can manage and/or access electronic credentials associated with the aggregation module 104 for the user and can authenticate the user in response to the user accessing an application and/or service of the aggregation module 104.

In some embodiments, the local authentication module 302 can encrypt and/or otherwise protect electronic credentials and/or downloaded data associated with a different user on the user's hardware device 102 so that the user cannot access data related to the different user, but the different user can access the data once the data is sent to the different user's hardware device 102, backend server 110, etc. The local authentication modules 302 of different hardware devices 102, 110 can cooperate to securely transmit data (e.g., one or more electronic credentials, downloaded data, etc.) from one hardware device 102, 110 to another hardware device 102, 110 over the data network 106. In another embodiment, the local authentication module 302 can ensure that the user's electronic credentials and/or downloaded data remain on a single hardware device 102 (e.g., not transmitted over the data network 106), remain in a secure repository, etc., and are not stored on and/or inaccessible to the backend server 110, another user's hardware device 102, etc.

In one embodiment, the network authentication module 304 receives and/or stores the user's electronic credentials for one or more third-party service providers 108 on the user's hardware device 102, on a backend server 110, etc. In various embodiments, the network authentication module 304 may receive the user's electronic credentials from the user, from the user's hardware device 102, from a backend server 110, etc. The network authentication module 304 may cooperate with the direct access module 204 to provide the user's electronic credentials to a server 108 of a third-party service provider 108 (e.g., the network authentication module 304 may provide the electronic credentials to the direct access module 204 to provide it to the server 108, the network authentication module 304 may provide the electronic credentials directly to the server 108, etc.).

In some embodiments, the network authentication module 304 can cooperate with the local authentication module 302 to encrypt and/or otherwise protect the user's electronic credentials for one or more third-party service providers 108 on the user's hardware device 102, on the data network 106, on a different user's hardware device 102, on a backend server 110, while providing the user's electronic credentials to the servers 108 of the third-party service providers 108, etc. In another embodiment, the network authentication module 304 ensures that the user's electronic credentials are only stored on the user's hardware device 102 and sent from the user's hardware device 102 to the servers 108 of the third-party service providers 108, and does not store the user's electronic credentials on the backend server 110, on a different user's hardware device 102, etc. In another embodiment, the network authentication module 304 can securely store (e.g., using secure encryption) a user's electronic credentials for a third-party service provider 108 on a backend server 110, on a different user's hardware device 102, etc., so that, as described below with respect to the routing module 314, the direct access module 204 can access and/or download data associated with the user even if the user's hardware device 102 is unavailable, blocked, etc. In some embodiments, whether the network authentication module 304 and/or the local authentication module 302 allows the electronic credentials to be sent to and/or stored by a different user's hardware device 102, backend server 110, etc. can be based on settings defined based on user input so that the user can determine the security level, etc.

In one embodiment, the password manager module 306 can manage and/or store the user's electronic credentials for multiple third-party service providers 108 so that the direct access module 204 can access and/or download data related to the user from each of the multiple third-party service providers 108. In certain embodiments, the password manager module 306 can generate and/or otherwise manage different secure credentials for each of the multiple third-party service providers 108.

In one embodiment, the password manager module 306 can securely store the generated user's credentials on the user's hardware device 102 so that the user does not have to remember and enter the generated electronic credentials. For example, in addition to allowing the direct access module 204 to access the third-party service provider 108 using the generated electronic credentials, the password manager module 306 can automatically fill in the electronic credentials (e.g., username, password) into one or more interface elements of a form on the interface web page in response to the user accessing a web page in a web browser, etc., without requiring the user to manually enter the electronic credentials. In some embodiments, the password manager module 306 can periodically update (e.g., regenerate different credentials (e.g., different passwords) and update the user's account with the third-party service provider 108 using the regenerated different credentials) the user's electronic credentials, for example, weekly, monthly, every two months, every three months, every four months, every five months, every six months, every year, or every two years, in response to a request from the user, in response to a request from the third-party service provider 108, and/or at another time period or in response to another periodic trigger.

In one embodiment, the password manager module 306 can synchronize the user's electronic credentials (e.g., electronic credentials provided by the user, electronic credentials generated by the password manager module 306, etc.) across the user's different hardware devices 102, web browsers, etc. For example, in response to the password manager module 306 and/or the user updating or otherwise changing the electronic credentials, the password manager module 306 can propagate the update/change to one or more other password manager modules 306 on the user's different hardware devices 102, etc.

In one embodiment, the pattern module 308 determines an ordered list (e.g., a pattern, script, etc.) of multiple locations (e.g., which may include locations other than locations where data of a user is stored and/or accessed) on one or more servers of a third-party service provider 108 for the direct access module 204 to access the server, one or more delays for the direct access module 204 to wait between accessing different locations on the server 108, and/or other portions of an access pattern for accessing data from the server. In some embodiments, the locations include independently addressable and/or accessible content and/or assets provided by one or more servers of the third-party service provider 108, such as a web page, a portion of a web page, an image or other data file, a database or other data storage, a page or portion of a mobile application, and the like. In one embodiment, the pattern module 308 determines a pattern/ordered list that includes one or more locations and/or delays that are not necessary for the direct access module 204 to access or use the server to download the requested data, and in fact, the pattern/ordered list may make it difficult or impossible for the third-party service provider 108 to distinguish between the direct access module 204 accessing the server of the third-party service provider 108 and a user accessing the server of the third-party service provider.

In one embodiment, the pattern module 308 may determine and/or select a plurality of locations and/or one or more delays (e.g., a pattern/ordered list) based on an average or combined pattern identified from the behavior of a plurality of users accessing the third-party service provider 108 using a web browser, mobile application, or the like, or based on such behavior. In one embodiment, the pattern module 308 may monitor the one or more users as they access the servers of the third-party service provider 108 (e.g., for a predetermined period of time, etc.), tracking which links, data, web pages, and/or other locations the one or more users access, how long the one or more users take to access different locations, the order in which the one or more users access the multiple locations, etc. In some embodiments, the one or more monitored users may be volunteers who have provided authorization to the pattern module 308 to monitor the users' access, either temporarily or permanently, in order to provide the direct access module 204 with a more realistic access pattern for accessing the servers of the third-party service provider 108.

In another embodiment, the pattern module 308 determines and/or selects multiple locations and/or one or more delays between visiting different locations based on patterns identified in the behavior of a user associated with the hardware device 102 on which the pattern module 308 is located, the user's behavior including accessing a third-party service using a web browser, mobile or desktop application, or other interface of the user's hardware device 102. For example, the pattern module 308 may include network hardware of the user's hardware device 102 (e.g., a network access card and/or chip, processor, FPGA, ASIC, etc. that communicates with the data network 106 to monitor data and/or interactions with servers of third-party service providers 108), a web browser plug-in or extension, a mobile and/or desktop application executed on a processor of the user's hardware device 102, etc. The pattern module 308 may request and obtain authorization from the user to monitor user activity made to one or more servers of one or more third-party service providers 108 via the user's hardware device 102.

In certain embodiments, the pattern module 308 may update the pattern/ordered list over time based on detected changes in access patterns of one or more users, etc. In one embodiment, the pattern module 308 may coordinate and/or collaborate with the access repair module 310 , described below, to update the pattern/ordered list in response to a server 108 of a third-party service provider 108 and/or data associated with a user becoming disrupted and/or inaccessible.

In one embodiment, the access repair module 310 detects that access to a server 108 of a third-party service 108 and/or data associated with the user is interrupted and/or becomes inaccessible. In some embodiments, the access repair module 310 provides an interface to the user to allow the user to graphically identify the location where the user's electronic credentials were entered, the location of data associated with the user, etc. For example, the access repair module 310 may provide a GUI, a command line interface (CLI), an API, and/or another interface that allows the end user to identify the location where the electronic credentials were entered, the action of submitting the electronic credentials, the location of the data, etc. In one embodiment, the access repair module 310 provides the interface to the user on the user's hardware device 102.

5A-5B , the access repair module 310 may overlay an interface on one or more pages of a website of the third-party service provider 108 on an electronic display screen of a user's hardware device 102. The access repair module 310 may provide one or more interfaces (e.g., a GUI, a CLI, an API, an overlay, etc.) to multiple users to allow the multiple users to define repairs and/or updates for accessing a server of the third-party service provider 108 (e.g., accessed in a distributed and/or decentralized manner across different hardware devices 102 or the like on the network 106, etc.).

In some embodiments, the access repair module 310 can determine and/or display one or more suggestions 504 and/or recommendations 504 for the user, which the user can confirm or change/revise (e.g., in a base interface, a standard interface, an initial user interface, etc.). For example, the access repair module 310 can display one or more interface elements having a suggested location for the user to enter a username, a suggested location for the user to enter a password, a suggested credential submission action, a suggested location for data related to the user, and/or one or more other interface elements that allow the user to graphically identify one or more locations within the website of the third-party service provider 108.

In some embodiments, the access repair module 310 processes one or more pages and/or other locations on the server 108 (e.g., one or more websites, web applications, etc.) to determine estimates and/or predictions of the location where the user's electronic credentials were entered, the action of submitting the user's electronic credentials, the location of data associated with the user, etc. In one embodiment, the access repair module 310 may estimate the one or more locations and/or actions (e.g., by scanning and/or parsing one or more pages of the website, based on input from other users who visited one or more pages of the website, based on the user's previous interactions with one or more pages of the website, predictions made using machine learning and/or artificial intelligence analysis of the website, based on statistical analysis of historical changes to one or more pages of the website and/or one or more similar websites, etc.). The access repair module 310 may display the estimates and/or predictions of the location where the user's electronic credentials were entered, the location of data associated with the user, etc. to the user in an interface so that the user can use the interface to confirm whether the estimates and/or predictions are correct.

The access repair module 310 may indicate one or more estimated locations and/or actions using an arrow or other pointing indicator pointing to the location; a link or other identifier for the location; a box or other highlighting around the location; changing the location's text label to make the text bold, italic, and/or underlined, etc. In some embodiments, a user may click on, select, or otherwise identify a location to confirm or change/correct the location suggested by the access repair module 310. For example, a user may click on or otherwise select an interface element associated with a location and/or action, and may click on or otherwise select the location and/or perform the action, and the access repair module 310 may record the above actions (e.g., automatically fill in text fields identifying locations and/or actions, record macros of actions that can be automatically repeated without the user for use by different users, etc.).

In some embodiments, instead of or in addition to the standard, basic, or initial user interface, the access repair module 310 can provide an advanced interface for experienced users and the like that has the source code of the website and/or other details of the website. For example, in one embodiment, the advanced access repair interface can allow one or more advanced users to identify one or more locations and/or actions within the source code of the website that may not be visible and/or obvious in the website itself. In some embodiments, the access repair module 310 can provide a user interface element that allows the user to select and/or switch the interface between a standard user interface or view and an advanced user interface or view.

In one embodiment, the testing module 318 cooperates with the access repair module 310 to verify that one or more locations and/or instructions received from a user are accurate (e.g., data that can be used to access a server of a third-party service provider 108). In some embodiments, the testing module 318 attempts to access a server 108 of a third-party service provider 108 for multiple different users (e.g., a sample group or test set) using the different users' electronic credentials, etc., based on an identification received from a single user by the access repair module 310.

In some embodiments, the testing module 318 determines whether data associated with different users (e.g., a sample group or test set) can be accessed using the identifier of a single user. The testing module 318 can repeatedly attempt to access data from the third-party service provider 108 using identifiers received from different users by the access repair module 310 (e.g., on different hardware devices 102 and sent over the data network 106 to a testing module 318 on a single hardware device 102, to multiple testing modules 318 on different hardware devices 102 over the data network 106, to a testing module 318 on a central backend server 110, etc.).

In one embodiment, the testing module 318 provides one or more identifications from the user to other instances of the direct access module 204 (e.g., other testing modules 318) to access the server 108 of the third-party service provider 108 in response to a threshold number of different users (e.g., a sample group or test set) that can access data on the server 108 using the identification of the single user. For example, if the identification of the single user successfully allows a predetermined number of other test users (e.g., 2 users, 10 users, 100 users, 1000 users, 50% of the test users, 75% of the test users, and/or another predetermined threshold number of test users) to access their data through the third-party service provider 108, the testing module 318 can provide instructions to more users (e.g., all or substantially all users, etc.) based on the identification.

In some embodiments, the testing module 318 can progressively increase the scope of the test to include multiple users, wherein the testing module 318 provides multiple users with instructions to access their data from the third-party service provider 108 using the identification of a single user (e.g., starting with one or more test users and increasing to two or more, three or more, four or more, five or more, ten or more, twenty or more, thirty or more, forty or more, fifty or more, one hundred or more, five hundred or more, one thousand or more, five thousand or more, ten thousand or more, one hundred thousand or more, one million or more, and/or other progressively increasing numbers of test users). In one embodiment, as described in more detail below with respect to the hierarchy module 312, the testing module 318 includes instructions based on the identification of a single user in an ordered list of a plurality of different instruction groups for accessing the server 108 of the third-party service provider 108.

In some embodiments, the testing module 318 is configured to prioritize the identification of one or more users based on one or more trust factors (e.g., scores, etc.) of the one or more users. In one embodiment, the trust factor may include a score or other metadata indicating the likelihood that the user's identification is correct. For example, in various embodiments, the trust factor may include and/or be based on the user's history of previous identifications (e.g., correct or incorrect), the user's close relationship with one or more providers of the aggregation module 104 (e.g., creator, vendor, owner, seller, reseller, manufacturer, backend server 110, etc.), positive and/or negative indications from other users (e.g., votes, likes, usage, feedback, star ratings, endorsements, etc.), and/or other indications of whether the user's identification is likely to be correct. The testing module 318 may determine how many other users provide the user's identification based on the one or more trust factors associated with the user (e.g., speed up the rate at which the user's identification is provided to other users in response to a higher trust factor, slow down the rate at which the user's identification is provided to other users in response to a lower trust factor, etc.)

The testing module 318 may provide an overlay interface that allows an administrator, moderator user, or the like to remove identification, adjust and/or overlay identification, adjust and/or overlay a user's trust factor, prohibit a user from providing identification, and/or otherwise overlay a user or user's identification. In various embodiments, the testing module 318 may provide an overlay interface such as a GUI, an API, a CLI, or the like to the administrator and/or moderator.

In certain embodiments, the testing module 318 enables one or more aggregation modules 104 and their aggregation services to self-heal, self-test, and/or self-incrementally deploy as the testing module 318 tests and uses the most effective solutions, etc. (e.g., based on multiple sets of instructions from one or more users).

In one embodiment, the hierarchy module 312 provides the direct access module 204 with an ordered list of a plurality of different sets of instructions for accessing a server 108 of a third-party service provider 108 using the user's electronic credentials, for downloading data associated with the user, etc. In some embodiments, each different set of instructions includes a location for entering the user's electronic credentials, instructions for submitting the user's electronic credentials, one or more locations for data associated with the user, etc.

In one embodiment, the hierarchy module 312 may receive one or more sets of instructions from a backend server 110 (e.g., the backend aggregation module 104b of the backend server 110), in a peer-to-peer manner from another user hardware device 102 (e.g., the aggregation module 104a of the user hardware device 102), from a testing module 318, etc. In some embodiments, the hierarchy module 312 may receive a plurality of different instruction groups that already exist in an ordered list (e.g., a global hierarchical order) based on a history of successful and/or unsuccessful use of the plurality of different instruction groups by different user hardware devices 102 and/or users, etc. In one embodiment, the hierarchy module 312 may determine a hierarchy and/or create an ordered list (e.g., a customized or personalized hierarchy) for a single user from the plurality of different instruction groups based on a history of successful and/or unsuccessful use of the plurality of different instruction groups by the user (e.g., via one or more of the user's hardware devices 102).

In one embodiment, the direct access module 104 may traverse the ordered list of multiple sets of instructions for accessing the servers 108 of the third-party service providers 108 in the order of the list until one of the sets of instructions is successful and the direct access module 104 is able to access and/or download data from the third-party service provider 108. In one embodiment, the hierarchy module 312 may place the set of instructions that was most recently used successfully at the top (e.g., as the first set of instructions to be attempted). For example, the hierarchy module 312 of the user's hardware device 102 may place a set of instructions for accessing the third-party service provider 108 at the top of the list in response to the direct access module 204 successfully accessing and/or downloading data from the third-party service provider 108 using the set of instructions (e.g., adjusting the order of the list over time). In some embodiments, the hierarchy module 312 can receive an ordered list of multiple different instruction groups for accessing a server 108 of a third-party service provider 108 arranged in a first order (e.g., a global order), and can dynamically adjust and/or rearrange the multiple different instruction groups over time based on usage by a single user/hardware device 102 (e.g., if access using a set of instructions is successful for the user/hardware device 102, then move the set of instructions up in the list, and if access using a set of instructions is unsuccessful for the user/hardware device 102, then move the set of instructions down in the list).

In some embodiments, the hierarchy module 312 can be configured to share one or more sets of instructions, ordered lists of multiple sets of instructions, etc., with the hierarchy module 312 of another user's hardware device 102 via the data network 106 (e.g., directly with the hardware device 102 of another user in a peer-to-peer manner, or indirectly via the backend aggregation module 104b of the backend server 110). In various embodiments, multiple different sets of instructions may succeed or fail for different users due to different account types, different account settings, different source systems (e.g., different users of the same third-party service provider 108 may have one or more different settings, different access methods, etc. due to company acquisitions, etc.), system changes or upgrades, and/or other differences in accounts, services, etc., between different users of the same third-party service provider 108.

In one embodiment, the routing module 314 determines whether the user's hardware device 102 is available for the direct access module 204 to download the data associated with the user from the server 108 of the third-party service provider 108. In some embodiments, the routing module 314 may, in response to the routing module 314 determining that the user's hardware device 102 is unavailable, use the user's electronic credentials to access the server 108 of the third-party service provider 108 through the remote backend server 110 to download the data associated with the user from the server 108 to the remote backend server 110. In one embodiment, the routing module 314 provides one or more alerts (e.g., data downloaded from the third-party service provider 108, recommendations or suggestions determined based on the data from the third-party service provider 108, notifications or other alerts based on events or other triggers detected in the data from the third-party service provider 108, etc.) to the user on the user's hardware device 102 based on the data associated with the user downloaded to the remote backend server 110.

In some embodiments, the routing module 314 maintains and/or stores a list of multiple hardware devices 102 associated with a single user and/or account. In response to determining that one hardware device 102 associated with the user and/or account is unavailable (e.g., powered off, in airplane mode, not connected to the data network 106, etc.), the routing module 314 can access the server 108 of the third-party service provider 108 through a different available hardware device 102 of the user and/or account, can provide one or more notifications or other alerts on the different available hardware device 102, etc. In various embodiments described below with respect to Figures 4A-4C, the routing module 314 can dynamically route data downloaded from the third-party service provider 108 to the user between multiple hardware devices in a secure manner, for example, one or more hardware devices 102 of the user, one or more hardware devices 102 of a different user, one or more backend servers 110, and/or another hardware device.

In one embodiment, the routing module 314 can alternate or cycle between multiple hardware devices 102, 110 (e.g., hardware devices of the same user, different users, etc.) that are used to periodically download data from the third-party service provider 108 for the same user. For example, cycling and/or alternating the devices 102, 110 from which data is downloaded can reduce the likelihood that the downloads will be misinterpreted as fraudulent or inappropriate. In another embodiment, the routing module 314 can download data from the same device 102, 110 (e.g., the user's primary hardware device 102, the backend server 110, etc.), which can be authorized and/or identified as a trusted device by the third-party service provider 108, etc.

In one embodiment, the frequency module 316 sets the frequency with which the direct access module 204 accesses the server 108 of the third-party service provider 108. In some embodiments, the frequency module 316 determines the frequency based on input from a remote backend server 110, which may be independent of the third-party service provider 108 being accessed, such that the remote backend server 110 (e.g., the frequency module 316 executing on the remote backend server 110) determines the frequency for multiple direct access modules 204 for different users and/or different hardware devices 102. For example, the frequency module 316 can limit a single user and/or hardware device 102 from accessing the same third-party service provider 108 to no more than a threshold number of times allowed within a period of time (e.g., once every ten minutes, once every half hour, once every hour, twice a day, three times a day, four times a day, etc.). In some embodiments, the frequency module 316 limits the access frequency to prevent the third-party service provider 108 from unintentionally denying service, etc.

In certain embodiments, the frequency module 316 can dynamically adjust the frequency with which a user and/or hardware device 102 can access a third-party service provider 108 over time. For example, the frequency module 316 can monitor the access and/or downloads of multiple users (e.g., all users, available users, active users, etc.) to limit or restrict the total access and/or download bandwidth to each of the different third-party service providers 108 (e.g., to avoid overusing any single third-party service provider 108, etc.). In one embodiment, in this manner, when fewer other users and/or hardware devices 102 are accessing and/or downloading data (e.g., during off-peak hours), the user and/or hardware device 102 can access and/or download data at a higher frequency, but when more other users and/or hardware devices 102 are accessing and/or downloading data (e.g., during peak hours), the user and/or hardware device 102 can be restricted to a lower cap or access frequency.

In another embodiment, the frequency module 316 determines the frequency based on user input to allow the user to set the access frequency independently of other users and/or the backend server 110. The frequency module 316 can provide a user interface (e.g., a GUI, a CLI, an API, etc.) that allows the user to set and/or adjust the access frequency for downloading data from one or more third-party service providers 108 using one or more hardware devices 102 (e.g., providing different settings to allow the user to set different access frequencies for different third-party service providers 108, different hardware devices 102 of the user, etc.).

FIG4A illustrates one embodiment of a system 400 for distributed/decentralized data aggregation. In the illustrated embodiment, the system 400 includes a single user hardware device 102 having an aggregation module 104a. In certain embodiments, the authentication module 202 of the aggregation module 104a can locally store and/or manage the user's electronic credentials on the user's hardware device 102, the direct access module 204 can access one or more third-party service providers 108 directly from the user's hardware device 102 (e.g., via the data network 106) to download data related to the user to the user's hardware device 102, the interface module 206 can provide data and/or one or more alerts/messages to the user based on the data from the user's hardware device 102, and the like. In the illustrated system 400, the aggregation module 104a can create a local repository of data from one or more third-party service providers 108 for the user on the user's hardware device 102, without requiring the user's credentials, the user's data, etc. to be provided to different user hardware devices, backend servers 110, etc.

4B illustrates one embodiment of a system 402 for distributed/decentralized data aggregation. In the illustrated embodiment, the system 402 includes multiple user hardware devices 102 associated with different users each having an aggregation module 104a. In some embodiments, a first aggregation module 104a (e.g., the authentication module 202 of the first aggregation module 104a) may securely provide, via a data network 106 or the like, encrypted user credentials of a first user from the first user's hardware device 102a to a second aggregation module 104a (e.g., the authentication module 202 of the second aggregation module 104a), so that the direct access module 204 of the second aggregation module 104a may access, via the second user's hardware device 102b, one or more third-party service providers 108 (e.g., via the data network 106) to download data associated with the first user.

For example, the second user's hardware device 102b may download data for the first user in response to the first user's hardware device 102a being powered off, dormant, blocked from accessing one or more third-party service providers 108, etc., as determined by the routing module 314. The interface module 206 of the second aggregation module 104a may provide one or more alerts/messages to the first user based on the downloaded data, and/or may provide the downloaded data to the first user (e.g., to a different hardware device 102 associated with the first user in response to the first user's hardware device 102a becoming available, to a backend server 110 accessible to the first user, etc.). As described above, in some embodiments, the authentication module 202, the direct access module 204, the interface module 206, and/or the routing module 314 may encrypt and/or otherwise protect the first user's data (e.g., the first user's electronic credentials, downloaded data associated with the first user, alerts/messages for the first user) to make it difficult or impossible for the second user to access the first user's data, thereby preventing and/or minimizing unauthorized access to the first user's data, while also providing greater flexibility in the devices 102 and/or locations from which the first user's data is downloaded.

4C illustrates one embodiment of a distributed/decentralized data aggregation system 404. In the illustrated embodiment, the system 404 includes one or more user hardware devices 102 having one or more aggregation modules 104a and one or more backend servers 110 including one or more backend aggregation modules 104b. In some embodiments, the authentication module 202 of the aggregation module 104a can securely provide the encrypted user credentials of the user from the user's hardware device 102 to the backend aggregation module 104b (e.g., the authentication module 202 of the backend aggregation module 104b) on the backend server 110 via the data network 106, etc., so that the direct access module 204 of the backend aggregation module 104b can access one or more third-party service providers 108 (e.g., via the data network 106) through the backend server 110 to download data related to the user.

For example, the backend server 110 may download the user's data in response to the user's hardware device 102a being powered off, dormant, blocked from accessing one or more third-party service providers 108, etc., as determined by the routing module 314, etc. The interface module 206 of the backend aggregation module 104b may provide one or more alerts/messages to the user based on the downloaded data and/or may provide the downloaded data to the user (e.g., directly from the backend server 110 as a web page and/or through a dedicated application, etc., to a different hardware device 102 associated with the first user in response to the user's hardware device 102a becoming available).

5A illustrates one embodiment of a user interface 500. In some embodiments, the interface 500 is provided to a user by the access repair module 310 on an electronic display screen of the hardware device 102 to allow the user to graphically identify one or more input locations for user credentials (e.g., a location for a username, a location for a password, etc.), a method for sending and/or submitting the user's credentials (e.g., an API specification, a location of a submit button, etc.), a location of data associated with the user (e.g., a URL or other link; a location on a linked web page; a tag, markup, or other identifier within the plain text and/or source code of the web page 506; etc.), and/or graphically identify one or more other instructions for accessing data associated with the user from the third-party service provider 108.

In the illustrated embodiment, the access repair module 310 overlays the interface 502 on one or more pages of the third-party service provider's 108 website 506 on the electronic display screen of the user's hardware device 102. As described above, in various embodiments, the access repair module 310 may comprise a browser plug-in and/or extension that provides the interface 502 within an internet browser, may be an embedded browser included within an application of the access repair module 310, or may otherwise be integrated with and/or communicate with an internet browser.

In the illustrated embodiment, the access repair module 310 determines and/or displays one or more suggestions 504 and/or recommendations 504 to the user, which the user can confirm or change/revise. For example, the access repair module 310 can display an interface element 504a with a suggested location for the user to enter a username, an interface element 504b with a suggested location for the user to enter a password, an interface element 504c with a suggested credential submission action, an interface element 504d with a suggested location for data associated with the user, and/or one or more other interface elements that allow the user to graphically identify one or more locations within the website 506 of the third-party service provider 108.

In one embodiment, interface element 504 may include one or more identifiers of an estimated location and/or action that access repair module 310 has determined (e.g., by scanning and/or parsing one or more pages of website 506, based on input from other users who have visited one or more pages of website 506, based on a user's previous interactions with one or more pages of website 506, predictions made using machine learning and/or artificial intelligence analysis of website 506, based on statistical analysis of historical changes to one or more pages of website 506 and/or one or more similar websites, etc.), such as an arrow or other pointing indicator pointing to the location; a link or other identifier of the location; a box or other highlighting around the location; changing the text label of the location to make the text bold, italic, and/or underlined; etc. In some embodiments, a user may click, select, or otherwise identify a location to confirm or change/correct the location suggested by access repair module 310. For example, a user may click or otherwise select an interface element 504 associated with a location and/or action (e.g., to activate the selected interface element 504), and may click or otherwise select the location and/or perform the action, and the access repair module 310 may record the above operations (e.g., automatically filling in text fields identifying the location and/or action, recording a macro that allows the action to be automatically repeated without the user, etc.).

In one embodiment, a user can interact with the website 506 to locate and/or identify one or more locations, perform one or more actions, etc. For example, in some embodiments, the user can navigate to one or more different pages within the website 506, can log into the website 506 using the user's electronic credentials for the website 506, can navigate to different websites 506, can navigate to and/or download user-related data from the website 506, can use the website 506 in a typical manner, etc. As described above with respect to the pattern module 308, in one embodiment, the pattern module 308 can monitor the user's access patterns to the website 506 to allow the direct access module 204 to at least partially emulate the user's access patterns 506 when accessing the website, downloading user-related data from the website 506, etc. In the illustrated embodiment, the access repair module 310 (and/or an associated browser) displays a browser view of the website 506, wherein the text, images, and/or other elements show substantially how an internet browser would display the website 506, with the addition of the interface 502 displayed on the website 506 to the side of the website 506, etc.

FIG5B illustrates one embodiment of a user interface 510. While the user interface 500 described above includes a rendered browser view of one or more pages of the website 506, in one embodiment of the interface 510 of FIG5B , the access repair module 310 (and/or associated browser) displays the source code 516 of the website 506. For example, in one embodiment, the user interface 500 may include a standard access repair interface, and the user interface 510 may include an advanced access repair interface to allow one or more advanced users to identify one or more locations and/or actions within the source code 516 of the website 506 that may not be visible and/or obvious within the website 506 itself. In some embodiments, a user may select and/or switch between the standard user interface 500 or view and the advanced user interface 510 or view.

In the illustrated embodiment, the access and repair module 310 displays a user interface 512 above and/or adjacent to the displayed source code 516, wherein one or more interface elements 514a-d allow a user to identify one or more locations, actions, etc., substantially as described above. In the illustrated embodiment, the access and repair module 310 displays one or more suggestions and/or estimates of locations and/or actions, which the user can confirm and/or change/revise. In various embodiments, the user can identify locations and/or actions in the source code 516 by selecting and/or activating the interface element 514 and selecting a portion of the source code 516, by dragging a portion of the source code 516 and dropping it onto the interface element 514, by cutting and pasting a portion of the source code 516 into the interface element 514, and/or otherwise identifying locations and/or actions based on the source code 516.

In some embodiments, in response to a user identifying one or more locations and/or actions (e.g., for entering, submitting, and/or sending electronic credentials; for locating and/or downloading data, etc.), the access repair module 310 can collaborate with the testing module 318 to perform on-site and/or real-time testing of the identified one or more locations and/or actions to determine the validity and/or feasibility of the identified one or more locations, while the interfaces 500, 510 are visible to and/or used by the user to allow the user to change and/or correct the provided information during the same session. For example, the access repair module 310 can display a test button or other user interface element to the user, which the user can select and/or activate to initiate the test. In another embodiment, the access repair module 310 can automatically perform the test in response to the user providing the location and/or action, without the user needing to select and/or activate the test button or other user interface element. In yet other embodiments, the testing module 318 can perform one or more tests independently of the access repair module 310, with or without the functionality of the access repair module 310.

6 illustrates one embodiment of a method 600 for distributed data aggregation. The method 600 begins with the authentication module 202 receiving 602 the user's electronic credentials for a third-party service provider 108 from a user on the user's hardware device 102. The direct access module 204 uses the user's electronic credentials to access 604 the server 108 of the third-party service provider 108 through the user's hardware device 102. The direct access module 204 downloads 606 data associated with the user from the server 108 of the third-party service provider 108 to the user's hardware device 102.

FIG7 illustrates one embodiment of a method 700 for distributed and/or decentralized data aggregation. The method 700 begins with the authentication module 202 determining 702 electronic credentials of a user for a plurality of third-party service providers 108. The direct access module 204 uses the determined 702 electronic credentials to access 704 servers of the plurality of third-party service providers 108. The direct access module 204 downloads 706 data associated with the user from the accessed 704 servers of the plurality of third-party service providers 108.

The direct access module 204 aggregates 708 the data downloaded 706 from the plurality of different third-party service providers 108. The interface module 206 provides 710 the aggregated 708 data to the user (e.g., by displaying the data on the user's hardware device 102, sending an alert or other message to the user's hardware device 102, sending the data to a remote backend server 110 independent of the third-party service provider 108 that the user can access using a web interface and/or API, etc.), and the method 700 ends.

8 illustrates another embodiment of a method 800 for distributed and/or decentralized data aggregation. The method 800 begins with the network authentication module 304 receiving 802 a user's electronic credentials for one or more third-party service providers 108. The password manager module 306 generates 804 new and/or different electronic credentials for the one or more third-party service providers 108 and updates the user's account with the one or more third-party service providers 108 using the generated 804 electronic credentials.

The access repair module 310 determines 806 whether there has been a change in access to one or more third-party service providers 108 (e.g., whether access is interrupted or unavailable, whether access is partial or incomplete, whether the access bandwidth is slower than previously determined, and/or whether another change in access has occurred). If the access repair module 310 determines 806 that access to the third-party service provider 108 has changed, the access repair module 310 provides 808 a graphical user interface 500, 510 to the user. The access repair module 310 receives 810 identification of one or more locations and/or actions for authenticating the user and/or downloading data from the third-party service provider 108 by providing 808 the graphical user interface 500, 510. The testing module 318 uses the identification of the one or more locations and/or actions received 810 to test 812 access to the third-party service provider 108. In response to a successful test 812 by the test module 318, the test module 318 and/or the mode module 308 provides 814 instructions to one or more direct access modules 204 associated with one or more different users for accessing the third-party service provider 108 and/or downloading data from the third-party service provider 108 based on the identification of one or more locations and/or actions received 810.

The routing module 314 determines 816 whether the hardware device 102 associated with the user is available. In response to the routing module 314 determining 816 that the hardware device 102 associated with the user is available, the direct access module 204 downloads 818 data related to the user from one or more third-party service providers 108 via the available hardware device 102 associated with the user.

In response to the routing module 314 determining 816 that the hardware device 102 associated with the user is unavailable, the direct access module 204 of the different device (e.g., the hardware device 102 of the different user, the backend server 110, etc.) downloads 820 data related to the user from one or more third-party service providers 108 via the different device. The routing module 314 (e.g., the routing module on the different device 102, 110) determines 822 whether an alert or other message is available for the user based on the downloaded data 820, and pushes 824 and/or otherwise sends the alert or other message to the device associated with the user (e.g., the unavailable device 102) in response to determining 822 that the alert or other message is available. For example, in one embodiment, the user's hardware device 102 may be unavailable for downloading data (e.g., powered off, offline, dormant, using mobile data instead of Wi-Fi, etc.), but may receive the alert or other message pushed 824 (e.g., via different means, such as text message, voicemail, email, push notification, etc.) and/or may receive the alert or other message pushed 824 in response to becoming available at a later time.

The interface module 206 provides 826 the user with the data downloaded 818, 820 and/or an alert pushed 824 (e.g., displays the data on the user's hardware device 102, displays an alert or other message pushed/sent 824 on the user's hardware device 102, sends the data to a remote backend server 110 independent of the third-party service provider 108 that the user can access using a web interface and/or API, etc.). In some embodiments, the method 800 continues to periodically determine 806 whether there is a change in access to the third-party service provider 108, determine 816 whether the user's hardware device 102 is available, download 818, 820 data related to the user, and/or provide 826 the user with the downloaded data and/or an alert or other message pushed 824, etc.

In various embodiments, an apparatus for determining a user's electronic credentials for a third-party service provider 108 on a user's hardware device 102 may include one or more of the following: the hardware device 102, the backend server 110, the authentication module 202, the local authentication module 302, the network authentication module 304, the password manager module 306, the aggregation module 104, a processor (e.g., a central processing unit (CPU), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent apparatus for determining a user's electronic credentials for a third-party service provider 108 on a user's hardware device 102.

In various embodiments, the apparatus for accessing the server 108 of the third-party service provider 108 through the user's hardware device 102 using the user's electronic credentials may include one or more of the following: the hardware device 102, the backend server 110, the direct access module 204, the mode module 308, the access repair module 310, the hierarchy module 312, the aggregation module 104, a network interface, a processor (e.g., a central processing unit (CPU), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent apparatus for accessing the server 108 of the third-party service provider 108 through the user's hardware device 102 using the user's electronic credentials.

In various embodiments, the means for downloading data associated with a user from a server 108 of a third-party service provider 108 to a hardware device 102 of a user may include one or more of the following: the hardware device 102, the backend server 110, the direct access module 204, the mode module 308, the access repair module 310, the hierarchy module 312, the aggregation module 104, a network interface, a processor (e.g., a central processing unit (CPU), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for downloading data associated with a user from a server 108 of a third-party service provider 108 to a hardware device 102 of a user.

In various embodiments, an apparatus for packaging data downloaded from a user's hardware device 102 of a remote device 110, 102 that is independent of a third-party service provider 108 from which the data is downloaded may include one or more of the following: the hardware device 102, the backend server 110, the interface module 206, the aggregation module 104, a processor (e.g., a central processing unit (CPU), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent apparatus for packaging data downloaded from a user's hardware device 102 of a remote device 110, 102 that is independent of a third-party service provider 108 from which the data is downloaded.

In various embodiments, an apparatus for providing downloaded data from a user's hardware device 102 to a remote device 110, 102 independent of a third-party service provider 108 from which the data was downloaded may include one or more of the following: the hardware device 102, the backend server 110, the interface module 206, the aggregation module 104, a processor (e.g., a central processing unit (CPU), a processor core, a field programmable gate array (FPGA) or other programmable logic, an application specific integrated circuit (ASIC), a controller, a microcontroller, and/or another semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent apparatus for providing downloaded data from a user's hardware device 102 to a remote device 110, 102 independent of a third-party service provider 108 from which the data was downloaded.

In various embodiments, an apparatus for performing other method steps described herein may include one or more of the following: hardware device 102, backend server 110, authentication module 202, local authentication module 302, network authentication module 304, password manager module 306, direct access module 204, mode module 308, access repair module 310, hierarchy module 312, interface module 206, routing module 314, frequency module 316, testing module 318, aggregation module 104, network interface, processor (e.g., central processing unit (CPU), processor core, field programmable gate array (FPGA) or other programmable logic, application specific integrated circuit (ASIC), controller, microcontroller and/or another semiconductor integrated circuit device), HDMI or other electronic display dongle, hardware application or other hardware device, other logic hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent apparatus for performing other method steps described herein.

The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics of the present invention. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the present invention is therefore indicated by the appended claims rather than by the foregoing description. All variations that come within the meaning and range of equivalents of the claims are intended to be embraced within their scope.

Claims (28)

1. A method comprising: Identify electronic credentials for users who use multiple third-party service providers; Using the user's designated electronic credentials, access each of the third-party service providers via the hardware device associated with the user to download data associated with the user from the third-party service provider; Accessing one or more other locations on one or more of the third-party service providers, wherein one or more artificially introduced delays exist between accessing the one or more other locations and downloading the data, thereby simulating a user's usage patterns on one or more of the third-party service providers; and Data downloaded from the third-party service provider is aggregated, and one or more communication messages are provided to the user on the hardware device based on the aggregated downloaded data. 2. The method of claim 1 further includes providing the downloaded data from the hardware device to a different device separate from the third-party service provider. 3. The method of claim 2, wherein the simulated usage pattern is determined based on one or more of the following: an average pattern identified in the behavior of multiple other users accessing one or more of the third-party service providers using a web browser, and a pattern identified in the behavior of users accessing one or more of the third-party service providers using a web browser. 4. The method according to claim 1, further comprising: It was detected that access to data associated with the user from one or more of the third-party service providers was unavailable; and Provide the user with an interface that allows the user to graphically identify one or more of the locations of the user's electronic credentials and the locations of the data associated with the user on one or more websites that are not available on the third-party service provider's website. 5. The method according to claim 4, further comprising: Processing one or more pages of the website; and The interface displays to the user an estimate of one or more of the input locations for the user's electronic credentials and the locations of data associated with the user, so that the user can use the interface to confirm whether the estimates are correct. 6. The method according to claim 5, further comprising: Based on the identifier from the user, attempt to access one or more unavailable third-party service providers for the plurality of different users using electronic credentials from the respective users; and In response to determining that an identifier from the user is sufficient to access data associated with a different user, the identifier is provided from the user to an additional user to access data associated with the additional user. 7. The method according to claim 1, further comprising: Generate and manage one or more distinct secure electronic credentials for each of the users in the third-party service providers; and One or more different secure electronic credentials for the user are securely stored on the hardware device associated with the user. 8. A system comprising: Multiple aggregation modules located on hardware devices of different users receive electronic credentials from the different users for multiple different third-party service providers, use the received electronic credentials to access the multiple third-party service providers in order to download data associated with the different users from the third-party service providers, and access one or more other locations on one or more of the third-party service providers, wherein there are one or more artificially introduced delays between accessing the one or more other locations and downloading the data, thereby simulating the usage patterns of the different users on one or more of the third-party service providers; and A backend server receives downloaded data associated with the different users from the different third-party service providers, separately aggregates the data from each of the different users from the multiple different third-party service providers, and provides one or more communication messages based on the separately aggregated data to the different users individually via one or more communication channels. 9. The system of claim 8, further comprising hardware device for the different users, the hardware device including a processor executing computer-executable program code of the aggregation module, the hardware device including a non-transitory computer-readable storage medium storing the computer-executable program code, and the hardware device including a network interface for communicating with the third-party service provider to download data associated with the different users. 10. A non-transitory computer-readable storage medium storing computer-usable program instructions executable by a processor to perform operations, said operations including: The electronic credentials of the user are determined on the user's hardware device for use by the third-party service provider; Using the user's electronic credentials, access the third-party service provider's server from the user's hardware device; Detect changes in access to one or more of the third-party service provider's servers and data associated with the user; and Provide the user with an interface that allows the user to graphically identify one or more of the input locations of the user's electronic credentials and the locations of the data associated with the user; Downloading data associated with the user from the third-party service provider's server to the user's hardware device; and One or more of the following: aggregating downloaded data from the user's hardware device to a remote device independent of the third-party service provider, and providing the downloaded data to the remote device. 11. The non-transitory computer-readable storage medium of claim 10, further comprising: Determine an ordered list on the server of multiple locations used to access the server; and Determine one or more delays for waiting between accessing the location. 12. The non-transitory computer-readable storage medium of claim 11, wherein the plurality of locations and the one or more delays are selected based on an average pattern identified in the behavior of a plurality of other users accessing the third-party service provider using a web browser. 13. The non-transitory computer-readable storage medium of claim 11, wherein the plurality of locations and the one or more delays are selected based on patterns identified in the user's behavior of accessing the third-party service provider using a web browser. 14. The non-transitory computer-readable storage medium of claim 10, further comprising: Processing one or more pages of the server; and The interface displays to the user an estimate of one or more of the locations of the user's electronic credentials and the locations of data associated with the user, so that the user can use the interface to confirm whether the estimate is correct. 15. The non-transitory computer-readable storage medium of claim 10, further comprising: Based on user identifiers, attempts are made to access the servers of the third-party service providers for the multiple different users using electronic credentials from those users; and Determine whether data associated with the different users can be accessed using the identifier from the user. 16. The non-transitory computer-readable storage medium of claim 15, further comprising: in response to a threshold being met by a number of different users who can access the data using an identifier from the user, providing the identifier from the user to other instances of the computer program product to access the third party's server. 17. The non-transitory computer-readable storage medium of claim 10, further comprising: providing an ordered list of receiving a plurality of different sets of instructions for accessing the server of the third-party service provider using the user's electronic credentials and for downloading data associated with the user. 18. The non-transitory computer-readable storage medium of claim 17, wherein one or more of the different instruction groups include a location for inputting the user's electronic credentials, an instruction for submitting the user's electronic credentials, and one or more locations of data associated with the user. 19. The non-transitory computer-readable storage medium of claim 10, wherein the operation is configured to access the server using the application programming interface and authentication program of the third-party service provider. 20. The non-transitory computer-readable storage medium of claim 10, further comprising: Determine whether one or more of the user's hardware device and another device of the user are available to download data associated with the user from the server of the third-party service provider; and In response to determining that the user's hardware device is unavailable, the user's electronic credentials are used to access the third-party service provider's server through different devices to download data associated with the user from the third-party service provider's server to the different devices. 21. The non-transitory computer-readable storage medium of claim 20, further comprising: providing one or more communication messages to the user on the user's hardware device based on data downloaded to the different devices and associated with the user. 22. The non-transitory computer-readable storage medium of claim 20, wherein the different device includes another user's personal hardware device, and the operation further includes: Send an encrypted copy of the user's electronic credentials to the different devices; and The downloaded data is encrypted on the different devices so that the other user cannot access the downloaded data. 23. The non-transitory computer-readable storage medium of claim 10, wherein the operation further includes setting the frequency at which the operation accesses the server of the third-party service provider. 24. The non-transitory computer-readable storage medium of claim 23, further comprising: determining the frequency based on input from the remote device independent of the third-party service provider, such that the remote device determines the frequency at which multiple different users and different hardware devices access the server of the third-party service provider. 25. The non-transitory computer-readable storage medium of claim 23, wherein the frequency is determined based on input from the user received on the user's hardware device. 26. The non-transitory computer-readable storage medium of claim 10, further comprising: Managing electronic credentials for users of multiple third-party service providers, including the aforementioned third-party service provider; and Access and download data associated with the user from each of the plurality of third-party service providers. 27. The non-transitory computer-readable storage medium of claim 26, further comprising: Generate different secure credentials for each of the plurality of third-party service providers; and The generated user credentials are securely stored on the user's hardware device. 28. A non-transitory computer-readable storage medium storing computer-usable program instructions executable by a processor to perform operations, said operations including: Identify the user's electronic credentials on the user's hardware device for use with third-party service providers; The frequency of accessing the third-party service provider's server is set based on input from a remote device independent of the third-party service provider, so that the remote device determines the frequency of access to the third-party service provider's server by multiple different users and different hardware devices. The user's electronic credentials are used to access the third-party service provider's server from the user's hardware device at a set frequency; Downloading data associated with the user from the third-party service provider's server to the user's hardware device; and One or more of the following: aggregating downloaded data from the user's hardware device to a remote device independent of the third-party service provider, and providing the downloaded data to the remote device.