Patent Application
20230161750
The invention relates to the field of data and database management. More specifically, the present invention discloses systems and methods for securely storing data elements about individual records on behalf of multiple parties, validating updated entries where possible, and sharing element level calculated most likely accurate values back to those who contribute to the same elements.
Database management systems allow users to store data securely as well as to modify and/or retrieve their stored data. In cases where multiple, disparate parties utilize a common database, the data of these parties is separated for data integrity and security. There is value, however, in connecting and analyzing the various data being stored by these parties. In many cases, one party may get an update on a specific record or data element before other parties are aware of the update. Rather than having to partner with outside companies to share data, it is desired that parties should be able to connect their database to a third-party service who securely stores the data of each party while programmatically adding value through analysis of the various contributed data and sharing of guidance based on its findings rather than directly sharing data submitted by each party.
The system of the present invention allows parties to submit their records, and the elements making up those records, to a centralized data repository to which they have access and can submit, store, query, retrieve, update, overwrite, or delete their own values for any element at any time using web services or other connection methods. Users of the system are likely to engage through common communication channels including, but not limited to, cell phones, personal computers, tablets, etc. Records are aligned within the system and allow comparison of data elements submitted by various users. The party provides authorization or refusal to contribute their data to the system of the present invention for further analysis.
Data elements not specifically flagged as contributed are stored on behalf of the submitting party and are not analyzed or shared with other parties. Submissions of new or updated data from users for a contributed element cause an analysis of recent validation and subsequently starts a validation process where possible or necessary. Simultaneously, these data submissions begin an algorithmic calculation to determine the value most likely to be accurate at any time for the contributed element. The calculated data is shared with the contributing party with the option for them to retrieve the calculated value and/or their own stored value.
In contrast, partners 102, 106, and 108 enabled their stored data to be shared with SE value algorithm 112. By allowing access to their stored data for analysis, partners 102, 106, and 108 are provided with the ability to retrieve the SE value or the stored value. Each partner 102, 106, and 108 can decide the amount and level of data shared with SE value algorithm 112. For example, partner 102 may allow SE value algorithm 112 access to all stored data whereas partner 106 may only allow access to certain stored fields, while restricting access to other fields. The permissions to the stored data granted by each partner 102-108 is stored in SE database 110. The permissions to the stored data can also be updated at any time. For example, partner 102 can elect to become a contributing partner at a first date and later revoke that permission at a second later date.
Every time new shared data is contributed by partners 102, 106, and 108, SE value algorithm 112 analyzes the new contributions and updates the SE value if necessary. This provides the partners 102, 106, and 108 access to the most recent sureEcosystem values, resulting in the constant availability of a specific data point's most likely current value.
SE database 110 further stores the data contributed to SE 100 by each contributing or non-contributing partner in association with the partner profile. As changes are made to the data stored for each partner 102-108, a record is kept of the value for each stored field of data for record keeping purposes. This historical data is utilized by SE value algorithm 112 to calculate the SE value for each field of data as will be described later.
Once data has been collected from at least one partner, SE value algorithm 112 calculates an initial SE value for each field possible. Then, as updated data is received over time, the SE value is reevaluated and shared with partners 102, 106, and 108.
The arrows from SE database 110 to partners 102-108 represent the ability to retrieve the partner's own data RO value (dashed black line) or the current SE value. Partner 104, as a non-contributing partner, does not have the ability to retrieve the SE value.
Referring first to
At decision step 306, it is determined if the specific field is a contributing field or a non-contributing field. As previously discussed, each contributing partner 102, 106, and 108 can decide on a field-by-field basis which field types of each record are contributed or not contributed. For partner 104, all of the field types would be marked as not contributed. If a CEV is determined to be not contributed, the SE database is updated and the process is terminated at step 308. If the CEV is determined to be an entry in a contributed field type, it is next determined if a record owner value (ROV) already exists in that field at step 310. If there is no current entry for the CEV, a confirmation (email, alert, etc.) is sent to the RO to validate the CEV at step 312. A confirmation may be sent to the record owner for each CEV or they may be grouped into a single alert and sent periodically (e.g., once a day, after 100 CEVs, etc.). In a preferred embodiment, the CEV must be verified within a set period of time, after which the alert is deleted.
At decision step 314, the RO approves or rejects each CEV. If the CEV is rejected in step 316, the RO is directed to initiate contact with SE 100 to update their profile. If the CEV is approved in step 318, the ROV is updated with the CEV to match the approved value. The CEV is then used to execute SE value algorithm 112 in step 320.
Returning to decision step 310, if the ROV value already exists for the CEV, it is determined in decision step 322 if the current REV matches the CEV. If no, the process proceeds to step 312 already described. If the current REV matches the CEV, a data validation process begins in step 324 (e.g., spell check, etc.) Formatting can be modified by the system here to meet the requirements of data normalization for each specific field. Examples of this normalization include formatting such as a phone number entry being 10 digits without punctuation, converting all email addresses to lower case only and ensuring they meet email structure requirements (i.e.: contain an ‘@’ and a period at some point at least two characters after the ‘@’ plus some combination or at least two characters after the period where the characters after the period are part of a master top level domain (TLD) list maintained within sureEcosystem.), converting web addresses (URLs) to a single standard layout without the use of www, and location addresses where adjustments are made to ensure compliance with USPS guidelines for United States addresses. After data validation, SE value algorithm 112 is executed in step 320 for the CEV.
The validation status of each CEV is then used to weight the gathered CEVs in step 328. In a preferred embodiment, pending CEVs are assigned a weight of 1, validated CEVs are assigned a weight of 1.25, and rejected CEVs are assigned a weight of 0.5. In some embodiments, certain partners may be considered “trusted partners” by SE 100. The trusted status can be acquired in a number of ways. For example, if the SE value is the same as the RO value for a partner above a certain threshold percent, that partner may become a trusted partner. In the same way, partners can be demoted from being a trusted partner if their CEVs become unreliable. In a preferred embodiment, Trusted Partner values receive an additional weight of a 1.25 multiple against each status weight.
It should be obvious to one of ordinary skill in the art that the weights for validated CEVs, rejected CEVs, and trusted partners can be automatically calculated by SE value algorithm 112 or set manually by a system administrator when specific, static values are required. Preferably the weight for validated CEVs is >1, the weight for rejected CEVs is <1, and the weight for trusted partners is >1. These values may also be adjusted globally or on a partner-by partner basis if desired.
In step 330, the normalized values are assigned weights and their weighted value is summed to determine a comparison value for each normalized CEV. The comparison values are then compared to determine the best represented values (BRVs) which are comparison values above a predefined threshold.
In decision step 334, it is determined if more than one unique comparison value exists in the BRV. If only a single BRV exists, it is then determined if a ROV already exists in step 336. If no ROV exists, the BRV is set to be the new SE value and the previous SE value is stored in step 338 for backup and posterity.
If there is more than one BRV as determined in step 334, it is next determined if a ROV exists in step 337. If the record owner does exist, the process proceeds to decision step 340. Similarly, if it is determined that a ROV exists in step 336, the process proceeds to decision step 340. In step 340, it is determined if the ROV is the same as any of the values in the BRV. If the ROV is the same as a BRV, the SE value is set to be the ROV and the previous SE value is stored in step 342.
If the ROV is not the same as any of the BRV, the process proceeds to decision step 344. Decision step 344 is also executed if it is determined that no ROV exists in step 337. In step 344, it is determined if the CEV (received in step 302) is the same as any of the BRV. If yes, the CEV is set to be the SE value in step 346 and the previous SE value is stored.
When partners add values to the system, and sureEcosytem values are calculated along with other necessary activities, the system also evaluates and stores information regarding whether or not the value submitted by the partner is, in fact, equal to the resulting sureEcosystem Value or that the sureEcosystem Value becomes equal to the partner submitted value within a specified period of time or within a specified number of record saves. When the partner reaches a volume threshold related to the amount of submitted data, and when their submissions are commonly the current, resulting, or near future sureEcosystem Value, as evaluated by the system, they are eligible for Trusted Partner status which may be offered, evaluated, and accepted either inside the system as a general notification followed by partner evaluation with resulting acceptance or rejection, or it can be done manually by the system administrator.
If the CEV is not the same as any of the BRV, a search is performed to determine the BRV with the most recent update (MRU) date in step 348. In decision step 350, it is determined if the BRV from step 348 is from a trusted partner. If the BRV from step 348 is from a trusted partner as determined in step 350, it becomes the new SE value and the previous SE value is stored in step 352.
If the BRV from step 348 is not from a trusted partner, a search is then performed for the BRV with the second most recent update (2MR) date in step 354. In decision step 356 it is determined if the 2MR BRV is from a trusted partner. If the 2MR BRV is not from a trusted partner, the SE value is not updated in step 358. If the 2MR BRV is from a trusted partner, the 2MR BRV is set to be the SE value in step 360.
The process described with respect to steps 320-360 occurs every time a new CEV is received from any partner. This allows the SE value to be up to date and reliably accurate for use by contributing partners.
The data stored in SE database 110 is preferably assigned a contributed or not contributed flag, such that the stored data can be grouped into contributed data 406 and non-contributed data 408. As previously discussed with respect to
Similar to public facing tools 402 and 404, partners may also be provided with partner facing tools 410 or have integrated management systems 412 which replicate some abilities of 402 and 404, respectively alongside additional management functions for the Partner. Partner administration tool 410 and partner update tool 412 are not accessible from outside sources other than 404
SE 100 provides the following advantage over other prior art systems:
This application claims priority to U.S. Provisional Application Ser. No. 63/060,879, filed Aug. 4, 2020, the entire contents of which are hereby incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63060879 | Aug 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17388685 | Jul 2021 | US |
| Child | 18093503 | US |
