BR102020022477A2 - APPARATUS, AND METHOD - Google Patents

Abstract

Apparatus, methods, program products and systems for account verification are disclosed. An apparatus includes a processor and a memory that stores executable code by the processor to receive a user's electronic credentials, uses the received electronic credentials to verify an account for the user, and in response to account verification failure using electronic credentials received, verifies the user's account using one or more micro-deposits.

Description

ACCOUNT VERIFICATION CROSS REFERENCES WITH RELATED ORDERS

This application claims the benefit of US Provisional Patent Application No. 62/992,370 entitled “ACCOUNT VERIFICATION” and filed March 20, 2020, by Michael Lott et al., which is hereby incorporated by reference.

FIELD OF THE INVENTION

This invention refers to account verification and, more particularly, refers to the dynamic verification of a user's account existence and status to third parties.

BACKGROUND OF THE INVENTION

Checking the existence and/or status of a user account can be time-consuming and may require extended user participation for completion.

BRIEF SUMMARY OF THE INVENTION

Apparatus, methods, program products and systems for account verification are disclosed. In one embodiment, an apparatus includes a processor and a memory that stores executable code by the processor to receive electronic credentials from a user, use the received electronic credentials to verify an account for the user, and in response to account verification failure. using the electronic credentials received, verify the user's account using one or more micro-deposits.

In some embodiments, a method for account verification includes receiving electronic credentials from a user, using the received electronic credentials to verify an account for the user and, in response to account verification failure using the received electronic credentials, verification the user's account using one or more microdeposits.

In one embodiment, an apparatus for account verification includes means for receiving electronic credentials from a user, means for using the received electronic credentials to verify an account for the user, and in response to account verification failure using electronic credentials received, means of verifying the user's account using one or more micro-deposits.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention are easily understood, a more particular description of the invention described briefly above will be made with reference to the specific embodiments, which are illustrated in the accompanying drawings. Understanding that these drawings represent only typical embodiments of the invention and, therefore, should not be considered as limiting its scope, the invention will be described and explained with specificity and additional details through the use of the attached drawings, in which:
Figure 1 is a schematic block diagram illustrating an embodiment of a system for account verification;
Figure 2 is a schematic block diagram of one embodiment of a verification module;
Figure 3 is a schematic block diagram of another embodiment of a verification module;
Figure 4A is a schematic block diagram illustrating a further embodiment of a system for account verification;
Figure 4B is a schematic block diagram illustrating another embodiment of a system for checking account;
Figure 4C is a schematic block diagram illustrating a particular embodiment of an account verification system;
Figure 5 is a schematic flowchart illustrating one embodiment of a method for account verification;
Figure 6 is a schematic flowchart illustrating a further embodiment of a method for account verification;
Figure 7 is a schematic flowchart illustrating another embodiment of a method for checking account; and
Figure 8 is a schematic flowchart illustrating another embodiment of a method for account verification.

DETAILED DESCRIPTION OF THE INVENTION

Reference throughout this specification to "an achievement", "the achievement" or similar language means that a particular feature, structure or characteristic described in connection with the achievement is included in at least one achievement. Therefore, the appearance of sentences "in an achievement", "in the achievement" and similar language throughout this descriptive report may, but not necessarily, refer to the same achievement, but means "one or more, but not all achievements" , unless otherwise expressly specified. The terms "including", "comprising", "having" and variations thereof mean "including, without limitation", unless expressly specified otherwise. An enumerated listing of items does not imply that any and all items are mutually exclusive and/or mutually inclusive, unless expressly stated otherwise. The terms “a/a”, “a/an” and “a/a” also refer to “one or more”, unless expressly specified otherwise.

Furthermore, the features, advantages and characteristics of the described embodiments can be combined in any suitable way. The skilled person will recognize that achievements can be practiced without one or more of the specific features or advantages of a particular achievement. In other cases, additional features and perks may be recognized in certain achievements that may not be present in all achievements.

These features and advantages of the achievements will be more fully evident from the following description and the appended claims, or may be learned by practicing the achievements, as hereinafter set forth. As will be recognized by those skilled in the art, aspects of the present invention may be incorporated as a system, method and/or computer program product. Thus, aspects of the present invention may take the form of an all-hardware embodiment, an all-software realization (including firmware, resident software, microcode, etc.) or an embodiment that combines software and hardware aspects that may generally be termed here as “circuit”, “module”, or “system”. In addition, aspects of the present invention may take the form of a computer program product incorporated in one or more computer readable media(s) having the program code incorporated therein.

Many of the functional units described in this descriptive report have been labeled as modules to emphasize their implementation independence more particularly. For example, a module can be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, ready-to-use semiconductors such as 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, or the like.

Modules can also be implemented in software for execution by different types of processors. An identified module of program code can, for example, comprise one or more physical or logical blocks of computer instructions that can, for example, be organized as an object, procedure or function. However, the executables of an identified module do not need to be physically located together, but can comprise disparate instructions stored in different locations that, when logically joined together, comprise the module and achieve the stated purpose for the module.

In fact, a module of program code can be a single instruction, or many instructions, and it can even be spread over several different code segments, among different programs, and among several memory devices. Likewise, operational data can be identified and illustrated here in modules and can be incorporated in any suitable form and organized in any type of data structure. Operational data can be collected as a single dataset or can be distributed in different locations, including different storage devices, and can exist, at least partially, merely as electronic signals in a system or network. Where a module or portions of a module are implemented in the software, the program code may be stored and/or propagated on one or more computer readable media(s).

The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon to cause a processor to carry out aspects of the present invention.

The computer readable storage medium may be a tangible device that can retain and store instructions for use by an instruction executing device. The 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 combination adequate of the above. A non-exhaustive list of more specific examples of computer readable storage media include the following: a portable computer floppy 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 disk read-only memory ("CD-ROM"), a versatile disk digital (“DVD”), a memory stick, a floppy disk, a mechanically encoded device such as punched cards or embossed structures in a slot with instructions engraved on it, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, should not be interpreted as being transient signals per se, such as radio waves or other freely propagated electromagnetic waves, electromagnetic waves that propagate through a waveguide or other media. transmission (for example, light pulses passing through a fiber optic cable), or electrical signals transmitted through a wire.

The computer readable program instructions described herein may be downloaded to the respective computer devices/processors from a computer readable storage medium or to an external computer or external storage device via a network, e.g. Internet, a local area network, a wide area network and/or a wireless network. The network can comprise copper transmission cables, transmission optical fibers, wireless transmission, routers, firewalls, switches, port computers and/or edge servers. A network adapter card or network interface in each computing device/processor receives the computer readable program instructions from the network and forwards the computer readable program instructions to store on a computer readable storage medium in the respective computer device/processor.

Computer readable program instructions for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, configuration data code or source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++ or similar, and conventional procedural programming languages such as the programming language in " C" or similar programming languages. Computer-readable program instructions can run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (eg over the internet using an internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuit, field programmable gate arrays (FPGA) or programmable logic arrays (PLA), can execute the computer readable program instructions using the state information of the computer readable program instructions for customizing the electronic circuit to carry out aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products in accordance with embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks of the flowchart illustrations and/or block diagrams, can be implemented by the computer readable program instructions.

These computer-readable program instructions may be provided to a general purpose computer processor, special purpose computer or other programmable data processing apparatus to produce a machine so that the instructions, executed by means of the computer processor. computer or other programmable data processing apparatus, create means for implementing the functions/actions specified in the flowchart and/or block(s) of the block diagram. These computer readable program instructions may also be stored on a computer readable storage medium which can direct a computer, programmable data processing apparatus and/or other devices to function in a particular way so that the The computer readable storage medium with the instructions stored therein comprises an article of manufacture which includes instructions which implement the aspects of the function/action specified in the flowchart and/or block(s) of the block diagram.

Computer readable program instructions can also be loaded into 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 process. implemented by computer, such that instructions executed on the computer, other programmable apparatus or other device implement the functions/actions specified in the flowchart and/or block(s) of the block diagram.

The schematic flowcharts and/or schematic block diagrams in the Figures illustrate the architecture, functionality and operation of possible implementations of apparatus, systems, methods and computer program products in accordance with various embodiments of the present invention. In this regard, each block in the schematic flowcharts and/or schematic block diagrams can represent a module, segment or portion of code, which comprises one or more executable instructions of the program code for implementing the logic function(s)( s) specified(s).

It should also be noted that, in some alternative implementations, the functions observed in the block may occur outside the order observed in the Figures. For example, two blocks shown in succession may actually be played substantially concurrently, or the blocks may sometimes be played in reverse order, depending on the functionality involved. Other steps and methods can be devised so that they are equivalent in function, logic or effect to one or more blocks, or portions thereof, of the illustrated Figures.

Although several types of arrow and line can be employed in the flowchart and/or block diagram, they are understood to not limit the scope of the corresponding realizations. In fact, some arrows or other connectors can be used to indicate just the logical flow of the depicted realization. For example, an arrow may indicate a waiting or monitoring period of unspecified duration between the enumerated steps of the represented achievement. It will also be noted that each block in the block diagram and/or flowchart, and the combinations of blocks in the block diagram and/or flowchart, can be implemented by special purpose hardware-based systems that perform the specified functions or actions, or combinations of special purpose hardware and program code.

Figure 1 depicts an embodiment of a system 100 for account verification. In one embodiment, system 100 includes one or more hardware devices 102, one or more verification modules 104 (e.g., a back-end verification module 104b, a plurality of verification modules 104a disposed in the one or more devices. of hardware 102, one or more merchant verification modules 104c to one or more third parties 108), one or more data networks 106 or other communication channels, one or more third parties 108 (e.g., one or more servers 108 of a or more service providers 108; one or more cloud or network service providers, or the like) and/or one or more back-end servers 110. In certain embodiments, although several specific hardware devices 102, modules of verification 104, data networks 106, third party 108 and/or backend servers 110 in Figure 1, the skilled person will recognize, in view of this disclosure, that various hardware devices 102, verification modules 104, data networks Data 106, third party 108 and/or backend servers 110 may be included in system 100 for account verification.

In one embodiment, system 100 includes one or more hardware devices 102. Hardware devices 102 (e.g., computing devices, information handling devices, or the like) may include one or more of a desktop computer, a laptop computer, a mobile device, tablet computer, smartphone, decoder, game console, smart TV, smartwatch, fitness band, head-mounted optical monitor (eg virtual reality headset, smart glasses, or the like), an HDMI or electronic monitor dongle, a personal digital assistant and/or other computing device comprising a processor (e.g., a central processing unit (CPU), a processor core, a field-programmable port array ( FPGA) or other programmable logic, an application-specific integrated circuit (ASIC), a controller, a microcontroller, and/or other semicond integrated circuit device user), a volatile memory and/or a non-volatile storage medium. In certain embodiments, the hardware devices 102 are in communication with one or more servers 108 of one or more third party 108 and/or one or more back-end servers 110 via a data network 106, described below. Hardware devices 102, in a further embodiment, are capable of executing various programs, program code, applications, instructions, functions, or the like.

In one embodiment, a verification module 104 is configured to verify the existence and/or status of one or more accounts of a user (e.g., bank accounts, online service provider accounts, social media accounts, and/or similar) with interaction, insertion, minimal or absent user feed, or similar, as described in more detail below with reference to Figures 2 and 3. As used herein, account verification (or instant account verification) enables entities as merchants , bank or similar check if a customer's function source is valid in real time, in the period of seconds and/or similar.

For example, a customer at a financial services company, eg a banking, lender, mortgage and/or similar company, provides their electronic credentials, eg a username and password, for the account they need to verify. A financial data aggregator can connect on behalf of that customer and securely return the account information, for example, the account and branch identification number, to the institution as verified.

In conventional account verification systems based solely on micro-deposits, two small deposits are made to the chosen financial account. The customer then needs to wait one to three business days for the deposits to clear into their account, at which time they need to connect to their financial account, as well as the company requesting the verification, to validate their account. Customers who need to mutually verify their account via micro-deposits often forget to return, and when they do, their enthusiasm for starting the session often wanes or disappears and they may not complete the registration for an account.

In certain embodiments, a verification module 104a in a user hardware device 102 can communicate with a third party verification module 104c 108 (e.g., either directly and/or through one or more verification modules 104b back-end in one or more back-end servers 110) in a data network 106 using proximity field communications (NFC), a matrix or other barcode, Bluetooth®, Wi-Fi, a radio frequency identifier (RFID), an infrared (IR) signal protocol, a radio frequency (RF) signal protocol, based on a determined geographic location to the user's hardware device 102 and/or to a third party 108, or the like. Thus, in some embodiments a verification module 104 can complete a transaction between a user and a third party 108 using a user's hardware device 102 instead of a payment card and/or payment card network, authenticating a user in instead of a card.

In certain embodiments, a verification module 104a of a user hardware device 102 may not communicate directly with a third party verification module 104c 108 for the transaction, but both communicate with a back-end verification module 104b (per example, using a data network 106, or the like). A backend verification module 104b can compare the geographic locations determined for a user's hardware device 102 and for a third party 108 (e.g., for fraud detection, triggering a transaction, presenting an offer to a user on the user's hardware device. user 102, complete a transaction or the like).

