Patent Application
20210027365
Data management systems, such as transaction management systems, personal financial management systems, small business management systems, and tax preparation systems, have proven to be valuable and popular tools for helping users of these systems perform various tasks and manage their personal and professional lives. Many currently available data management systems use account aggregation to obtain the data necessary to provide users of these data management systems various features and services.
Account aggregation is the process of obtaining access to accounts identified as being associated with a user, and then collecting user account data, such as transaction data, from one or more the disclosed user accounts. The data management systems then process the collected account data from all disclosed, or identified, accounts to provide the user with analysis and recommendations such as various reports, advice, snapshots, and other features in a holistic way based on theoretically complete and current data.
To provide users of an account aggregating data management system accurate analysis and recommendations, it is important that the data management system obtain as complete a set of the users' data as possible. Since the users account data is obtained from disclosed accounts associated with the users, it follows that obtaining a complete set of account data requires the identification/disclosure of a complete set of accounts associated with the users.
In order to provide account aggregating data management systems with access to the disclosed accounts associated with a user, the user typically provides, directly or indirectly, a listing, or set, of their associated user accounts. Herein, these user accounts are referred to as “disclosed,” or “identified,” user accounts. Typically, the disclosed user accounts are identified by the user providing account identification data to the data management system at the time the user first signs up to use the data management system.
In addition to providing account identification data, the user also typically provides the data management system with account access and permissions credentials data for the disclosed accounts so that the data management system can access the user's account data contained in the disclosed user accounts. In many cases, the data management system uses the provided account access and permissions credentials data to access the disclosed accounts and then employs one of various available methods of data scraping to obtain the desired data contained in the disclosed accounts.
Despite the need for providing as complete a set of user accounts as possible to the account aggregating data management system, is often the case that one or more accounts associated with a given user are not disclosed to the account aggregating data management system. These “undisclosed,” or “unidentified,” user accounts exist for one of several reasons such as the user forgetting or otherwise omitting the inclusion of one or more user accounts in the set of disclosed user accounts provided to the account aggregating data management system, or the user opening, obtaining, or otherwise gaining access to, new user accounts and not identifying these new accounts to the account aggregating data management system.
Currently, based on the empirical data associated with existing users of account aggregating data management systems, it is estimated that between 22% and 46% of users of account aggregating data management systems have at least one undisclosed user account that should be disclosed to the account aggregating data management system.
This is a significant problem in the account aggregation and data management system fields because these undisclosed accounts may result in reports, features, advice, and data analysis that are incomplete because the complete set of account data required for accurate processing is not available to the data management system. This is particularly problematic in cases where the reports and features provided through the data management system are relied on by the users to make important decisions and to understand their current and future status.
What is needed is an effective, efficient, and accurate solution to the long-standing technical problem of identifying undisclosed accounts associated with users of account aggregation data management systems.
The systems and methods of the present disclosure provide a technical solution to the problem of identifying undisclosed user accounts by leveraging the test deposit mechanisms used by many financial institutions to link accounts between financial institutions.
Using the disclosed embodiments, when test deposit transactions are identified in a disclosed user account, it is determined highly likely that there is a potential undisclosed user account in existence. Consequently, once test deposit transactions are identified in a disclosed user account, the user of the data management system is asked about the existence of the undisclosed user account.
If the user confirms the existence of the undisclosed user account, the status of the undisclosed account is changed to newly identified user account and account data associated with the newly identified user account is obtained. The newly identified user account is then added to the list of disclosed user accounts with the data management system, i.e., the status of the newly identified user account is transformed to disclosed user account status.
As a result of these, and other features discussed in more detail below, the disclosed embodiments provide an extremely efficient, effective, and flexible technical solution to the technical problem of identifying undisclosed accounts associated with a user of a data management system.
As noted, the disclosed embodiments treat the existence of test deposits in a disclosed user account as a strong indication that there is a potential undisclosed user account. Test deposits are used by financial institutions, such as banks, when a user desires the link two user accounts with two separate financial institutions. Typically, the user desires to create a link between the two user accounts so that funds can be transferred between the two user accounts. However, the linking of two user accounts from different financial institutions is inherently subject to fraud or mistakes.
To address these risks, before allowing the user to link the two user accounts with two different financial institutions, a financial institution associated with the first of the two user accounts must ensure that the correct user account data for the second user account is being used and that the user has access to the transaction data in the second user account. The assumption is that if the user has the correct account information for the second user account and can access the transaction data in the second user account, then the user is legitimately associated with the second user account.
To this end, the financial institution associated a first of the two user accounts makes one or more small deposits in relatively rapid succession into the second user account associated with the second financial institution. Typically, two test deposits of less than one dollar each are made. Typically, the test deposits are made within a very short time of each other, often within minutes or seconds of each other, so that both test deposits can be readily found in a list of user transactions in the account data of the second user account.
Once the test deposits are made, the user is then asked to access the transaction data in the second user account and report back to the first financial institution the exact amount of the one or more small deposits. Using this test deposit mechanism, when the user reports back to the first financial institution the exact amount of the one or more small deposits, this is considered a confirmation that the correct second user account information has been obtained and that the user has access to the account data in the second user account. Therefore, the capability to successfully transfer funds between the two user accounts, and two financial institutions, is considered confirmed and user is determined to be legitimately associated with the second user account with the second financial institution.
The systems and methods of the present disclosure leverage this test deposit mechanism based on the assumption that the existence of test deposit transactions in a disclosed user account is a strong indication that an undisclosed user account has been opened and is being linked to the disclosed user account where the test deposits were made.
Using the disclosed embodiments, the test deposits are identified by obtaining transaction data from all the user accounts disclosed to a data management system used by the user. The transaction data is then scanned and analyzed to identify test deposit transactions listed in the transaction data.
Identifying test deposit transactions is typically a straightforward process because, as noted above, test deposit transactions are usually made in pairs, are of small amounts, smaller than a typical “real” transaction, and have very similar date and time values. The concurrence of these three factors in any real transaction is highly unlikely. Consequently, test deposits are readily recognized based on these standard transaction data features alone.
However, in addition, many test deposit transactions include text in the description field of the test deposit transactions indicating the transaction is a test deposit. In these cases, identifying a test deposit transaction is a trivial task. Further, some test deposit transactions also identify the financial institution sending the test deposit. In these cases, the identity of the financial institution associated with the test deposit transactions is also trivial. Therefore, identifying test deposit transactions in disclosed user account transaction data, and often identifying the financial institutions associated with the test deposits, can be performed efficiently, effectively, and accurately using standard data analysis and scanning techniques.
As noted above, using the disclosed embodiments, when test deposit transactions are identified in a disclosed user account, is determined highly likely that there is a potential undisclosed user account in existence. Consequently, once test deposit transactions are identified in a disclosed user account, the user of the data management system is queried regarding the existence of the undisclosed user account.
If the user confirms the existence of the undisclosed user account, the status of the undisclosed account is changed to newly identified user account and account data associated with the newly identified user account is obtained. The newly identified user account is then added to the list of disclosed user accounts with the data management system, i.e., the status of the newly identified user account is transformed to disclosed user account status.
Common reference numerals are used throughout the FIGs. and the detailed description to indicate like elements. One skilled in the art will readily recognize that the above FIGs. are merely illustrative examples and that other architectures, modes of operation, orders of operation, and elements/functions can be provided and implemented without departing from the characteristics and features of the invention, as set forth in the claims.
Embodiments will now be discussed with reference to the accompanying FIGs., which depict one or more exemplary embodiments. Embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein, shown in the FIGs., and/or described below. Rather, these exemplary embodiments are provided to allow a complete disclosure that conveys the principles of the invention, as set forth in the claims, to those of skill in the art.
The systems and methods of the present disclosure operate on the principle that the presence of test deposit transactions in a disclosed user account is a strong indication that a new, or undisclosed, user account exists. Using this fact, the disclosed embodiments scan user transaction data for the presence of test deposit transactions. If test deposit transactions are detected, it is determined to be highly likely that there is a potential undisclosed user account in existence. Consequently, once test deposit transactions are identified, the user of the data management system is asked about the existence of an undisclosed user account.
If the user confirms the existence of the undisclosed user account, the status of the undisclosed account is changed to newly identified user account and account data for the newly identified user account is obtained from the user. The newly identified user account is then added to the list of disclosed user accounts with the data management system.
As seen in
Service provider computing environment 101 includes data management system 111. In the specific illustrative example of
Data management system 111 includes user transaction database 112 including user transaction data 113. User transaction data 113 can be obtained from one or more transaction data sources including, but not limited to, one or more third-party financial institution computing systems 171 or 191, which represent “N” third-party financial institution computing systems associated with one or more third party financial institutions providing financial accounts to users of data management system 111. User transaction data 113 and financial institution computing systems 171, 181, through 191 are discussed in more detail below.
As noted, in the specific illustrative example of
In addition to providing account identification data, the user also typically provides the data management system 111 with disclosed account access and permissions credentials data that is then included in disclosed user account data 115. As discussed below, this allows the data management system 111 to access the user's account data contained in the disclosed user accounts of disclosed user account data 115. In many cases, as part of the data aggregation process, once data management system 111 uses the provided disclosed account access and permissions credentials data of disclosed user account data 115 to access the disclosed user accounts, the data management system then employs one of various available methods of data scraping to obtain the desired user account data contained in the disclosed user accounts of disclosed user account data 115.
Once the user provides disclosed user account data 115 to data management system 111, the account identification data and disclosed account access and permissions credentials data for the disclosed user accounts can be collected in a disclosed user account data portion of a user account table 131.
As seen in
Returning to
In the specific illustrative example of
Similarly, in the specific illustrative example of
Similarly, in the specific illustrative example of
In operation, the data management system 111 utilizes a data acquisition module 110 to retrieve user transaction data 113 related to the financial transactions of the users of the data management system 111. The data acquisition module 110 can be configured to use disclosed user account data 115 to acquire user transaction data 113 related to financial transactions of the users. In particular, the data acquisition module 110 uses the disclosed account access and permissions credentials data of disclosed user account data 115 to log into the online services of the disclosed user accounts of disclosed user account data 115 and provided through financial institution computing systems, such as financial institution computing systems 171 and 191 in
Once access to the disclosed user accounts, such as user accounts 172 and 192, of third-party financial institution computing systems, such as financial institution computing systems 171 and 191 in
The user transaction data 113 can include debit card transactions, credit card transactions, credit card balances, bank account deposits, bank account withdrawals, credit card payment transactions, online payment service transactions such as PayPal transactions or other online payment service transactions, loan payment transactions, investment account transactions, retirement account transactions, mortgage payment transactions, rent payment transactions, bill pay transactions, budgeting information, financial goal information, or any other types of financial data. The user transaction data 113 can also include data related to withdrawals, deposits, and balances in the bank accounts of users.
The user transaction data 113 can include, for each financial transaction represented in user transaction data 113, one or more of: time stamp data corresponding to a time stamp that indicates the date and time of the financial transaction; location data representing the location of the transaction; amount data representing the amount of the transaction; and payee data representing the merchant or payee associated with the transaction. In addition, user transaction data 113 can include, for each financial transaction, description data indicating the items purchased or transaction category assigned to the transaction.
It is important to note that data acquisition module 110 and disclosed user account data 115 can only be used to access and acquire account data from disclosed user accounts made known to the data management system via disclosed user account data 115. Consequently, user transaction data 113 only includes transaction data from the disclosed user accounts of disclosed user account data 115.
It follows that, in the specific illustrative example of
As discussed above, to provide users of an account aggregating data management system, such as data management system 111, accurate analysis and recommendations, it is important that data management system 111 obtain as complete a set of the users' account data as possible, i.e., that the set of account and transaction data included in user transaction data 113 be as complete as possible. If data management system 111 is not provided a complete set of the users' account and transaction data included in user transaction data 113, then the analysis and recommendations provided to the users may be incorrect or, at best, be based on incomplete input data. It follows that, in the specific illustrative example of
Since the user's account and transaction data included in user transaction data 113 can only be obtained from the disclosed user accounts of disclosed user account data 115, it follows that obtaining a complete set of user account and transaction data requires the identification of a complete set of user accounts in disclosed user account data 115.
In short, the quality of the various reports, visualizations, and recommendations generated and provided by data management system 111 is directly proportional to the percentage of the total number of user accounts that are disclosed to the data management system 111 via disclosed user account data 115. Consequently, it is important that disclosed user account data 115 include a set of disclosed accounts associated with a user that is as complete possible.
However, as also discussed above, despite the need for providing as complete a set of user accounts in disclosed user account data 115 as possible, it is often the case that one or more accounts associated with a given user, such as account 182 in
To address this issue, the systems and methods of the present disclosure leverage the test deposit mechanisms used by many financial institutions to detect potential undisclosed user accounts, such as account 182, that are not listed in disclosed user account data 115.
As noted above, test deposits are used by financial institutions when a user desires to link two user accounts provided by two separate financial institutions to address security risks, before allowing the user to link the two user accounts provided by two different financial institutions. Using the test deposit mechanism, the financial institution associated a first of the two user accounts makes one or more small deposits in relatively rapid succession into the second user account associated with the second financial institution. Typically, two test deposits of less than one dollar each are made. Typically, the test deposits are made within a very short time of each other, often within minutes or seconds of each other, so that both test deposits can be readily found in a set of user transactions in the account data of the second user account.
Once the test deposits are made, the user is then asked to access the transaction data in the second user account and report back to the first financial institution the exact amount of the one or more small deposits. If the user reports back the exact amount of the small deposits, this is considered a confirmation that the capability to successfully transfer funds between the two user accounts exists and the user is legitimately associated with the second user account.
Returning to
Using the test deposit mechanism described above, before linking the accounts, second financial institution transmitted test deposit transaction data 185 representing test deposit transactions, typically two test deposits, from second financial institution computing system 181 to first financial institution computing system 171 and first financial institution disclosed user account 172. As a result of the transfer of the test deposits represented in test deposit transaction data 185 being transferred to first financial institution disclosed user account 172, test deposit transaction data 185 will be included in the transaction data of disclosed user account data 173 of the first financial institution disclosed user account 172. In accordance with the embodiments discussed herein, it is the presence of this test deposit transaction data 185 in the transaction data of disclosed user account data 173 of the disclosed first financial institution account 172 that is to identify the existence of undisclosed user account 182, and in some cases the identity of the second financial institution.
To this end, using the disclosed embodiments, when data management system 111 utilizes data acquisition module 110 to retrieve user transaction data 113, data acquisition module 110 uses disclosed user account data 115 to access all of the disclosed user accounts in disclosed user account data 115, which includes the disclosed user account data 173 of disclosed user account 172 in first financial institution computing system 171. Even through data acquisition module 110 still cannot access undisclosed user account 182, and undisclosed user account data 183, by accessing and obtaining disclosed user account data 173 of disclosed user account 172, data acquisition module 110 obtains test deposit transaction data 185 representing the test deposit transactions from the second financial institution to disclosed user account 172. Consequently, user transaction data 113 will also include test deposit transaction data 185.
According to the disclosed embodiments, user transaction data 113, including test deposit transaction data 185, is provided to test deposit detection module 123 of undisclosed user account detection module 121. Test deposit detection module 123 uses a detection process 300 to analyze user transaction data 113 and identify test deposit transaction data, such as test deposit transaction data 185, in user transaction data 113.
As seen in
As seen in
Typically, user transaction data 113 can include numerous formats, abbreviations and greater or fewer types of transaction data. Consequently, user transaction data 113 must typically undergo some form of formatting, such as any formatting known in the art, to generate consistent structured data for all user transactions.
In addition, those of skill in the art will readily recognize that the various types of data shown in the specific illustrative example of
Of note in
Given the features typically associated with test deposit transactions, such as those shown in
In n addition, many test deposit transactions, such as those shown in rows 405 and 407 of
Further, some test deposit transactions, such as those shown in rows 405 and 407 of
Returning to
However, if text in the description data associated with the transactions represented in user transaction data 113 indicating the transaction is a test deposit is not identified, process 300 proceeds to operations 303, 305, and 307. In this case, all three requirements of operations 303, 305, and 307 must be met, e.g., a yes (Y) response must be generated, for transactions to be confirmed as detected test transactions at confirmed detected test deposit transaction 321.
As noted above, test deposit transactions typically have transaction data features that are unique to test deposits transactions and are readily identified when all these features are present. These test deposit account features include: a pair of deposit transactions to the same disclosed user account; both transactions occurring within a short time of each other, often within minutes or seconds of each other; and both transactions having very small transaction amounts, typically less than a US dollar, and often only a few cents. According to the disclosed embodiments, this fact is used by test deposit detection module 123 and detection process 300 to identify test deposit transactions in user transaction data 113.
To this end, at pair of transactions? 303, user transaction data 113 is analyzed to identify pairs of deposit, or debit, transactions into the same disclosed user account, with the attributes discussed above and scanned for at operations 305 and 307.
As a specific illustrative example, the pair of transactions shown in rows 405 and 407 of
At within defined time window? 305, pairs of deposit transactions from pair of transactions? 303 having dates and times within a defined time window are identified. As noted above, test deposit transactions are typically sent within a very small-time frame, such as minute or seconds. Consequently, the defined time window can be seconds, minutes, an hour, or even a day, but typically not a window greater than a day.
As a specific illustrative example, pairs of debit transactions, such as those shown in rows 405 and 407 of
At amount less than threshold? 307, pairs of transactions from within defined time window? 305 are analyzed to determine if both transactions have amounts less than a defined threshold amount. As noted above, test deposit transactions typically have very small transaction amounts, typically less than would be practical for a real transaction. Consequently, defined threshold amount can be a US dollar, or even a fraction of a US dollar.
As a specific illustrative example, pairs of debit transactions, such as those shown in rows 405 and 407 of
Consequently, the only transactions confirmed as test deposits at confirmed detected test deposit transaction 321 are those transactions that either include text in the description data associated with the transactions indicating the transaction is a test deposit, or that: are pairs of deposit, or debit, transactions into the same disclosed user account; have dates and times within a defined time window; and are less than a defined threshold transaction amount. All other transactions in user transaction data 113 are determined not to be test deposit transactions and are filtered out at not test deposit 309.
Those transactions in user transaction data 113 identified and forwarded to confirmed detected test deposit transaction 321 are then considered indicative of the potential existence of an undisclosed user account and, at determined potential existence of an undisclosed user account 323, account data is collected including all the data currently known about the potential undisclosed account.
The account data associated with the undisclosed account typically includes at least the account ID for the disclosed user account receiving the test deposit transactions, such as account ID data from column 421 in
However, as also noted above, some test deposit transactions also include data that identifies the financial institution sending the test deposit, such source FI data in column 431 in
Once generated, potential undisclosed user account data 125 is used to add the potential undisclosed user account identified by virtue of detecting test deposit transaction data 185 to user account table 131.
Referring to
Returning to
Referring to
At potential undisclosed user account alert data generation module 601 potential undisclosed user account alert data 603 is generated that represents one or more potential undisclosed user account alerts to be provided to the user of the data management system. The one or more potential undisclosed user account alerts can include information alerting the user to each transaction in user account table 131 having a status of “undisclosed.” The one or more potential undisclosed user account alerts also include a request that the user confirm the existence of each transaction in user account table 131 having a status of “undisclosed,” and provide account data for each transaction in user account table 131 having a status of “undisclosed,” confirmed by the user to exist.
As seen in
As seen in
In addition, in this specific illustrative example, potential undisclosed account entries 713 and 715 include reason or source data indicating how the potential undisclosed account entry was identified, in this case by test deposit detection. It is also worth noting that while potential undisclosed account entry 713 includes financial institution identification data, i.e., Wells Fargo, the financial institution associated with potential undisclosed account entry 715 is unknown. This indicates that test deposit transaction data associated with potential undisclosed account entry 713 included description data indicating the financial institution sending the test deposit transaction data, while the test deposit transaction data associated with potential undisclosed account entry 715 did not.
In addition, in this specific illustrative example, confirm buttons are included with undisclosed account entry 713 and undisclosed account entry 715. Confirm buttons can be used by the user to easily confirm the existence of the undisclosed accounts of potential undisclosed account entry 713 or potential undisclosed account entry 715.
Also shown in specific illustrative example is text 717 reminding the user to provide newly identified user account data for any confirmed potential undisclosed account entry and a link 719 to the interface page provided by data management system 111 where newly identified user account data can be entered.
Returning to
The newly identified user account data 611 can include the same data the user provided for other disclosed accounts in disclosed user account data 115, e.g., the newly identified user account number, the financial institution providing the newly identified user account, the newly identified user account type, the user ID for accessing the newly identified user account, and the password for accessing the newly identified user account.
In addition, if the user confirms the existence of the undisclosed user account of potential undisclosed user account data 125 indicated in the potential undisclosed user account alert, newly identified user account data 611 is provided to user accounts status update module 613 where the status of the undisclosed user account of potential undisclosed user account data 125, now newly identified user account data 611, is transformed to a status of disclosed user account.
Once the newly identified user account data 611 is obtained by user accounts status update module 613, the newly identified user account data 611 is added to the set of disclosed user accounts with the data management system, i.e., the newly identified user account is transformed into a disclosed user account and is added to disclosed user account data 115 and user account table 131 as a disclosed user account.
Referring to
Returning to
Referring to
At operation 903 a data management system such as any of the data management systems discussed herein with respect to
Once a data management system is provided at operation 903, process flow proceeds to operation 905.
At operation 905 disclosed user account data representing a set of disclosed user accounts associated with a user of the data management system is received. The disclosed user account data can be any type of disclosed user account data, including that shown and discussed with respect to
Once disclosed user account data representing a set of disclosed user accounts associated with a user of the data management system is received at operation 905, process flow proceeds to operation 907
At operation 907, access is obtained to user transaction data associated with one or more of the disclosed user accounts in the disclosed user account data of operation 905. The user transaction data is user transaction data such as discussed herein with respect to
Once access is obtained to user transaction data associated with one or more of the disclosed user accounts in the disclosed user account data at operation 907, process flow proceeds to operation 909.
At operation 909 the user transaction data of operation 907 is analyzed/processed to identify a test deposit transaction in the user transaction data using any of the methods of processes discussed herein, including those discussed with respect to
Once the user transaction data is analyzed/processed to identify a test deposit transaction in the user transaction data at operation 909, process flow proceeds to detect a test deposit transaction in the user transaction data operation 911.
At operation 911, as a result of the analysis/process performed at operation 909, one or more test deposit transactions are detected in the user transaction data of operation 907 using any of the methods of processes discussed herein, including those discussed with respect to
Once one or more test deposit transactions are detected in the user transaction data at operation 911, process flow proceeds to operation 913.
At operation 913 the potential existence of an undisclosed user account is determined based on the detection of the test deposit transaction in the user transaction data at operation 911 using any of the methods of processes discussed herein, including those discussed with respect to
Once the potential existence of an undisclosed user account is determined based on the detection of the test deposit transaction in the user transaction data at operation 913, process flow proceeds to operation 915.
At operation 915, data representing a potential undisclosed account alert is generated and the potential undisclosed account alert is provided to the user. The potential undisclosed account alert requests the user confirm the existence of the undisclosed user account associated with the detection of the test deposit transaction and this response is processed using any of the methods and systems discussed herein, including the methods and systems discussed with respect to
Once the potential undisclosed account query alert is provided to the user at operation 915, process flow proceeds to operation 917.
At operation 917 the user confirms the existence of the undisclosed user account using any of the methods and systems discussed herein, including the methods and systems discussed with respect to
Once the user confirms the existence of the undisclosed user account at operation 917, process flow proceeds to operation 919.
At operation 919 the undisclosed user account is designated a newly identified user account, and account data associated with the newly identified user account is obtained and added to the disclosed user account data using any of the methods and systems discussed herein, including the methods and systems discussed with respect to
Once the newly identified user account is obtained and added to the disclosed user account data at operation 919, process flow proceeds to end operation 920 and process 900 is exited to await new data.
In the discussion above, certain aspects of one embodiment include process steps and/or operations and/or instructions described herein for illustrative purposes in a specific order and/or grouping. However, the specific order and/or grouping shown and discussed herein are illustrative only and not limiting. Those of skill in the art will recognize that other orders and/or grouping of the process steps and/or operations and/or instructions are possible and, in some embodiments, one or more of the process steps and/or operations and/or instructions discussed above can be combined and/or deleted. In addition, portions of one or more of the process steps and/or operations and/or instructions can be re-grouped as portions of one or more other of the process steps and/or operations and/or instructions discussed herein. Consequently, the specific order and/or grouping of the process steps and/or operations and/or instructions discussed herein do not limit the scope of the invention as claimed below.
As discussed in more detail above, using the above embodiments, with little or no modification and/or input, there is considerable flexibility, adaptability, and opportunity for customization to meet the specific needs of various users under numerous circumstances.
The present invention has been described in particular detail with respect to specific possible embodiments. Those of skill in the art will appreciate that the invention may be practiced in other embodiments. For example, the nomenclature used for components, capitalization of component designations and terms, the attributes, data structures, or any other programming or structural aspect is not significant, mandatory, or limiting, and the mechanisms that implement the invention or its features can have various different names, formats, or protocols. Further, the system or functionality of the invention may be implemented via various combinations of software and hardware, as described, or entirely in hardware elements. Also, particular divisions of functionality between the various components described herein are merely exemplary, and not mandatory or significant. Consequently, functions performed by a single component may, in other embodiments, be performed by multiple components, and functions performed by multiple components may, in other embodiments, be performed by a single component.
Some portions of the above description present the features of the present invention in terms of algorithms and symbolic representations of operations, or algorithm-like representations, of operations on information/data. These algorithmic or algorithm-like descriptions and representations are the means used by those of skill in the art to most effectively and efficiently convey the substance of their work to others of skill in the art. These operations, while described functionally or logically, are understood to be implemented by computer programs or computing systems. Furthermore, it has also proven convenient at times to refer to these arrangements of operations as steps or modules or by functional names, without loss of generality.
In addition, the operations shown in the FIGs., or as discussed herein, are identified using a particular nomenclature for ease of description and understanding, but other nomenclature is often used in the art to identify equivalent operations.
Therefore, numerous variations, whether explicitly provided for by the specification or implied by the specification or not, may be implemented by one of skill in the art in view of this disclosure.