In one embodiment, as described in more detail below, a verification module 104a may be part of, integrated into and/or in communication with a mobile personal finance management (PFM) application running on a mobile hardware device 102 for the user, and may already have access to and authorization from the user to access one or more of the user's bank accounts (for example, accounts with a plurality of third party financial institutions 108, 114 or similar) using the user's electronic credentials. A verification module 104 may use the user's electronic credentials to aggregate transaction data for the user, to verify fund and/or credit availability, to send payment for a transaction, or the like. A verification module 104, in some embodiments, can clear, categorize, classify and/or otherwise process the user's aggregated financial transaction data from one or more third-party bank accounts (for example, to facilitate accurate fraud detection for subsequent financial transactions, or similar).

In one embodiment, a third party verification module 104c, in response to a completed transaction or the like, may provide item level data for the transaction with a user verification module 104a, to a backend verification module 104b , or similar. In other embodiments, a verification module 104c can provide item level data prior to completion of a transaction, while a verification module 104 can use the item level data to detect fraud for the transaction. Item-level data is described in more detail below. For example, in some embodiments, a verification module 104c may provide the item level data as an electronic receipt to the user on a hardware device 102 to the user, or the like.

In one embodiment, a verification module 104 is configured to determine and/or receive electronic credentials from a user (e.g., username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN ), challenge response, security code, hardware code, software code, DNA sequence, signature, facial recognition, voice pattern recognition, bioelectrical signals, two-factor authentication credentials or similar) to one or more third parties 108. Verification module 104, in certain embodiments, accesses a third party server 108 using a user's electronic credentials to download user-associated data from server 108, such as user photos, user social media posts, history user's physician, user's financial transaction records or other financial data, and/or other data associated with and/or owned by the user , but stored by a third party server 108 (e.g., stored by non-proprietary hardware, maintained and/or controlled by the user).

The verification module 104, in various embodiments, can locally provide the downloaded data to the user (e.g., displaying the data on an electronic monitor of a hardware device 102); can provide the downloaded data from the user's hardware device 102 to and/or packet data to a remote server 110 (e.g. a backend verification module 104b) or other remote device (e.g., another hardware device 102 of the user, a hardware device 102 of a different user or the like), which may not be affiliated with affiliated third parties 108; may provide one or more alerts, messages, announcements or other communications to the user (eg, on a 102 hardware device) based on the downloaded data; or similar.

In certain embodiments, system 100 includes a plurality of verification modules 104 disposed/located on hardware devices 102 of a plurality of different users (e.g., comprising hardware and/or executable code running on one or more hardware devices 102). The plurality of verification modules 104 can act as a distributed and/or decentralized system 100, running on various hardware devices 102, which are geographically dispersed and using different IP addresses, each downloading and/or aggregating data (e.g., photos , social media posts, medical history, financial transaction records, other financial data, and/or other user data) separately in a distributed and/or decentralized manner. Although third parties 108 (for example, a financial institution, bank, credit union and/or other online banking provider; a social media site; a medical provider; a photo hosting site or the like) may block an aggregation service data or other entity to access data for a plurality of users from a single location (for example, a single IP address, a single block of IP addresses or the like), several distributed and/or decentralized verification modules 104, in certain achievements, it can be very difficult for a third party 108 to block.

In one embodiment, a hardware device 102 may include and/or run a web browser, which a user can use to access a third party server 108 (e.g., loading a third party web page 108 in the web browser) . At least a portion of a verification module 104, in certain embodiments, may comprise a plugin for and/or an extension of a web browser of a user's personal hardware device 102 so that third parties 108 cannot block the module checking 104 of accessing the third party server 108 without also blocking the user's own access to the server 108 using the web browser. For example, the verification module 104 may use the same cookies, IP address, saved credentials or the like as a user would then to access a third party server 108 through the internet browser. In certain embodiments, verification module 104 can support integration with several different types of web browsers (e.g., on different hardware devices 102).

A verification module 104, in certain embodiments, may mimic or copy the user's behavioral pattern when accessing a third party server 108 108 to reduce the likelihood that third party 108 can distinguish access to server 108 by an access verification module 104 to server 108 by a user. For example, a verification module 104 may visit one or more locations (e.g., web pages) of a third party server 108 108 even if the verification module 104 does not want to download data from each of the locations, it may wait for a certain delay time between accessing different locations, can use a certain scroll pattern, or the like, to mask the transfer and/or aggregation of data from a user of the verification module 104 to reduce the chances of being detected and/or blocked by third parties 108.

In one embodiment, at least a portion of a verification module 104 may be embedded or another part of another application running on a hardware device 102, such as a personal financial administration application (e.g., computer executable code for displaying transactions user's financial statements from various financial institutions, determining and/or displaying the user's budgets and/or financial objectives, determined and/or displaying the user's account statements, determined and/or displaying the user's net worth or similar) , a photo viewer, a medical application, an insurance application, an accounting application, a social media application, or the like, which can use data from the verification module 104 to download from a third party server 108 108.

In one embodiment, the verification modules 104a comprise a distributed system 100, with the verification modules 104a and/or associated hardware devices 102 downloading and/or aggregating data substantially independently (e.g., downloading data concurrently or non-concurrently , if a global clock, successful and/or failure independent of components). Distributed verification modules 104a can pass messages to each other and/or to a back-end verification module 104b to coordinate their distributed aggregation of data to users. In one embodiment, the verification modules 104a are decentralized (e.g., hardware devices 102 associated with users perform one or more aggregation functions, such as downloading data), rather than relying solely on a centralized server or other device to perform a or more aggregation functions.

In a distributed and/or decentralized system 100, a central entity, such as a backend verification module 104b and/or a backend server 110, in certain embodiments, may still provide one or more verification modules 104a with one or further messages comprising instructions to access a third party server 108 108 using the user's credentials or the like. For example, a backend verification module 104b may provide one or more verification modules 104a of one or more hardware devices 102 with one or more instruction sets for accessing a third party service server 108, as a location for access a user's electronic credentials (eg a text box, a field, a label, a coordinate or the like), an instruction to send a user's electronic credentials (eg press the button, click the link, or similar), one or more locations of data associated with a user (for example, a row in a table or graph, a column in a table or graph, a uniform resource locator (URL) or other address, a coordinate, a label or similar), and/or other instructions or information using which verification modules 104a can access and download user data.

In a further embodiment, one or more verification modules 104a can pass messages to each other, such as instructions to access a third party server 108 using a user's credentials, or the like, in a peer-to-peer manner. In another embodiment, a central entity, such as a back-end verification module 104b, may initially propagate one or more instruction sets to a third-party server 108 using a user's credentials to one or more verification modules 104a, and the one or more verification modules 104a may send the one or more instruction sets to other verification modules 104a.

However, in certain embodiments, instructions for accessing a user's data may change over time, may vary for different third-party users 108, or similar (for example, due to updates, different service levels or servers 108 for different users, acquisitions and/or consolidation of different third parties 108, or the like) cause certain instructions to fail over time and/or for certain users, preventing a verification module 104 from accessing and downloading a user's data. A back-end verification module 104b, in one embodiment, may provide one or more verification modules 104a with a hierarchical list of diverse instruction sets known to enable access to a user's data from a third-party server 108 108. A verification module 104a in a hardware device 102 can try different sets of instructions in hierarchical order until the verification module 104a can access a user's data.

A verification module 104, in certain embodiments, can provide an interface to a user, allowing the user to repair or adjust unsuccessful instructions for accessing user data, by graphically identifying an entry location for the user's electronic credentials, a instruction for sending a user's electronic credentials, a location of data associated with the user, or the like. A verification module 104, in one embodiment, may highlight or otherwise suggest (e.g., in bold, color, represent a visual comment or mark, or the like) an estimate of which verification module 104 determined the location of an entry. for a user's electronic credentials, an instruction to send a user's electronic credentials, a location of data associated with the user, or the like. For example, a verification module 104 can process a web page of a third party 108 server 108 (e.g. parsing and/or searching a hypertext markup language (HTML) file) to estimate an input location for the user's electronic credentials, an instruction to send a user's electronic credentials, a location of data associated with the user, or the like.

A verification module 104, in certain embodiments, can provide an advanced interface for a user to graphically repair interrupted and/or unsuccessful instructions for accessing a user's data from a third party server 108, which allows the user to view the code of a web page (eg, HTML or similar) and identifying an input location for the user's electronic credentials, an instruction to send a user's electronic credentials, a location of data associated with the user, or similar in code of the web page. In one embodiment, a verification module 104 can provide a basic interface for a user to graphically repair interrupted and/or unsuccessful instructions for accessing a user's data from a third party server 108 by overlaying the basic interface to a page of the web or other location of the server 108 where the user can graphically identify an input location for the user's electronic credentials, an instruction to send a user's electronic credentials, a location of data associated with the user, or the like (e.g. , without requiring the user to view the HTML or other code of the web page). A verification module 104, in certain embodiments, may provide an interface that includes a selectable list of interrupted and/or missing instructions, locations, or the like, and may graphically highlight and/or demand suggestions in response to selecting one of an item from the list.

A verification module 104, in one embodiment, may test instructions provided by users (for example, using a test set) before allowing each of the verification modules 104a to use the instructions provided (for example, to prevent a user from abusive provides false or incorrect instructions). A verification module 104 can score or rank users based on a success rate of the instructions provided by the users, and can speed up (for example, provide a greater number of verification modules 104a and/or users) the use of instructions for users with a higher score or rating. The distributed network of verification modules 104, in certain embodiments, can therefore be self-corrective and/or self-testing, allowing for continuous access to and/or aggregation of user data from one or more third parties 108, even if the instructions access options change or stop.

The one or more verification modules 104, in certain embodiments, may provide an interface (e.g., an application programming interface (API)) to provide downloaded and/or aggregated user data from the servers 108 of one or more third party 108 to one or more other entities (e.g., a remote server 110 or other hardware device 102 not affiliated with a third party 108, a backend verification module 104b, or the like). The interface, in one embodiment, comprises a private interface between the verification modules 104a of the users' hardware devices 102 and one or more back-end verification modules 104b. For example, this may make it possible for a backend verification module 104b to provide a user with access to the user's downloaded and/or aggregated data in multiple locations, on multiple hardware devices 102, through multiple channels or the like, even if the user hardware device 102 that under data is turned off, out of battery, not connected to data network 106, or the like. In another embodiment, the interface comprises a public and/or open interface that can be secured by allowing a user to share the user's downloaded data from a verification module 104 to one or more tools, services and/or other entities to store, process and/or otherwise use the data.

In various embodiments, a verification module 104 can be incorporated as hardware, software, or some combination of hardware and software. In one embodiment, a verification module 104 may comprise computer executable program code stored on a non-transient computer readable storage medium for execution on a hardware device processor 102, and back-end server 110, or the like. . For example, a verification module 104 may be embedded as executable program code in one or more of a hardware device 102, a back-end server 110, a combination of one or more of the above, or the like. In this embodiment, the various modules that perform the operations of a verification module 104, as described below, may be located in a hardware device 102, a back-end server 110, a combination of the two, and/or the like.

In various embodiments, a verification module 104 can be incorporated as a hardware device that can be installed or deployed in a back-end server 110, in a user hardware device 102 (e.g., a dongle, a protective housing for an handset 102 or tablet 102 that includes one or more semiconductor integrated circuit devices within the housing in communication with the handset 102 or tablet 102 wirelessly and/or at a data port such as USB or a proprietary communications port, or other peripheral device), or elsewhere on the data network 106 and/or placed with a user hardware device 102. In certain embodiments, a verification module 104 may comprise a hardware device such as a secured hardware dongle or another hardware device (eg, a decoder, a network device, or the like) that attaches to another hardware device 102, such as a laptop, a server, a computer. tablet device, a smartphone, or the like, either by cable connection (eg USB connection) or wireless connection (eg Bluetooth®, Wi-Fi®, proximity field communication (NFC), or similar); that attaches to an electronic display device (for example, a television or monitor that uses an HDMI port, a DisplayPort port, a Mini DisplayPort port, a VGA port, a DVI port, or the like); operating substantially independently on a data network 106; or similar. A hardware device of a verification module 104 may comprise a power interface, a wired and/or wireless network interface, a graphical interface (e.g., a graphics card and/or GPU with one or more display ports ) which outputs to a display device and/or a semiconductor integrated circuit device, as described below, configured to perform the functions described herein in connection with a verification module 104.

A verification module 104, in this embodiment, may comprise a semiconductor integrated circuit device (e.g., one or more chips, matrix, or other discrete logical hardware), or the like, such as a field-programmable gate array (FPGA) or other programmable logic, firmware for an FPGA or other programmable logic, microcode for executing in a microcontroller, an application-specific integrated circuit (ASIC), a processor, a processor core, or the like. In one embodiment, a verification module 104 can be mounted on a printed circuit board with one or more electrical lines or connections (e.g., for volatile memory, a non-volatile storage medium, a network interface, a peripheral device, a graphical/display interface. The hardware device may include one or more pins, pads, or other electrical connections configured to send and receive data (for example, in communication with one or more electrical lines on a printed circuit board or the like) , and one or more hardware circuits and/or other electrical circuits configured to perform various functions of a verification module 104.

The semiconductor integrated circuit device or other hardware device of a verification module 104, in certain embodiments, comprises and/or is communicatively coupled to one or more volatile memory media, which may include, among others: random access media ( RAM), dynamic RAM (DRAM), cache, or the like. In one embodiment, the semiconductor integrated circuit device or other hardware device of a verification module 104 comprises and/or is communicatively coupled to one or more non-volatile memory media, which may include, among others: NAND flash memory, memory NOR flash, nano random access media (nano RAM or NRAM), cable-based nanocrystal memory, silicon oxide-based nanometer sub-10 process memory, graphene memory, silicon oxide silicon oxide nitrite (SONOS) , resistive RAM (RRAM), programmable plating cell (PMC), conductive bridge RAM (CBRAM), magneto-resistive RAM (MRAM), dynamic RAM (DRAM), phase change RAM (PRAM or PCM), media. magnetic storage (eg hard disk, tape), optical storage media or the like.

Data network 106, in one embodiment, includes a digital communication network that transmits the digital communications. Data network 106 may include a wireless network such as a wireless cellular network, a wireless local area network such as a Wi-Fi network, a Bluetooth® network, a proximity field communication (NFC) network, a ad hoc network and/or similar. 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. . Data network 106 can include two or more networks. Data network 106 can include one or more servers, routers, switches, and/or other network equipment. Data network 106 may also include one or more computer readable storage media, such as a hard disk drive, an optical drive, non-volatile memory, RAM, or the like.

The one or more third parties 108, in one embodiment, may include one or more network accessible computer systems, such as one or more web servers that host one or more websites, a corporate intranet system, an application server, an interface server application programming (API), an authentication server, or the like. The one or more third parties 108 may include systems related to various institutions or organizations. For example, third parties 108 may include a system that provides electronic access to a financial institution, a university, a government agency, a public service provider, an email provider, a social media site, a photo-sharing site, a a video sharing website, a data storage website, a medical provider, or other entity that stores data associated with a user. Third parties 108 may allow users to create user accounts to transfer, view, create and/or modify data associated with the user. Thus, the third party 108 can include an authorization system, such as a connection element or page of a website, application or similar front-end, where a user can provide credentials such as username/password combination to access the user data.

In one embodiment, the one or more backend servers 110 and/or one or more backend verification modules 104b provide central management of the various network verification modules 104a. For example, the one or more backend verification modules 104b and/or a backend server 110 may store data downloaded from the user centrally from verification modules 104a, may provide instructions for verification modules 104a to access the data from one or more third parties 108 using the user's credentials, or the like. A back-end server 110 may include one or more servers located remotely from hardware devices 102 and/or one or more third parties 108. A back-end server 110 may include at least a portion of the modules or sub-modules described above in with respect to verification modules 104 of Figure 2 and Figure 3, may comprise hardware of a verification module 104, may store executable program code of a verification module 104 on one or more non-transient computer readable storage media, and /or may otherwise perform one or more of the diverse operations of a verification module 104 described herein in order to aggregate user data from one or more third parties in a distributed manner.

Figure 2 depicts an embodiment of a verification module 104. In the depicted embodiment, the verification 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 a user's electronic credentials for a third party 108 from the user on a user's hardware device 102. In a further embodiment, the authentication module 202 can receive electronic credentials for a different user (e.g., from a different hardware device 102, from a back-end verification module 104, or the like), which can be encrypted and/or otherwise secured so that the direct access module 204 can download the data for the different user (eg, downloading data for multiple users from a single user hardware device 102).

For example, in the distributed/decentralized system 100, if a user's hardware device 102 is turned off, asleep, without battery, blocked by a third party 108, or the like, in certain embodiments, a verification module 202 in a user's hardware device different 102 and/or on a backend server 110 can download data to a user, using the user's electronic credentials, and can send the data to a user's hardware device 102, can send an alert and/or automatic notification to the a user hardware device 102, or the like. Thus, in one embodiment, a user may continue to aggregate data, receive automatic alerts and/or notifications, or the like, even if the user's own hardware device 102 is locked, unavailable, or the like. In cooperation with one or more authentication modules 202, verification modules 104a, 104b, in certain embodiments, can communicate with each other using a secure and/or encrypted protocol, and/or can store electronic credentials securely and/ or encrypted, so that a user cannot see and/or access another user's electronic credentials, downloaded data or other private and/or sensitive data.

In embodiments where a verification module 104 comprises hardware (e.g., a semiconductor integrated circuit device such as an FPGA, an ASIC, or the like), the authentication module 202 may comprise dedicated security hardware for storing and/or processing credentials electronic data, downloaded data and/or other sensitive and/or private data, such as a secure cryptoprocessor (eg a dedicated computer on a chip or microprocessor embedded in a package with one or more physical security measures) that does not produce decrypted data to a bus or non-secure storage, which stores cryptographic keys, a 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; or similar. In another embodiment, the authentication module 202 can store and/or process electronic credentials, downloaded data and/or other sensitive data in a secure and/or encrypted form using software and/or hardware from an existing user's hardware device 102 ( for example, data encryption in RAM, NAND, and/or other general purpose storage) with or without dedicated security hardware. In certain embodiments, the authentication module 202 may encrypt and/or secure data (e.g., electronic credentials, downloaded data) associated with a first user that is received, processed, and/or stored by a second (e.g., different) device from user hardware 102 (e.g., from user's first hardware device 102 to data network 106 or the like), preventing 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 a different user 102 hardware device.

In one embodiment, as described above, electronic credentials may comprise one or more of a username and password, fingerprint scan, retinal scan, digital certificate, personal identification number (PIN), challenge response, token security, hardware token, software token, DNA sequence, signature, facial recognition, voice pattern recognition, bioelectrical signals, two-factor authentication credentials, or other information by which the authentication module 202 can authenticate and/or validate an identity of and/or an authorization of a user.

The authentication module 202, in certain embodiments, may receive different credentials from a user for different user accounts with different third parties 108 (e.g., different social networks, different photo sharing sites, different financial institutions), so that the verification module 104 can download, aggregate and/or combine user data from several different third parties 108. In one embodiment, as described below with respect to password manager module 306 of Figure 3, authentication module 202 at instead of and/or in addition to receiving one or more passwords or other electronic credentials from a user, it may manage and/or assign one or more passwords or other electronic credentials for a user to one or more third parties 108. For example, in In certain embodiments, the authentication module 202 may receive an initial set of electronic credentials (eg, a username and password) from a user. o for a third party user account 108, and the authentication module 202 can use the initial set of electronic credentials to access the third party user account 108 to establish a new password determined by the authentication module 202. authentication 202, in one embodiment, can determine passwords or other electronic credentials that are more secure than those typically created by and/or memorable to a user (eg, larger numbers, more numbers, greater variation between uppercase and lowercase letters, more often altered or similar).

In one embodiment, the direct access module 204 accesses one or more servers 108 of one or more third parties 108, a hardware device 102 of a user and/or a back-end server 110, using electronic credentials of a user of the authentication module 202 (e.g., for the user associated with hardware device 102, for a different user, or the like). Direct access module 204, in certain embodiments, downloads data associated with a user (eg, a user's social media posts, a user's photos, a user's financial transactions, or the like) from one or more servers 108 of one or more third parties 108 to a hardware device 102 of a user (e.g., of the user associated with the downloaded data, of a different user for processing and/or transfer to the hardware device 102 of the user associated with the downloaded data or the like) and /or to a backend server 110 associated with the direct access module 204, instead of or in addition to downloading the data directly to a user's hardware device 102 (e.g., based on the availability of the hardware device 102 of the to back up the data to a second location, or similar).

Direct access module 204, in certain embodiments, may use a web page interface of a third party server 108 to access server 108 using a user's electronic credentials and/or download data associated with the user. For example, in certain embodiments, the direct access module 204 can download/upload a web page from a third party 108 server 108, enter a username and password or other electronic credentials for a user in text boxes on a form. on the webpage, submit the username and password or other electronic credentials using a submit button or other element of the webpage interface and/or otherwise submit electronic credentials using a website to gain authorized access to data on the server 108 associated with the user. As described below, the standard module 308 may receive and/or provide instructions that enable the direct access module 204 to access a server 108 (e.g., a location or method for sending electronic credentials, or the like).

In response to successful authentication and access to a third party server 108 with a user's electronic credentials, the direct access module 204 may download data associated with the user (e.g., from a user account or the like) from the server 108 to a hardware device 102 associated with the user, to a backend server 110, to a hardware device 102 of another user that downloads data on behalf of the user, or the like. As described below, in certain embodiments, the standard module 308 may receive and/or provide instructions that enable the direct access module 204 to download data associated with a user from a third-party server 108 (e.g., a URL or other link to a place for the data, a tag or other identifier for locating the data on one or more web pages or other structured data, or the like). Direct access module 204, in certain embodiments, may follow the instructions of a standard module 308 to authenticate and/or access data from one or more web pages of a server 108 in a screen-scraping form by analyzing one or more web pages for locating an entry location and/or submitting electronic credentials; to locate, download and/or extract data associated with a user, or similar.

In one embodiment, the direct access module 204 sends or otherwise presents the electronic credentials and/or receives or otherwise downloads the data using an API or other access protocol from a third-party server 108. For example, the module Direct Access 204 may send a request in a specific and/or compatible format to a server 108 (eg an API server 108) of a third party 108. The sent request may comprise electronic credentials for a user or a portion thereof (by example, username and/or password), a subsequent request may comprise electronic credentials for a user or a portion thereof (for example, in response to receiving an acknowledgment from server 108 for the first request, or the like) and/or direct access module 204 may use a different access protocol than server 108.

In response to a request for data from direct access module 204 (e.g., in response to direct access module 204 which authenticates a user using an access protocol of a server 108), a third party server 108 may send and/ or return data associated with a user (for example, in one or more messages, packages, payloads, such as a URL or other pointer to a location from which the direct access module 204 can retrieve the data, or the like). Direct access module 204, in various embodiments, can receive data associated with a user directly from a third-party server 108 in a data network 106; may receive a bookmark, URL or other link to a data location associated with a user of a third party server 108; may receive data associated with a user from another entity in a data network 106 (e.g., in response to a request from third party server 108 for the other entity or the like); or may otherwise receive data associated with a user in accordance with a third party access protocol 108.

In one embodiment, the third party 108 provides a direct access module 204 with an API or other access protocol. In a further realization, a direct access module 204 can act as a package for and/or a plugin or extension of a third-party app 108 (eg, a mobile app), and the app can have access to an API or other third-party access protocol 108. In another embodiment, a direct access module 204 may be configured to use an API or other access protocol in the same way as a third-party application 108 (e.g., a mobile application), through observation third-party application 108 or similar. In certain embodiments, a direct access module 204 can cooperate with a third-party application 108, a web browser through which a user accesses third-party services 108, or the like to access data associated with a user (e.g., accessing data already downloaded by an application and/or user, accessing a database or other data store from an application and/or web browser, scanning and/or scraping the screen of a third party web page 108 as a user accesses the web page, or similar).

Direct access module 204, in certain embodiments, can access different third parties 108 in different ways. For example, a first third party 108 may grant direct access module 204 access to an API or other access protocol, while direct access module 204 may use a web page interface (eg, page scraping) to access and downloading data from a second third party 108, or the like. In one embodiment, a remote backend server 110 may be associated with a first party service provider 110 (e.g., a vendor and/or provider of a verification module 104) and the direct access module 204 may download data. associated with a user of either the first party service provider 110 or the one or more third party 108, aggregating the data together so that the user can access the data in a single interface and/or application. For example, as described below with respect to interface module 206, interface module 206 can provide a user with access to user photos from several third-party cloud storage providers 108 in a single photo application, it can provide a user with access to a user's personal financial information in a single personal financial administration application and/or online banking application, may provide a user with access to multiple social media posts in a single social networking application, or similar.

Direct access module 204, in certain embodiments, can store downloaded and/or aggregated data independently of one or more third parties 108. For example, direct access module 204 can store a user's downloaded and/or aggregated data in a user hardware device 102, on a user-accessible back-end server 110, or the like. Thus, in certain embodiments, a user can control and/or access user data, even if the third party 108 closes or is not available, can use user data in any way desired by the user even if the use is not supported by third parties 108, or similar.

Direct access module 204, in one embodiment, in addition to and/or instead of downloading data from one or more third parties 108, may load the data and/or change one or more settings of one or more third parties 108 in response to the user input or the like. For example, in embodiments where the data comprises photos, the direct access module 204 may upload a photo from a user's hardware device 102 to one or more third parties 110 (e.g., a downloaded photo that the user has edited on the hardware device 102 or similar). In embodiments where the data comprises social media posts or other content, the direct access module 204 may receive input from a user (e.g., a photo, a text post, one or more emojis, a video, a document, or another file, or the like) and upload the received entry to one or more third parties 108 (for example, social media sites or the like). In embodiments where the data comprises financial transactions or other financial data, the direct access module 204 may schedule a bill payment or other payment or money transfer, remote deposit of a check (e.g., when loading photos from the front and/ or back of the check, or similar) and/or perform another action.

Direct access module 204 can upload or change a user's account information with third parties 108, such as an account type or plan, credit card or other payment information associated with an account, a telephone number or address, or other contact information with an account, a password or other electronic credentials for an account, and/or other account information of a user for a third party 108. Direct access module 204 may update and/or load data in substantially similar manner to that described herein for downloading data (for example, determining a user's electronic credentials to a third party 108, accessing a third party 108 server 108, uploading and/or providing data to a third party 108, or the like).

In one embodiment, the interface module 206 provides the user data downloaded by the direct access module 204 from a hardware device 102 of one user (e.g., the user associated with the downloaded data, of a different user) to another entity, such as a user's hardware device 102 associated with the downloaded data (for example, in response to data downloaded by a hardware device 102 of a different user, from a hardware device 102 of one user to another hardware device 102 of the same user), a remote server 110 or other remote device 102 not affiliated with (eg, not owned by, operated by, controlled by, or similar) third parties 108 from which the data was downloaded, or the like. For example, the interface module 206 may provide an API or other interface to provide a user's downloaded and/or aggregated data to a user's hardware device 102, to a backend verification module 104b, to a back server -end 110, to different thirds 108, to a different/second user hardware device 102, or the like.

In certain embodiments, it may be transparent and/or substantially transparent to a user (e.g., not apparent) that hardware device 102, 110 has downloaded data associated with the user. For example, the interface module 206 may provide downloaded data associated with a user from a user hardware device 102 to another user hardware device 102, from a user hardware device 102 to a backend server 110 (e.g., from which the user can access the data using a web browser, an application or the like), from a backend server 110 to a hardware device 102 of the user, or the like, allowing the user to access the data from a different location than location to which the data was downloaded.

In certain embodiments, the interface module 206 provides a graphical user interface (GUI) on a hardware device 102 of a user and provides user-associated downloaded data to the user through the GUI (eg, allowing the user to view the data directly, providing one or more notifications and/or recommendations to the user based on the data, providing one or more tables or graphs to the user based on the data, providing a summary of one or more statistics related to the data, or similar). The interface module 206, in various embodiments, can provide a GUI to the user from the same hardware device 102 to which the data was downloaded, on a hardware device 102 different from the hardware device 102, 110 to which the data was downloaded. downloaded, or similar.

For example, in an embodiment where the data associated with a user comprises photos, the interface module 206 may provide a photo management interface, a photo editing interface, or the like, in which the user can view and/or another way to access the user's downloaded and/or aggregated photos. In a further realization, where the data associated with a user comprises the user's financial transaction history (for example, purchases and/or other financial transactions downloaded from one or more financial institutions 108 such as banks, credit unions, finance companies or the like ), the interface module 206 may provide a personal financial administration interface, with a list of transactions, one or more budgets, one or more financial goals, a debt management interface, an equity interface, and/or other interface financial administration system where the user can view the user's downloaded and/or aggregated financial transaction history and/or alerts or recommendations based on these. In another embodiment where the data associated with a user comprises social media posts, the interface module 206 may provide a GUI comprising a stream, feed and/or wall of social media posts for the user to view (e.g., posts from social media downloaded and/or aggregated from various social networks 108, from different user contacts or friends, or similar).

Interface module 206, in certain embodiments, may provide one or more access controls to a user, allowing the user to define which devices 102, users, third parties 110 or the like can access which data. For example, the interface module 206 may provide an interface for a user to allow and/or restrict certain mobile applications, certain APIs for third party services, certain plugins or extensions, certain users, certain hardware devices 102 and/or one or more other entities to access data downloaded for the user from one or more third parties 108 (for example, with access controls by third parties 108 or other data source, by data type, by entity requesting access, and/or in other granularity). Thus, the verification module 104, in certain embodiments, may comprise a local repository of aggregated data, which one or more other devices 102 and/or services may access and use, with the user's permission.

Figure 3 represents another embodiment of a verification module 104. In the depicted embodiment, the verification module 104 includes an authentication module 202, a direct access module 204 and an interface module 206 and further includes a routing module 314, a frequency module 316 and a test module 318. The authentication module 202, in the depicted embodiment, includes a local authentication module 302, a network authentication module 304, and a password manager module 306. The direct access module 204 , in the illustrated embodiment, includes a standard module 308, an access repair module 310, and a hierarchy module 312.

In one embodiment, the local authentication module 302 protects and/or authenticates user access to downloaded data, stored passwords and/or other data on a user's hardware device 102, transferred to and/or from a hardware device User 102, or similar. For example, the local authentication module 302 may cooperate with one or more security and/or authentication systems of the user's hardware device 102, such as a PIN, password, fingerprint authentication, facial recognition, or other electronic credentials used by the user. to gain access to hardware device 102. In a further embodiment, local authentication module 302 may authenticate a user before allowing interface module 206 to provide user access to downloaded/aggregated data and/or alerts or other messages. For example, local authentication module 302 may manage and/or access electronic credentials associated with verification module 104, for a user, and may authenticate the user in response to the user accessing an application and/or service of verification module 104 .

In certain embodiments, the local authentication module 302 may encrypt and/or otherwise secure, on a user's hardware device 102, the electronic credentials and/or downloaded data associated with a different user, so that the user cannot access the data associated with the different user, but the different user can access the data as it is transmitted to a different user's hardware device 102, to a backend server 110, or the like. Local authentication modules 302 of different hardware devices 102, 110 can cooperate to securely transfer data (e.g., one or more electronic credentials, downloaded data, or the like) in the data network 106, of a hardware device 102, 110 to another hardware device 102, 110. In a further embodiment, the local authentication module 302 can ensure that a user's electronic credentials and/or downloaded data remain on a single hardware device 102 (e.g., not transmitted in a data network 106), in a secure repository or the like, and are not stored and/or accessible to a back-end server 110, a hardware device 102 of another user, or the like.

In one embodiment, the network authentication module 304 receives and/or stores a user's electronic credentials for one or more third parties 108 on a user's hardware device 102, a back-end server 110, or the like. Network authentication module 304, in various embodiments, can receive a user's electronic credentials from the user, a user's hardware device 102, a back-end server 110, or the like. Network authentication module 304 may cooperate with direct access module 204 to provide electronic credentials of a user to a third party server 108 (e.g., network authentication module 304 may provide electronic credentials to the direct access module 204 for providing a server 108, the network authentication module 304 can provide the electronic credentials directly to a server 108, or the like).

Network authentication module 304, in certain embodiments, may cooperate with local authentication module 302 to encrypt and/or otherwise secure a user's electronic credentials to one or more third parties 108, in a hardware device 102 of a user, and a data network 106, on a hardware device 102 of a different user, on a back-end server 110, while being provided to a third party server 108, or the like. In a further embodiment, the network authentication module 304 ensures that a user's electronic credentials are only stored on a user's hardware device 102 and sent from the user's hardware device 102 to a third-party server 108, and not store a user's electronic credentials on a backend server 110, on a different user hardware device 102, or similar. In another embodiment, the network authentication module 304 can securely store (e.g., using secure encryption) a user's electronic credentials to a third party 108 on a back-end server 110, on a different user hardware device 102, or similar, so that a direct access module 204 can access and/or download data associated with the user, even if the user's hardware device 102 is not available, locked, or the like, as described below in relation to the routing module 314. In certain embodiments, either the network authentication module 304 and/or the local authentication module 302 allow electronic credentials to be sent and/or stored by a different user hardware device 102, a back-end server 110 , or similar, can be based on a setting defined based on user input, so that the user can decide a security level, or the like.

In one embodiment, password manager module 306 can manage and/or store a user's electronic credentials for a plurality of third parties 108 so that direct access module 204 can access and/or download user-associated data from each. of the plurality of third parties 108. The password manager module 306, in certain embodiments, may generate and/or otherwise manage different secure credentials for each plurality of third parties 108.

Password manager module 306, in one embodiment, can securely store the generated credentials for a user on a 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 a direct access module 204 to access third parties 108 using the generated electronic credentials, the password manager module 306 can automatically populate one or more interface elements of a form on a web page with the electronic credentials (eg, a username, a password) of the user, in response to the user accessing the web page in a web browser, or the like, without the user manually entering the electronic credentials. The password manager module 306, in certain embodiments, may periodically update (e.g. regenerate different credentials, such as a different password, and update the third party user account 108 with the different regenerated credentials) periodically the electronic credentials for a user , like every week, every month, every two months, every three months, every four months, every five months, every six months, annually, every two months, in response to a user request, in response to a third party request 108 and/or at another time period or in response to another periodic trigger.

Password manager module 306, in one embodiment, can synchronize a user's electronic credentials (e.g., user-provided, generated by password manager module 306, or the like) between different hardware devices 102, web browsers, or similar from a user. For example, in response to a password manager module 306 and/or the user who updates or otherwise changes electronic credentials, the password manager module 306 can propagate the update/change to one or more other password manager modules 306 , on different user hardware devices 102, or similar.

In one embodiment, the pattern module 308 determines an ordered list (e.g., a pattern, a script, or the like) of various locations on one or more third-party servers 108 108 for the direct access module 204 to access the server (e.g., which may include locations other than where user data is stored and/or accessible), one or more delays for direct access module 204 to wait between access locations in server 108, and/or other components of an access pattern to access data from a server. Sites, in certain embodiments, comprise independently addressable and/or accessible content and/or assets provided by one or more third party servers 108, or similar, such as web pages, portions of a web page, images or other data files , databases or other data stores, pages or sections of data from a mobile application, or the like. The pattern module 308, in one embodiment, determines a pattern/ordered list that contains one or more locations and/or delays that are not necessary for the direct access module 204 to access or use in order to download the desired data but instead , the standard/ordered list can make it difficult or impossible for a third party 108 to distinguish between a direct access module 204 accessing a third party server 108 and a user accessing the third party server.

The pattern module 308, in one embodiment, may determine and/or select the various locations and/or the one or more delays (e.g., a pattern/ordered list) based on an average pattern or a combined pattern identified or based on the behavior of various users accessing third parties 108 using a web browser, a mobile application, or the like. The standard module 308, in one embodiment, can monitor one or more users (e.g., for a predetermined period or the like) as they access a third-party server 108, tracking which links, data, web pages and/or other locations the one or more users access, how long the one or more users access different locations, an order in which the one or more users access the locations, or similar. In certain embodiments, the one or more monitored users may be volunteers who have provided the standard module 308 with authorization to temporarily or permanently monitor user access in order to provide a more realistic access standard for the direct access module 204 to use to access a third-party server 108.

In a further embodiment, the pattern module 308 determines and/or selects multiple locations and/or one or more delays between accessing different locations based on an identified pattern in user behavior associated with the hardware device 102 in which the pattern module 308 is arranged accessing the third party service using a web browser, a mobile or computer application, or other user hardware device interface 102. For example, the standard module 308 may comprise hardware device networking hardware of user 102 (e.g., a network access card and/or chip, a processor, an FPGA, an ASIC, or the like in communication with the data network 106 to monitor data and/or interactions with a third party server 108), a web browser plugin or extension, a mobile and/or computer device that runs on a processor of the user's hardware device 102, or the like. Standard module 308 may request and receive user authorization to monitor user activity against one or more third party servers 108 from user hardware device 102.

The pattern module 308, in certain embodiments, may update a pattern/ordered list over time based on detected changes in the access patterns of one or more users or the like. In one embodiment, pattern module 308 may coordinate and/or cooperate with access repair module 310, described below, to update a pattern/ordered list in response to a third party server 108 and/or data associated with a user that has been stopped and/or is 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 a user is interrupted and/or becomes inaccessible. Access repair module 310, in certain embodiments, provides an interface to a user that allows the user to graphically identify an entry location for the user's electronic credentials, a location of data associated with the user, or the like. For example, access repair module 310 may provide a GUI, a command line interface (CLI), an API and/or other interface that allows an end user to identify an entry location for electronic credentials, an action to submit electronic credentials, a data location, or the like. Access repair module 310, in one embodiment, provides an interface to a user on a hardware device 102 of the user.

In certain embodiments, for example, access repair module 310 may overlay an interface on one or more pages of a third party website 108 on an electronic display screen of a user's hardware device 102, as described in detail below in connection with to Figures 5A-5B. Access repair module 310 may provide one or more interfaces (eg, GUIs, CLIs, APIs, overlays, or the like) to multiple users, allowing multiple users to define a fix and/or update to access a third-party server 108 (for example, in a distributed and/or decentralized way, from different hardware devices 102 or similar in a network 106).

Access repair module 310, in certain embodiments, may determine and/or display one or more 504 suggestions and/or 504 recommendations to the user, which the user may confirm or change/correct (for example, in a basic interface, a standard interface, an initial user interface, or similar). For example, the Access Repair module 310 may display one or more interface elements with a suggested location for a user to enter a username, a suggested location for a user to enter a password, a suggested credential submit action, a suggested location of data associated with the user, and/or one or more interface elements that allow the user to graphically identify one or more locations on a third-party website 108.

Access repair module 310, in certain embodiments, processes one or more pages from and/or other locations on a server 108 (e.g., one or more websites, web apps or the like) to determine an estimate and/or prediction an entry location for a user's electronic credentials, an action for sending a user's electronic credentials, a location of data associated with a user, or the like. In one embodiment, access repair module 310 can estimate one or more locations and/or actions (for example, when scanning and/or analyzing one or more pages of a website, based on input from other users accessing one or more pages of a website, based on previous user interactions with one or more pages of a website, a prediction made using machine learning and/or artificial intelligence analysis of a website, based on a statistical analysis of historical changes to one or more pages of a website and/or one or more similar or similar websites). Access repair module 310 may display to a user in an interface an estimate and/or prediction of an entry location for the user's electronic credentials, a location of data associated with the user, or the like so that the user can confirm that estimate and/or predict is correct or not using the interface.

Access repair module 310 may indicate one or more estimated locations and/or actions with an arrow or other indicator of a location; a link or other identifier for a location; an other highlight box around a location; changing the text tag to a place to make text bold, italic, and/or underlined; or similar. A user, in certain embodiments, may click, select, or otherwise identify a location to confirm or change/correct a location suggested by Access Repair module 310. For example, a user may click or otherwise select an element of interface associated with a location and/or action and can click or otherwise select the location and/or perform the action, which the Access Repair module 310 can record (for example, automatically fill in a text field that identifies the location and/or action, recording a macro that allows the action to be automatically repeated without the user, for a different user, or similar).

In certain embodiments, instead of or in addition to a standard, basic or initial user interface, the Access Repair Module 310 may provide an advanced interface, for experienced users or the like, with source code for a website and/or others. website details. For example, in one realization, an advanced access repair interface may allow one or more advanced users to identify one or more locations and/or actions in a website's source code, which may not be visible and/or readily evident on the website itself. Web site. In certain embodiments, the access repair module 310 may provide a user interface element that allows a user to select and/or switch between a standard user interface or view and an advanced user interface or view.

In one embodiment, test module 318 cooperates with access repair module 310 to verify whether one or more locations and/or instructions of a user are accurate or not (e.g., useful for accessing data from a third-party server 108 ). Test module 318, in certain embodiments, attempts to access a third party server 108 108 for a plurality of different users (e.g., a sample group or test set), based on an ID of the received access repair module 310 of a single user, using the electronic credentials of different users or similar.

Test module 318, in certain embodiments, determines whether data associated with different users (eg, a sample group or test set) is accessible using the unique user identification. Test module 318 may repeatedly attempt to access third-party data 108 using IDs that Access Repair module 310 has received from different users (for example, on different hardware devices 102 and sends to test module 318 on a single hardware device 102 in data network 106, sends to several test modules 318 in different hardware devices 102 in data network 106, sends to a test module 318 in a central backend server 110, or the like).

Test module 318, in one embodiment, provides one or more user IDs to other examples of direct access module 204 (e.g., other test modules 318) to access a third party server 108 108 in response to a number of different users (eg a sample group or test set) for which data is accessible using unique user identification satisfy a threshold. For example, if the unique user ID successfully allows a predefined number and other test users (eg 2 users, 10 users, 100 users, 1000 users, 50% test users, 75% test users, and /or other predefined threshold number of test users) to access its data from third parties 108, test module 318 may provide identification based instructions to more users (eg all or substantially all users, or the like).

In certain embodiments, test module 318 may successively augment a test dimension comprising several users to which test module 318 provides instructions for accessing its third-party data 108 using a unique user identification (e.g., starting with one or more users test, 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, a hundred or more, five hundred or more, a thousand or more, five thousand or more, ten thousand or more, a hundred thousand or more, a million or more, and/or other successively increasing numbers of test users). Test module 318, in one embodiment, includes instructions based on a single user identification in an ordered list of several different instruction sets for accessing a third party server 108 108, as described in detail below in relation to hierarchy module 312 .

Test module 318, in certain embodiments, is configured to prioritize the IDs of one or more users based on one or more confidence factors for the one or more users (eg, scores or the like). A confidence factor, in an achievement, might comprise a score or other metadata indicating a probability that the user ID is correct. For example, in many realizations, a confidence factor may include and/or be based on one or more of a user's past identification history (eg, correct or incorrect), a user's affiliation with a provider (eg, a creator, a supplier, an owner, a seller, a reseller, a manufacturer, the backend server 110, or similar) of one or more verification modules 104, positive and/or negative indicators (eg, votes, likes, uses, feedback, stars, endorsements, or the like) of other users, and/or other indicators of whether or not the identification is likely to be correct. Test module 318 can determine how many other users to provide user identification based on one or more confidence factors associated with the user (for example, accelerating a rate at which user identification is provided to other users in response to a factor confidence factor, decreasing a rate at which user identification is provided to other users in response to a lower confidence factor, or the like).

The 318 test module can provide a command interface, allowing an administrator, moderator user or the like to remove an ID, set and/or command an ID, set and/or command a confidence factor for a user, prohibit a user from providing IDs, and/or otherwise command a user or user ID. In several embodiments, the 318 test module can provide a command interface to an administrator and/or moderator such as a GUI, an API, a CLI, or the like.

In certain embodiments, the test module 318 makes the one or more verification modules 104 and their aggregation services self-healing, self-testing and/or additional self-implementing, as it tests and uses the most effective solutions, or similar ( for example, sets of instructions based on input from one or more users).

In one embodiment, hierarchy module 312 provides direct access module 204 with an ordered list of several different instruction sets for accessing a third party server 108 using a user's electronic credentials, to download data associated with the user, or the like. . Each different set of instructions, in certain embodiments, comprises a location to enter a user's electronic credentials, an instruction to send the user's electronic credentials, one or more locations for the user's associated data, or the like.

Hierarchy module 312, in one embodiment, may receive one or more instruction sets from a back-end server 110 (e.g., a back-end verification module 104b of a back-end server 110), from another device. user hardware 102 in point-to-point mode (e.g., a verification module 104a of a user hardware device 102), of a test module 318, or the like. Hierarchy module 312, in certain embodiments, may receive several different sets of instructions already in an ordered list (for example, a global order of hierarchy) based on a history of successful and/or unsuccessful uses of the different sets of instructions by different user hardware devices 102 and/or users, or similar. In one embodiment, hierarchy module 312 can determine a hierarchy for and/or create an ordered list of several different sets of instructions for a single user (e.g., a custom or individualized hierarchy) based on a history of successful usages. and/or unsuccessful of the different sets of instructions by the user (for example, from one or more of the user's 102 hardware devices).

Direct access module 104, in one embodiment, can iterate through an ordered list of several instruction sets to access a third party server 108 108, in the order of the list, until one of the instruction sets succeeds and the direct access 104 can access and/or download data from third parties 108. Hierarchy module 312, in one embodiment, can place the most recently successfully used set of instructions at the top (eg, as the first set to attempt ). For example, hierarchy module 312 for a user hardware device 102 may place a third party access instruction set 108 at the top of a list (e.g., adjusting a list order over time) in response to the module direct access window 204 that successfully accesses and/or downloads data from a third party 108 using the instruction set. In certain embodiments, hierarchy module 312 may receive an ordered list of several different sets of instructions for accessing a third party server 108 108 in a first order (e.g., a global order) and may dynamically adjust and/or rearrange the different instruction sets over time based on user's single hardware device 102 usage (eg moving an instruction set up the list if accessing using the instruction set is successful for user/hardware device 102, moving an instruction set down in the list if access using the instruction set is unsuccessful for user/hardware device 102, or similar).

Hierarchy module 312, in certain embodiments, may be configured to share one or more instruction sets, an ordered list of several instruction sets, or the like with a hierarchy module 312 of another user hardware device 102 on a network. 106 (e.g., directly to the user's other hardware device 102 in a point-to-point fashion, indirectly via a backend verification module 104b of a backend server 110, or the like). Different sets of instructions can be successful or unsuccessful for different users, in different realizations, due to different account types, different account sets, different source systems (eg due to corporate acquisition or similar, different users of the same third party 108 may have one or more different sets, different access methods, or similar), system changes or updates, and/or other difference in accounts, services or the like for different users of the same third party 108.

In one embodiment, routing module 314 determines whether a user's hardware device 102 is available to direct access module 204 to download user-associated data from a third-party server 108. Routing module 314, in certain embodiments, may access a third party server 108 from a remote backend server 110 using electronic user credentials to download user-associated data from server 108 to remote backend server 110 in response to routing module 314 determining that the user's hardware device 102 is not available. Routing module 314, in one embodiment, provides a user with one or more alerts (e.g., data downloaded from third parties 108, a recommendation or suggestion determined based on data from third parties 108, a notification or other alert based on a event or other trigger detected in third party data 108, or the like) on a user's hardware device 102 based on the user-associated data downloaded to the remote backend server 110.

In certain embodiments, routing module 314 maintains and/or stores a list of various hardware devices 102 associated with a single user and/or account. In response to the determination that a hardware device 102 associated with a user and/or account is not available (e.g., powered off, in airplane mode, not connected to data network 106, or the like), routing module 314 may accessing a third party server 108 from a different available hardware device 102 of the user and/or account, may provide one or more notifications or other alerts on a different available hardware device 102, or the like. Routing module 314, in various embodiments as described below in relation to Figures 4A4C, can dynamically route data transfer for a third party user 108 between various hardware devices, such as one or more user hardware devices 102, a or more hardware devices 102 from a different user, one or more backend servers 110 and/or other hardware device securely.

Routing module 314, in one embodiment, may switch or route between several hardware devices 102, 110 (e.g., from the same user, from different users, or the like) to download data for the same third-party user 108 periodically. For example, forwarding and/or switching devices 102, 110 from which data is downloaded can decrease the probability that the transfer will be misinterpreted as fraudulent or inappropriate. In another embodiment, the routing module 314 may download data from the same device 102, 110 (e.g., a user's primary hardware device 102, a back-end server 110, or the like), which may be authorized and/or identified by third parties 108 as a trusted device, or the like.

In one embodiment, frequency module 316 sets a frequency with which direct access module 204 accesses third party server 108. Frequency module 316, in certain embodiments, determines a frequency based on input from a back server - remote end 110, which may be unaffiliated with the third party 108 being accessed, so that the remote back-end server 110 (for example, frequency module 316 running on the remote back-end server 110) determines frequencies for a plurality of direct access modules 204 for different users and/or different hardware devices 102. For example, frequency module 316 can limit a single user and/or hardware device 102 from accessing the same third parties 108 more than a threshold number allowed in a period (eg, once every ten minutes, once every half hour, once every hour, twice a day, three times a day, four times a day, or the like). Frequency module 316, in certain embodiments, limits an access frequency to prevent unexpected denial of service by third parties 108, or the like.

Frequency module 316, in certain embodiments, can dynamically adjust a frequency with which a user and/or hardware device 102 can access third parties 108 over time. For example, frequency module 316 can monitor access and/or transfers by multiple users (eg all users, available users, active users, or the like) close or limit a total access and/or lower bandwidth for each of the different thirds 108 (for example, so as not to overwhelm any unique thirds 108, or the like). Thus, in one embodiment, a user and/or hardware device 102 may access and/or download data at a higher frequency when some other users and/or hardware device 102 are accessing and/or downloading data (e.g., times of low peak), but can be limited to a lower threshold or frequency of access when more other users and/or hardware 102 devices are accessing and/or downloading data (eg high peak time).

In a further embodiment, frequency module 316 determines a frequency based on input from a user, allowing the user to set the frequency of access independently of other users and/or a back-end server 110. Frequency module 316 may provide a user interface (eg, a GUI, CLI, API, or similar) allowing a user to establish and/or adjust an access frequency to download data from one or more third parties 108 using one or more hardware devices 102 (for example, providing different configurations that allow the user to set different access frequencies for different third parties 108, different user hardware devices 102, or the like).

In one embodiment, an account verification module 320 is configured to use received electronic user credentials to verify an account for the user. As described above, an account verification module 320 can verify an account in real time (e.g., substantially instantaneously), using the user's electronic credentials for the account (e.g., an account number and PIN/password, a username and password, or similar). In such an embodiment, an account verification module 320 receives the user's electronic credentials, a password manager (e.g., LastPass®) and/or the like. Electronic credentials may, in certain embodiments, include access tokens that can be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

For example, an account verification module 320 might attempt to access the user's account by presenting the user's access tokens as part of an OAuth service. As used here, OAuth can refer to an open standard/service for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites, but without providing passwords. In another example, an account verification module 320 may attempt to access a user's account using a web page associated with the account (for example, an HTTP interface, a screen scroll, or the like), may use an API associated with the account , or similar.

In various embodiments, an account verification module 320, in response to successful connection to the user's account using the user's electronic credentials, can be configured to verify an account existence, an account status, an account content ( for example, an amount present on a financial account, asset verification, income verification, or the like), a capacity or limitations of an account (for example, other services that the user has access to, or does not have access to), a level of subscription and/or association associated with an account, a number of messages associated with an account (for example tweets, Instagram posts, Facebook posts, product reviews, or the like), a most recent post associated with an account, a number of friends and/or followers associated with an account, or similar.

In some embodiments, an account verification module 320 is configured to use various methods to verify an account (e.g., in a failed, rollover, rollback, round robin, and/or other configuration). For example, in one realization, an account verification module 320 may attempt to access a user's account to verify the account using the user's electronic credentials (for example, using a web/HTTP interface, an Oauth service, and/or a interface API) and in response to the verification failure attempt, the account verification module 320 may attempt to verify the account using a different method such as microdeposits and/or may use another verification method.

As used herein, micro-deposits are deposits into a user's account, usually two or more deposits of small amounts, which, when the user views the deposits in their account, enters the deposit amounts into an interface of the entity that made the deposits to verify user account. The ordering and/or verification methods used by an account verification module 320, in some embodiments, may be configurable and/or customizable, based on one or more preferences of a user, an entity that verifies the user's account, or similar (for example, an account verification module 320 may use different failure methods, different verification methods, or similar for different users, different consumers/customers, or similar).

An account verification module 320 (for example, located in a personal financial administration application/system/platform, in a third party such as a banking institution or other financial institution, and/or the like), in one realization, can automatically verify one or more micro-deposits into an account based on aggregated financial transaction data for the account user. For example, in some embodiments, a user may have previously logged in to and/or configured an account for aggregation using an account verification module 320, and in response to a third-party verification request of the account, the account verification module 320 can send one or more micro-deposits to the account, and can process aggregated subsequent transaction data for the account to verify proper receipt of the one or more micro-deposits (e.g., corresponding amounts, a party to the transaction, or the like in a self-confirmation mode ).

For example, an account verification module 320, as part of a personal financial administration platform/application or a third-party system, can deposit $0.50 and $0.37 cents into the user account that the third party wants to verify in response to a Third party request to verify the account. An account verification module 320 can then access the user's aggregate transaction data (for example, without accessing the user's account directly, for example using a bank website), and process the transaction data by fetching the two micro-deposits in the account. An account verification module 320 can then determine whether micro-deposits are present in the aggregate transaction data, and if so, can determine whether the micro-deposit amounts match the amounts that have been deposited into the user's account and still send a confirmation or verification to the user. third parties that micro-deposits are present in the user's account. thus, in one embodiment, an account verification module 320 can verify an account for a user with little or no participation and/or additional input by the user (e.g., without the user manually entering an amount of a microdeposit to confirm the amount, or similar).

In further embodiments, the account verification module 320 sends the microdeposit transaction information (e.g., a microtransaction amount, a transaction party, and/or other identifying information) of the user's transaction data to a third party that prompts you to verify the user's account. For example, account verification module 320 may send microdeposit transaction information using a third party API using a third party interface (e.g., a website that account verification module 320 scratches to locate a location of website graphical entry for microtransaction information), and/or similar.

In other embodiments, an account verification module 320 may verify an account based on financial transaction data that is aggregated from a plurality of transaction data sources (e.g., bank servers) for the account (e.g., based on previous financial transactions already aggregated for the account, without additional micro-deposits or other verification, or similar). In such an embodiment, financial transaction data can be aggregated on a data aggregation server, which can be a first party server and/or a third party server. For example, the account verification module 320 may receive electronic credentials from the user at the data aggregation server and the data aggregation server may attempt to access the user's account on behalf of the user using the received electronic credentials. Upon successful connection to the user's account, the user's account information, for example, financial transaction data such as account number, branch identification number, and/or the like can be received on the data aggregation server.

In one embodiment, an image module 322 is configured to collect at least a portion of the user's electronic credentials or other information (e.g., a name, an identifier, an account number, an agency identification number, and/or similar) using a (automatic) scan (eg, a photo, optical character recognition, image recognition, or the like) or screenshot of a document, such as an invalidated check, a deposit slip, a receipt, a statement financial statement, a credit card statement, a mortgage statement and/or the like. In further embodiments, the account verification module 320 verifies the account information using the information that the module 322 image captures, for example, by comparing account information such as account numbers, user information (e.g., name, address, social security numbers, or similar), agency identification numbers, and/or similar.

In one embodiment, an information request module 324 collects a minimal amount of information from a user based on a verification order and/or method selected for verifying the user's account (for example, so that the request module 324 does not collect additional user information in response to one or more verification attempt failures). For example, an information request module 324 can prompt the user for the user's electronic credentials, for a name, for an account number, and/or the like. Thus, an information request module 324 may request information from the user to verify the user's account at one time without subsequent request for additional information from the user in response to the account verification failure.

In another embodiment, an information request module 324 may collect information from a user for a first verification method initially, e.g., using electronic credentials, and may subsequently collect additional information from the user for a second verification method, e.g., microdeposits. , in response to the failure of the first verification method, or the like. For example, an information request module 324 may request electronic user credentials for account verification and, in response to the account verification failure, subsequently requests user account information for user account verification using the one or more micro-deposits. .

In one embodiment, a reporting module 326 is configured to provide one or more reports and/or other messages to a user associated with an account being verified, a third-party request verification of the account, or the like (e.g., using a graphical user interface of a hardware device 102, an email, a text message, an automatic notification, or the like). A reporting module 326 may notify a user and/or third parties of the success or failure of an account verification, an order of failure of the verification methods used (eg, an audit trail, proof of diligence, a registration or similar), and/or similar.

In one embodiment, the reporting module 326 generates reports that indicate whether the user's account was successfully verified, whether the user's electronic credentials were successfully used to verify the user's account, whether microdeposits were used to verify the user's account in response to failure to verify the user's account using the user's electronic credentials and micro-deposit amounts, and/or similar.

Figure 4A depicts an embodiment of a system 400 for account verification. System 400, in the embodiment shown, includes a single user hardware device 102 with a verification module 104a. An authentication module 202 of verification module 104a, in certain embodiments, can store and/or manage the user's electronic credentials locally on the user's hardware device 102, the direct access module 204 can access one or more third parties 108 directly from the user hardware device 102 (e.g., on data network 106) to download user-associated data to user hardware device 102, interface module 206 may provide the data and/or one or more alerts/messages with based on the user data of the user hardware device 102, or the like. In the depicted system 400, the verification module 104a can create a local data repository for the user of one or more third parties 108, on the user's hardware device 102, without providing user credentials, user data or the like to a different user's hardware device, for a 110 backend server, or similar.

Figure 4B depicts an embodiment of a system 402 for account verification. System 402 in the illustrated embodiment includes a plurality of user hardware devices 102 with verification modules 104a associated with different users. In certain embodiments, a first verification module 104a (e.g., an authentication module 202 of the first verification module 104a) can securely provide the encrypted user credentials to a first user of the user's first hardware device 102a to a second module of verification module 104a (e.g., an authentication module 202 of the second verification module 104a), in the data network 106 or the like, so that a direct access module 204 of the second verification module 104a can access one or more third parties 108 from the user's second hardware device 102b (e.g., on data network 106) to download data associated with the first user.

For example, the user's second hardware device 102b may download data for the first user in response to the user's first hardware device 102a turned off, hibernated, blocked from access by one or more third parties 108, or the like, as determined by a module Router 314, or similar. The interface module 206 of the second verification 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., in response to the first hardware device of the user 102a being made available, to a different hardware device 102 associated with the first user, to a back-end server 110 to which the first user has access, or the like). As described below, in certain embodiments, authentication module 202, direct access module 204, interface module 206 and/or routing module 314 may encrypt and/or otherwise secure data for the first user (by example, the first user's electronic credentials, downloaded data associated with the first user, alerts/messages for the first user), so that it is difficult or impossible for the second user to access the data for the first user, thus avoiding and/or minimizing unauthorized access to the first user's data while providing greater flexibility in the devices 102 and/or locations from which data for the first user can be downloaded.

Figure 4C represents an embodiment of a system 404 for account verification. System 404, in the depicted embodiment, included one or more user hardware devices 102 with one or more verification modules 104a, and one or more backend servers 110 comprising one or more backend verification modules 104b. An authentication module 202 of a verification module 104a, in certain embodiments, can securely provide encrypted user credentials to a user of the user's hardware device 102 to a back-end verification module 104b (e.g. authentication 202 of the backend verification module 104b) at a backend server 110, on the data network 106 or the like, so that a direct access module 204 of the backend verification module 104b can access one or more third parties 108 from the back-end server 110 (e.g. on data network 106) to download the associated user data.

For example, the back-end server 110 may download data to the user in response to the user's hardware device 102a that is powered off, hibernated, blocked from accessing one or more third parties 108, or the like, as determined by a routing module 314 , or similar. The interface module 206 of the backend verification module 104b may provide one or more alerts/messages to the user based on the downloaded data and/or may provide the data provided to the user (eg, in response to the user's hardware device 102a which becomes available to a different hardware device 102 associated with the first user, directly from the backend server 110 as a web page and/or through a dedicated app, or the like).

Figure 5 depicts an embodiment of a method 500 for account verification. Method 500 starts and an authentication module 202 receives 502 a user's electronic credentials for a third party 108 from the user on a hardware device 102 of the user. a direct access module 204 accesses 504 a third party server 108 108 from the user's hardware device 102 using the user's electronic credentials. a direct access module 204 downloads 506 the user-associated data from the third party server 108 to the user's hardware device 102, and method 500 terminates.

Figure 6 depicts an embodiment of a method 600 for account verification. Method 600 starts and an authentication module 202 determines 602 a user's electronic credentials to a plurality of third parties 108. A direct access module 204 accesses 604 the servers of the plurality of third parties 108 using the determined electronic credentials 602. A module Direct access 204 downloads 606 the user-associated data from accessed servers 604 of the plurality of third parties 108.

A direct access module 204 aggregates 608 the downloaded data 606 from the plurality of different third parties 108. An interface module 206 provides 610 the aggregated data 608 to the user (e.g., displaying the data on a user's hardware device 102, sending an alert or other message to a user's hardware device 102, sending the data to a remote backend server 110 unaffiliated with third parties 108 which the user can access using a web interface and/or API, or similar) and method 600 ends.

Figure 7 represents another embodiment of a method 700 for account verification. Method 700 is initiated and, in one realization, an authentication module 202 receives 702 electronic credentials for a user. In further embodiments, an account verification module 320 verifies 704 the user's account using the received electronic credentials and, in response to the verification failure, verifies 706 the user's account using microdeposits, and method 700 terminates.

Figure 8 represents another embodiment of a method 800 for account verification. Method 800 begins and, in one embodiment, a direct access module 204 accesses 802 transaction data for a user that is aggregated from a plurality of user accounts. In further embodiments, an account verification module 320 identifies 804 at least one microdeposit transaction of a user account in the aggregated transaction data and verifies 806 the user's account using the information based on the microdeposit transaction, and method 800 ends.

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

A means for accessing a third party server 108 from a hardware device 102 of a user using electronic user credentials, in various embodiments, may include one or more of a hardware device 102, a back-end server 110 , a direct access module 204, a standard module 308, an access repair module 310, a hierarchy module 312, a verification 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 other semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware device or other hardware device, other logical hardware and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for accessing a third party server 108 108 from a user's hardware device 102 using the user's electronic credentials.

A means for downloading data associated with a user from a third party server 108 to a user's hardware device 102, in various embodiments, may include one or more of a hardware device 102, a back-end server 110, a direct access module 204, a standard module 308, an access repair module 310, a hierarchy module 312, a verification 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 other semiconductor integrated circuit device), an HDMI or another electronic display dongle, a hardware device or other hardware device, other logical 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 third party server 108 to a hardware device 102 of the user.

A means for packaging data downloaded from a user's hardware device 102 to a remote device 110, 102 unaffiliated with third parties 108 from which the data was downloaded, in various embodiments, may include one or more of a hardware device 102, a back-end server 110, an interface module 206, a verification module 104, a processor (e.g., a central processing unit (CPU), a processor core, a field-programmable port array (FPGA) or other programmable logic, an application-specific integrated circuit (ASIC), a controller, a microcontroller and/or other semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware device or other hardware device, or logical hardware and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for packaging downloaded data from a user's hardware device 102 to a remote device 110, 102 unaffiliated with third parties 108 from which the data was downloaded.

A means for providing downloaded data from a user's hardware device 102 to a remote device 110, 102 unaffiliated with a third party 108 from which the data was downloaded, in various embodiments, may include one or more of a device. hardware 102, a back-end server 110, an interface module 206, a verification module 104, a processor (e.g., a central processing unit (CPU), a processor core, a field-programmable port array (FPGA) ) or other programmable logic, an application-specific integrated circuit (ASIC), a controller, a microcontroller and/or other semiconductor integrated circuit device), an HDMI or electronic display dongle, a hardware device or other hardware device, other logical hardware and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for providing downloaded data from a user's hardware device 102 to a remote device 110, 102 unaffiliated with third parties 108 from which the data was downloaded.

A means for receiving a user's electronic credentials, in various embodiments, may include one or more of an authentication module 202, a hardware device 102, a back-end server 110, an interface module 206, a verification module 104, an account verification module 320, a processor (e.g., the 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 other semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware device or other hardware device, other logical hardware, and/or other executable code stored in a computer-readable storage medium. Other realizations may include similar or equivalent means for receiving a user's electronic credentials.

A means for using the received electronic credentials to verify an account for the user and, in response to account verification failure using the received electronic credentials, verification of the user's account using one or more micro-deposits, in various embodiments, may include one or more of a hardware device 102, a backend server 110, an interface module 206, a verification module 104, an account verification module 320, 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 other semiconductor integrated circuit device), an HDMI or other dongle display device, a hardware device or other hardware device, other logical hardware and/or other executable code stored on a readable storage medium per computer. Other realizations may include similar or equivalent means for using the received electronic credentials to verify an account for the user and, in response to account verification failure using the received electronic credentials, verifying the user's account using one or more micro-deposits.

A means for identifying at least one microdeposit transaction from a user account in the aggregate transaction data and verifying a user account using the information based on the microdeposit transaction, in various embodiments, may include one or more of a device. hardware 102, a back-end server 110, an interface module 206, a verification module 104, an account verification module 320, 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 other semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware device or other hardware device, or logical hardware and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for identifying at least one microdeposit transaction of a user account in the aggregated transaction data and verifying the user account using information based on the microdeposit transaction.

The means for carrying out the remaining method steps described herein, in various embodiments, may include one or more of a hardware device 102, a backend server 110, an authentication module 202, a local authentication module 302, an authentication module network 304, a password manager module 306, a direct access module 204, a standard module 308, an access repair module 310, a hierarchy module 312, an interface module 206, a routing module 314, a frequency module 316, a test module 318, a verification module 104, a network interface, a processor (eg, 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 other semiconductor integrated circuit device), an HDMI or other electronic display dongle, a hardware device or other hardware device, other logical hardware, and/or other executable code stored on a computer-readable storage medium. Other embodiments may include similar or equivalent means for carrying out one or more of the method steps described herein.

The present invention can be incorporated in other specific forms without deviating from its spirit or essential characteristics. The described achievements are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than the foregoing description. All changes that come in the meaning and equivalence range of the claims must fall within their scope.

Claims (30)

APPARATUS, characterized by comprising:
processor;
memory that stores executable code by the processor to:
receive electronic credentials from a user;
use the electronic credentials received to verify an account for the user; and
in response to the failure of account verification using the electronic credentials received, verify the user's account using one or more micro-deposits. APPARATUS according to claim 1, characterized in that the user's account is verified using the electronic credentials received in response to the successful connection to the user's account using the electronic credentials received. APPARATUS according to claim 1, the one or more micro-deposits characterized by comprising deposits of one or more amounts in the user's account and confirmation of the one or more deposited amounts. APPARATUS according to claim 1, characterized in that the user's electronic credentials are received on a data aggregation server, the data aggregation server trying to connect to the user's account using the received electronic credentials and receiving the account information for the user account in response to successful connection to the user account, the account information comprising at least one of an account number and an agency identification number. APPARATUS according to claim 4, characterized in that the code is executable by the processor to verify the account information using the information captured from an image of an invalidated check. APPARATUS according to claim 1, characterized in that the code is executable by the processor to request information from the user for verification of the user's account at one time without subsequently requesting additional information from the user in response to the account verification failure. APPARATUS according to claim 1, characterized in that the code is executable by the processor to request the user's electronic credentials for account verification and, in response to account verification failure, subsequently request the user's account information for account verification the user using the one or more microdeposits. APPARATUS according to claim 1, characterized in that the code is executable by the processor to check one or more features of the user's account, one or more features comprising an account status, account content, an account capacity, a level of subscription associated with the account, a number of messages associated with the account, a most recent message associated with the account, and a number of friends and/or followers associated with the account. APPARATUS according to claim 1, characterized in that the code is executable by the processor to provide one or more reports associated with the verification of the user's account, the one or more reports provided to the user and/or a third party that requests the verification of the user's account. user. APPLIANCE according to claim 9, characterized in that one or more reports indicate one or more among whether the user's account was successfully verified, whether the user's electronic credentials were successfully used to verify the user's account and whether the micro-deposits were used to verify the user's account in response to failure to verify the user's account using the user's electronic credentials and microdeposit amounts. APPARATUS according to claim 9, characterized in that one or more reports are provided using one or more among a graphical user interface of a hardware device, an email, a text message and an automatic notification. METHOD, characterized by comprising:
receiving electronic credentials from a user;
use of the electronic credentials received to verify an account for the user; and
in response to unsuccessful account verification using received electronic credentials, user account verification using one or more micro-deposits. METHOD, according to claim 12, characterized in that the user's account is verified using the electronic credentials received in response to the successful connection to the user's account using the electronic credentials received. METHOD, according to claim 12, being the one or more micro-deposits characterized by comprising deposits of one or more amounts to the user's account and confirmation of the one or more deposited amounts. METHOD according to claim 12, characterized in that the user's electronic credentials are received on a data aggregation server, the data aggregation server trying to connect to the user's account using the received electronic credentials and receiving the account information for the user account in response to successful connection to the user account, the account information comprising at least one of an account number and an agency identification number. APPARATUS, characterized by comprising:
processor;
memory that stores executable code by the processor to:
access transaction data for a user that is aggregated from a plurality of user accounts;
identify at least one microdeposit transaction from a user account in the aggregate transaction data; and
verify user account using microdeposit transaction based information. APPARATUS according to claim 16, characterized in that the code is executable by the process to send the microdeposit transaction information to third parties that request the verification of the user's account. APPARATUS according to claim 17, characterized in that the code is executable by the processor to send microdeposit transaction information by at least one of the use of a third-party application program interface and location of an input location for the information. transaction and microdeposit on a third-party interface and sending the microdeposit transaction information using the input location. APPARATUS according to claim 18, the entry location being characterized by comprising an entry location of a third party website, the entry location determined using a screen scraping of the website. APPARATUS according to claim 16, characterized in that the code is executable by the processor to use the electronic credentials previously stored for the user to access the aggregate transaction data for the user. APPARATUS according to claim 16, characterized in that the code is executable by the processor to generate the at least one microdeposit on a personal financial administration platform and deposit the at least one microdeposit into the user's account in response to a request from a third party to verify the user account. APPARATUS according to claim 21, characterized in that the code is executable by the processor to verify the at least one microdeposit transaction in the personal financial administration platform and send a verification confirmation to third parties. APPARATUS according to claim 16, characterized in that the code is executable by the processor to verify the user account by matching an amount of the microtransaction in the user account of the aggregated transaction data with an amount deposited in the user account. APPARATUS according to claim 16, characterized in that the code is executable by the processor to verify one or more characteristics of the user's account, one or more characteristics comprising the account status, account content, an account capacity, a level of signup associated with the account, multiple posts associated with the account, one most recent post associated with the account, and a number of friends and/or followers associated with the account. APPARATUS according to claim 16, characterized in that the code is executable by the processor to provide one or more reports associated with the verification of the user's account, the one or more reports provided to the user and/or a third party that requests the verification of the user's account. user. APPARATUS according to claim 25, characterized in that one or more reports indicate one or more among whether the user's account was successfully verified, whether the user's electronic credentials were successfully used to verify the user's account and whether the micro-deposits were used to verify the user's account in response to failure to verify the user's account using the user's electronic credentials and microdeposit amounts. APPARATUS according to claim 25, characterized in that one or more reports are provided using one or more of a graphical user interface of a hardware device, an email, a text message and an automatic notification. METHOD, characterized by comprising:
accessing transaction data for a user that is aggregated from a plurality of user accounts;
identifying at least one microdeposit transaction from a user account in the aggregate transaction data; and
verification of user account using information based on microdeposit transaction. METHOD, according to claim 28, characterized in that it further comprises sending microdeposit transaction information to third parties who request verification of the user's account. The METHOD according to claim 29, further comprising sending the microdeposit transaction information by at least one of using a third-party application programming interface and locating an input location for the microdeposit transaction information in a third-party interface and submission of transaction and microdeposit information using the input location.

Images