HK1242439B - One way and two way data flow systems and methods - Google Patents

Description

Unidirectional and bidirectional data flow systems and methods

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 62/060,440, filed on October 6, 2014, which is incorporated herein by reference in its entirety.

Technical Field

The present invention relates to a unidirectional and bidirectional data flow system and method.

Background Art

In the prior art, it is known to provide a user profile that can include detailed information about a user. For example, U.S. Patent Application Publication No. 2011/0238482 describes a digital profile for a user that collects, stores, and updates information about the user's attributes in a personal genome database that communicates with the user's computer. However, the prior art typically provides user profiles that are similarly accessible to anyone with credentials to view the user profile. For example, the personal genome of U.S. Patent Application Publication No. 2011/0238482 is accessible to anyone with credentials linked to the personal genome, but not to anyone else. The prior art lacks the ability to generate a personal genome and/or other profile information that can be accessed only by the person described in the profile, as well as separate personal genome and/or other profile information that can be accessed by that person and other authorized users through different trusted access permissions.

The unidirectional and bidirectional data flow systems described herein are able to provide such separate records, thereby allowing people to control data confidentiality while still sharing certain data as they see fit.

Summary of the Invention

The systems and methods described herein can provide a comprehensive, universally accessible digital profile system that securely captures, organizes, stores, and distributes detailed information about participating users, including, in some embodiments, personal and/or sensitive information. The systems and methods described herein can provide authorized third-party applications with access to multiple portions of a user's information when needed, while still preserving the user's privacy. The systems and methods described herein can be dynamic and automatically scalable, allowing nearly any type of data to be captured and subsequently aggregated to accommodate the user's permissions and/or privacy settings.

For example, some embodiments may provide features such as the following. The described systems and methods may receive a value for an attribute of a user having an account with the access-controlled service. The described systems and methods may determine whether the value is derived from an assessment initiated by an organization associated with the user, wherein the organization has at least one account with the access-controlled service. When the value is derived from the assessment initiated by the organization associated with the user, the described systems and methods may store the received value in a record in the database that is associated only with the user and is not accessible through the at least one account of the organization, and store the received value in a separate record associated with the organization and the user, wherein access to the separate record by third parties is controlled by the user. When the value is derived from a source different from the assessment initiated by the organization associated with the user, the described systems and methods may store the received value in the record in the database that is associated only with the user. The described systems and methods may determine whether the attribute is associated with a predictive model. In response to determining that the attribute is associated with the predictive model, the systems and methods described herein may execute the predictive model associated with the attribute using the received value to generate a predicted value using the score and confidence factor of the attribute. When the value is derived from the assessment initiated by the organization associated with the user, the systems and methods described herein may store the predicted value in the record associated only with the user in the database and in the record associated with the organization and the user. When the value is derived from the assessment not initiated by the organization associated with the user, the systems and methods described herein may store the predicted value in the record associated only with the user in the database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system according to an embodiment of the present invention.

FIG2 is a block diagram of an analysis process according to an embodiment of the present invention.

FIG3 is an example of an analysis model process according to an embodiment of the present invention.

4A and 4B are flow charts illustrating a process for registering a new assessment tool according to an embodiment of the present invention.

FIG. 5A illustrates a unidirectional data flow according to an embodiment of the present invention.

FIG. 5B illustrates bidirectional data flow according to an embodiment of the present invention.

FIG6 is a flow chart illustrating a process for storing data using a unidirectional data flow according to an embodiment of the present invention.

FIG7 is a flowchart illustrating a process for permission setting with risk tolerance assessment according to an embodiment of the present invention.

FIG8 is a flowchart illustrating a process for reflecting data on an organizational view according to an embodiment of the present invention.

FIG. 9 is a block diagram illustrating permission setting control data sharing according to an embodiment of the present invention.

DETAILED DESCRIPTION

The systems and methods described herein can provide a comprehensive, universally accessible digital profile system that securely captures, organizes, stores, and distributes detailed information about participating users. The system can form a detailed, centralized user model that describes a wide variety of personal attributes for each participating user, such as demographics, physical characteristics, personality traits, interests, attitudes, qualifications, skills, professional competencies, activities, recommended actions, and historical events. The system can provide authorized third-party applications with access to multiple portions of a user's information when needed, while still preserving the user's privacy. The system can be dynamic and automatically scalable, so that virtually any type of data can be captured and later aggregated to suit the user's permissions and/or privacy settings.

Authorized third-party data users or third-party applications can access user data (e.g., through a cryptographic scheme), but users maintain control over their own data and can set up multiple layers of privacy filters that automatically aggregate or mask their data before releasing it to specific third-party data users. Users can opt in or out of data-sharing opportunities, as needed. Each user can have a unique private identifier, similar to how a hardware device receives a unique IP address linked to its stored data. Third parties do not have access to a user's private identifier, but they may still have access to various portions of the user's data. A unique intermediary cryptographic system can decrypt the private identifier and generate a temporary password that briefly links the various portions of the user's data to the requesting third-party application. When the third-party application's transaction is complete (e.g., the third-party application has received and/or submitted the data), the temporary password can be invalidated, removing the third-party application's access to the user's data. Because third-party applications remain unaware of the user's private identifier and can access data only through a specialized intermediary cryptographic system, the system can control when and what data can be accessed.

In addition, the original application that captures the data can have the ability to utilize the data captured from other applications in order to better customize the experience of each user using the data. Although having this data is valuable, it may be difficult for the application to derive it by itself. For example, many applications can greatly benefit from knowing what the user's English reading level is at the beginning of an application session. However, application developers may not have the industry knowledge and expertise to create their own effective reading level assessments. In addition, whenever a user starts a new application, the user may not understand that a reading level assessment is required. A small number of reading experts can instead develop a sound, research-based reading level assessment tool that can be used to assess the user's reading level once (or periodically, perhaps every 6 months). The results of this reading assessment can then be stored in the user's personal attribute record and shared with other user-trusted applications that can utilize reading level data, without having to know exactly how the reading assessment determines the reading level. In this way, each application can know the user's reading level at the beginning of each session and adapt to the presentation of text information accordingly.

According to some embodiments of the present invention, a password mapping (e.g., between a user identifier and a temporary password) coupled with data privacy and aggregation tools can provide a tangible, commercially viable, and reliable source of detailed user profile information that provides personal data owners with choices about when and how to share their own data. Additionally, third-party applications can also be providers of data, thereby allowing the underlying user model to continue to grow with usage. As the data grows, the accuracy of the data contained within the model can continue to increase in overall accuracy. User profile data can be managed using one-way data gates and optional two-way gates that can allow such data to be captured, stored, and utilized to achieve the described user benefits while protecting the user's true identity and privacy, and while also ensuring that applications and organizations that have invested in the user can still access the data they capture.

The systems and methods described herein may include one or more computers, which may also be referred to as processors. A computer may be any one or more programmable machines capable of performing arithmetic and/or logical operations. In some embodiments, a computer may include a processor, memory, data storage device, and/or other known or novel components. These components may be connected physically or via a network or wireless link. The computer may also include software that directs the operation of the aforementioned components. Computers may be referred to by terms commonly used by those skilled in the art, such as server, PC, mobile device, router, switch, data center, distributed computer, and other terms. A computer may facilitate communication between multiple users and/or other computers, provide a database, perform data analysis and/or conversion, and/or perform other functions. It will be understood by those skilled in the art that the terms used herein are interchangeable, and any computer capable of performing the described functions may be used. For example, although the term "server" may appear in the following description, the disclosed embodiments are not limited to servers.

Computers can be linked to each other via one or more networks. A network can be any number of fully or partially interconnected computers, wherein some or all of the computers are capable of communicating with each other. It will be understood by those of ordinary skill that the connection between computers can be wired (e.g., via Ethernet, coaxial, optical, or other wired connections) or can be wireless (e.g., via Wi-Fi, WiMax, or other wireless connections) in some cases. The connection between computers can use any protocol, including connection-oriented protocols (such as TCP) or connectionless protocols (such as UDP). Any connection through which at least two computers can exchange data can be the basis of a network.

Configuring the File System

FIG1 illustrates the relationships between the components of a digital profiling system 10 according to an embodiment of the present invention. System 10 allows users to connect to various applications, which may be hosted on a server 15 within a data analysis platform 16 or externally on a third-party server 14. Users can connect to these applications using virtually any device 12 they desire. For example, a computer such as a desktop PC, laptop, smartphone, tablet, etc. may be used. Users may have a profile containing personal data. When launching an application, these applications may request a portion of the user's personal profile to customize the user experience to suit, for example, each specific user's preferences, inclinations, and learning style.

In some embodiments, user profiles 17 (also referred to herein as "user models") may be the central data management component of system 10. User models 17 may serve as a secure repository for storing information about all aspects of a user's skills, knowledge, personality, demographics, interests, aptitudes, attitudes, and behaviors (collectively, personal attributes). One or more user model servers 17 may manage user data, while one or more personal attribute (PA) directory servers 18 and data storage servers 19 may control database files containing various portions of user data.

To retrieve user data, an application may first obtain access to a temporary password that can be used to identify the user for a short period of time without actually letting the application know who the user actually is. In the case of an application 15 that can be hosted within a platform 16, a user profile processor 17 may automatically generate a temporary password and send the password to the application 15 during the application startup sequence. The application may use the password to access a portion of the user's personal profile data.

In the case of an application that can be launched from a third-party server 14 external to the platform 16, the application can request a temporary password by redirecting the user to a function within the user model 17 that allows the user to log into the platform 16 and then passing the temporary password back to the application 14. Once the application 14 receives the temporary password, it can use it to retrieve a portion of the user's digital profile. The temporary password can also be used when the application 14 wishes to store new observations about the user in the user's personal profile (user model) 17. Data received from the application can be stored in one of the data stores 19 based on location information managed by the PA directory server 18.

The user model server 17 can be responsible for handling activities related to managing a user model that approximates the actual user by maintaining many individual PAs that describe many aspects of the user. For security reasons, the individual PAs can be spread across multiple data stores on different physical servers 19, and the individual PAs can be identified by non-descriptively coded identifiers. For example, the identifier can have the form of 16 alphanumeric characters divided into four groups of four characters. In this way, the identifier can look similar to a traditional Internet Protocol (IP) address. There may be no predictable pattern that identifies which server contains which PA. Instead, the central PA directory server 18 can maintain contact with the data store 19 that actually contains each PA.

Using this approach, the security and privacy of user data can be ensured because the data store 19 can contain only a list of encoded user IDs and encoded PA IDs. In the event of any type of malicious activity against the data store 19, only the numeric data without descriptive context will be available. The PA directory server 18 may only know the PA's name as a set of encoded identifiers (e.g., a 16-character string) and a pointer to the individual data store 19. The user model server 17 may only hold user data for a very short period of time because data is sequentially entered and exited from the data store 19 by the PA directory server 18. Therefore, there may generally be no permanent information in the user model server 18 that could be used by a potential intruder.

Registering an application

Figures 4A and 4B illustrate the process for registering a new application 14. As described above, applications 14 and 15 can be used to extend and update user model 17. New applications 14 and 15 can be registered within system 10 to describe the type of attributes being assessed and to merge the assessment and observation results with existing or new personal attributes. Once an application is registered, the assessment results can be stored in any user's personal user model 17, and third-party applications 14 can immediately begin using the new attribute information.

The registration process may begin at 104 when a third-party application 14 or its associated vendor contacts the vendor support website operated by system 10. In some embodiments, all vendors must have a registered vendor ID to participate in system 10. This vendor ID can be used to provide context to user 11 and can be associated with vendor-specific privacy and aggregation filtering rules, with the user 11 wishing to control which vendors can see their personal attribute data. At 106, system 10 may determine whether the vendor has a vendor ID. If the vendor does not already have a vendor ID, at 108, the vendor ID may be requested, for example, by completing a vendor application form on the vendor support website operated by system 10. At 110, a system administrator may review the vendor's request for completeness and acceptability. The system administrator may accept the vendor's request as is, return it for further information or clarification, or immediately deny the request. If the vendor's request is accepted, as determined at 112, a unique vendor ID may be issued and stored in the system's user model processor 17 at 114. A vendor ID may be submitted along with each data request so that the system 10 can confirm that the requesting vendor remains active and so that the user's privacy filters can adequately control the type of data presented to the vendor.

The supplier may complete and submit the new assessment form at 116. Each individual assessment may be individually qualified so that the system 10 can determine how relevant the assessment is to existing personal attributes or whether new personal attributes are appropriate.

Subprocess 118 may be executed to map the assessment results to personal attributes. The provider may provide information regarding the value of each assessment result and how relevant they believe those results are to the existing attribute structure. Since an assessment may have more than one result, each result may be processed individually in an iterative manner. System 10 may execute subprocess 118 until all results have been processed and mapped. In some embodiments, each result may be processed simultaneously. Furthermore, in some embodiments, such processing may involve all other personal attributes of user model 17 connected to the enabling relationship specified in analysis processor 20.

At 120, the system 10 may determine whether the result requires a new attribute. If no new attribute is required, then at 122, the result may be added to a list of resources that affect existing personal attributes. If a new attribute is required, then at 124, the vendor may request the new attribute and identify the characteristics of the proposed new attribute so that the new personal attribute can be created. At 126, the system administrator may review the request for the new personal attribute to ensure that no existing attributes can be used to capture the evaluation results. At 128, the system administrator may accept the request for the new personal attribute, identify existing personal attributes that are sufficient to capture the evaluation results, or return the request to the vendor for further clarification. If the new attribute request is accepted, then at 130, the system administrator may create the new attribute, which may be immediately available in the analysis processor 20, the application 14, the application 15, and to all user models 17 at the end of the registration process.

Many assessment results may require the application of aggregation rules in order to present aggregated information to the third-party application 14, rather than actually assigning the user's raw score for the assessment. At 132, the system 10 may determine whether aggregation rules are required. If aggregation rules are to be applied, at 134, the vendor and/or system administrator may load these aggregation rules into the user model processor 17 via the system's vendor support website. At 136, a final review and approval process may be performed to ensure that everything is set up correctly. At 138, the application 14 may be accepted, or the system administrator may deny activation of the application 14.

If the evaluation is accepted, then at 140, the evaluation ID can be activated and results capture can begin. If the evaluation has been rejected, at 142, an appropriate message can be prepared for the supplier. If refinement is required, as determined at 128, then at 144, an appropriate message can be prepared for the supplier. At 146, the final status of the evaluation request and any prepared message can be sent back to the supplier.

One-way data flow

The system 10 can provide unidirectional data flow and/or bidirectional data flow. As discussed above, the system 10 can be used as a repository for PAs that describe specific individuals and can transmit multiple portions of those PAs to computer applications, which can use the data to provide a better user experience customized for each user. When an application wishes to participate in the system 10 as a partner application, the developer of the application can register the application and announce which PAs the application will read and write. Although there are hundreds or thousands of PAs that can be defined, each application can be limited to only those PAs that can be logically considered to be of interest to the specific domain of the requesting application.

To that end, each participating application 14 can create and implement a "read contract" and a "write contract" that can define which PAs will be read and written, respectively, as a result of initiating the application. During the registration process (e.g., the process of Figures 4A to 4B described above), the validity of the requested read elements can be verified by a human data administrator who verifies that the requested data is actually relevant to the purpose and function of the application. In addition, the true identity of each user can be shielded from the requesting application by preventing all personally identifiable information from being transmitted to the requesting application and by aggregating certain data elements in a manner that produces a highly accurate and meaningful approximation of the real user without providing real value that can be used to identify the individual user. Temporary access tokens can be used in place of personally identifiable information, and those access tokens may not persist across multiple sessions of the same application. Therefore, access tokens obtained during one session of use of an application are subsequently worthless to that application or any other application.

FIG5A illustrates a one-way data flow according to an embodiment of the present invention. As can be seen in FIG5A , each user can have many different data layers associated with their account. The lowest layer 1140 can store a virtual representation of the individual and can contain a copy of all data written to the individual's account. Each individual account can contain a large number of profiles 1120. Each profile can describe an aspect of an individual's behavior, tendencies, preferences, knowledge, skills, personality, or abilities. When combined in an individual record 1140, these profiles can provide a meaningful approximation of the real individual described by the data.

If a particular user is associated with one or more organizations that invest in the individual by providing access to specific learning or tracking applications, each of those organizations can set up an organization record for the individual. An organization can be almost any entity that includes individual users as members and also provides (paid or non-paid) access to software applications for the benefit of the individual. The example of Figure 5A shows 7 different organization records, such as school records 1130. Each of these organization records contains PA values 1110 captured by the application that can be initiated by the specific organization for the benefit of the individual and the organization, as discussed above. As can be seen in Figure 5A, there can be many different organizations that have a variety of purposes and interests associated with a single individual user. Some of these organizations will be interested in storing and tracking special PA values that are only of interest to the application suites provided by those specific organizations. However, there can be other organizations that will initiate applications that store and retrieve PA values, and applications initiated by other organizations can also be storing and retrieving these PA values.

The captured data can be visualized as a stack of two-dimensional planes that are subdivided into a PA grid as shown in FIG5A . Each PA 1110 can have a specific location within each organization's record. Thus, all PAs 1110 in a single column across organizations can represent different values for the same PA 1110. For example, one organization may consider an individual's foreign language proficiency to be at a "beginner" level, while another organization may consider an individual's proficiency in the same language to be at an "intermediate" level, depending on each organization's standards. Each new instance of a PA value can be stored according to the process described in FIG6 .

6 is a flow chart illustrating a process for storing data using a unidirectional data stream according to an embodiment of the present invention. At 1205, a new PA value may be observed by an application and sent to the system 10, for example, via an application programming interface (API). At 1210, the system 10 may determine whether the submitted application has been initiated by the organization for the current individual. It is possible that the application has been initiated by zero or more organizations. If the application has been initiated by zero organizations, it may be assumed that the data is strictly for the benefit of the individual user and is not derived from the efforts or investments of any organization that has established an organizational record for the individual. In this case, at 1240, the data is stored directly in the individual record.

If the application capturing the PA data is actually associated with one or more organizations, then at 1215, the PA value can be stored in the organizational record of each organization that originated the application. If more than one organization has sponsored the same application for the same individual user, all sponsoring organizations can receive the observed data, regardless of how the application was launched or where the application is located. In this way, an individual learner can receive credit for his/her work without having to complete tasks in the same application hosted on multiple organizations' servers.

Once the data is stored in one or more organizational records, the system 10 can automatically check the input data against any predictive models associated with the affected PA at 1220. If one or more models use the incoming PA values as input, the affected models can be executed and the resulting predicted PA values can be updated across all affected organizations at 1225 (see the "Predictive Analysis and Modeling" section below for more details). The results of the predictive models can be manipulated just like observed PA values and can be automatically stored in all organizational records for which the application for the initial PA observation was initiated.

At this point, all originating organization records may have been updated with the new observation and all predicted side effects associated with that initial observation. The system 10 can now use a one-way gate to automatically pull the new data down into the individual record so that it can be used and shared in any way the individual wishes. However, before this can happen, in some embodiments, at 1230, the system 10 may first check to see if the data is compliant with the Family Educational Rights and Privacy Act (FERPA), which restricts the sharing of data captured by applications or organizations that receive funding from the U.S. government. If the data is from any source that is not compliant with FERPA rules, then at 1240, the data and all derived predictions may be copied to the individual record.

If the input data is subject to FERPA regulations, the system 10 can require the legal parent or guardian of the minor to clearly declare that the data is for personal use. A process called "Declare My Data" can be required once so that the PA values authorized for entry are continuously and automatically migrated down through a one-way gate to the individual record, where the individual owner of the data can use the data for his/her benefit. For example, data captured from an application initiated by a school or educational institution (that has received funding from the U.S. Department of Education) for individuals under the age of 18 cannot be shared with any other entity (including the individual record of the student described by the data). The system 10 interface can include a "Declare My Data" button or option that, when clicked or selected, can generate an electronic form that can be used to submit authorization to share data between various organizations and individual records within the present invention. When a parent, guardian, or qualified student uses the "Declare My Data" form and specifies the specific organizations involved, data from applications initiated by those organizations can be automatically migrated through a one-way gate and flow from the organization down to the individual record, where the data can be used for the individual's benefit. If the input data is subject to FERPA regulations, the system 10 may check to see if the appropriate authorization has been completed at 1235. If authorization has been provided, the data may be stored in the individual record at 1240. If authorization to waive FERPA restrictions has not been granted, the input data may not be stored in the individual record and will be maintained solely within the organizational record; and the process may end at 1255.

If the input data makes it through all one-way gates, then at 1240, the input data can be stored in the individual record, and at 1245, any predictive models associated with the PA at the individual record level can be triggered. At 1250, each model can be executed in turn, and the appropriate predicted value can be added to the individual record. Once all of these predictive models have completed, the process can end at 1255.

Bidirectional data flow

By default, each user's performance attributes can be separated into separate organizational records, and the system 10 can use a one-way gate to project all data stored in all those organizational records onto the individual record. Thus, the individual record can contain the values of all PAs that have been observed by any application from any organization. While this projection of data onto individual records can be very useful when an individual wants to use an application that is prepared to read those PAs and tailor its user experience, there may be more applications that can use the data but only through applications launched from one of the organizational records associated with the individual user.

Returning to the reading level assessment example mentioned above, assume that a user is joining a school that has set up an organizational record for the individual, and that the school has launched a reading tutor that can (among other things) accurately assess the user's reading level. Now further assume that the same individual is a member of a professional group dedicated to the subject of electronic engineering, and that her membership includes access to an intelligent tutor that teaches members the basics of electronic circuits and the flow of electrons through closed circuits.

The intelligent tutor may have the ability to adjust the presentation of learning materials based on the reading level of the individual student using the intelligent tutor. Thus, students with lower reading skills receive instructional materials with longer descriptions using smaller words, while students with higher reading levels receive more concise text that uses the power of advanced language to quickly and accurately convey key concepts using fewer but more complex words.

An electrical engineer creating an intelligent tutor for delivering learning materials about electrical circuits might not be able to also create an accurate tool capable of assessing each user's reading level. Therefore, the intelligent tutor might need to make the reading tutor available to an individual's school using assessment data generated by the reading tutor. Once the electrical tutor knows the reading level, it can adjust appropriately to the individual's needs, but the reading tutor's data might not be visible to the individual because it is stored in records at a different organization.

The optional bidirectional data flow shown in FIG5B and the flowchart in FIG8 can illustrate how data can be shared between organizations with the permission of the individual who owns the data. Assuming that multiple observations of individual attributes have been stored in the system using the unidirectional method described above, those observations can now be shared with an organization other than the originating organization. Using the permission settings described in more detail below, individual attributes can be moved up the data stack through a bidirectional gate that allows selected data to flow from the individual record to the target organization record.

FIG5B illustrates a bidirectional data flow according to an embodiment of the present invention. In FIG5B , outlined empty squares 1150 represent PA data that has been moved from an individual record to one or more organizational records. All of these data items may exist in the individual record and may be moved to the organizational record through a bidirectional gate 1160 based on one or more logic rules that can manage the migration process while preserving the user's privacy and security.

For example, in Figure 5B, a user may take the same standardized test for two different situations. The first test may have been administered by a professional group of which the user is a member. The second test may have been administered by a standardized testing organization. In both cases, the results may have been stored in the records of both organizations (because those organizations sponsored the testing application), and the results may have also been migrated to the individual's record through a one-way door. However, the user's employer may have indicated that it would like to see the results of the standardized test in order to more effectively provide ongoing educational resources to the individual.

To accomplish this, the test data residing in the individual record can be moved from the individual record to the user's employer record via a two-way gate 1170. In this manner, the privacy rules within the two-way gate can be checked to ensure that the user is willing to share the test data with their employer. If not, the privacy filter in the two-way gate can prevent the data from flowing back to the employer record, and the employer may never even know that the standardized test data exists.

A similar scenario can occur using some healthcare data initially obtained from a user's school records and their health club records. Once the data reaches the individual record via a one-way gate, it can be made immediately available to the user's medical health record via another two-way gate 1180. Each individual PA and each organization can be subject to customized security and privacy logic rules that determine whether data from the individual record can flow back up to the organization.

FIG8 is a flow chart illustrating a process for reflecting data on an organizational view, according to an embodiment of the present invention. In this process, a bidirectional gate can reflect data from an individual record to all organizational records that are eligible to view the data. At 1405, personal attributes can be updated in the individual record. System 10 can loop through the list of organizations associated with the individual to determine which organizations should be able to view the new data.

At 1410, the system 10 can identify the first organization, and at 1415, the system 10 can execute the permission rule set to determine whether the organization is authorized to view the PA. If not, the process can skip the next action, otherwise at 1420, the PA data can be linked to (e.g., copied to) the organization record with the matching organization ID. At 1425, the system 10 can check to see if other organization records are attached to the user. If so, at 1430, the next organization ID can be retrieved, and the process can repeat from 1415. If no other organizations are attached to the individual, at 1435, the process can end.

Permission settings with risk tolerance assessment

System 10 can employ semantically intelligent security and privacy risk tolerance assessments that use a range of specialized tools to derive detailed information about a user's attitude toward sharing information in various contexts. User model 17 can be responsible for conducting these assessments. Based on the results of these assessments, system 10 can automatically categorize a user into one of many different security profiles that automatically set sharing permissions for all PA values.

FIG7 is a flow chart illustrating a process for setting permissions using a risk tolerance assessment along with tools that can allow each user to manually adjust the resulting settings if desired, in accordance with an embodiment of the present invention. The process can use a combination of elicitation tools that narrow each user's particular view of the world and security measures that best help them navigate that world. The process is shown linearly in FIG7 , but in some embodiments, the order of events can be altered as a reflection of user responses or values within specific personal attributes. Where possible, the system 10 can attempt to work from broad knowledge to specific, detailed knowledge as the system 10 builds its security recommendations.

One common type of elicitation is called a Slide Q's 1305. Slide Q's can provide a quick and easy way to determine baseline attitudes on a variety of topics. The user can be presented with a stack of virtual cards, each containing an image, text, or a combination of image and text that conveys a safety question. For each card, there can be three possible choices, such as "Dangerous," "Safe," and "Neutral," but other choices may be possible. In one exemplary interface for a device equipped with a touch screen, if the user perceives the illustrated scenario as dangerous, they can swipe to the left to record that response. If the user perceives the scenario as safe, they can slide the card to the right to indicate that choice. If the user is undecided, a vertical swipe downward will record "Neutral." With each swipe, the current card can be moved off the screen in that direction, and a new card with a new question can be displayed.

Assessing a user's usage and comfort level with established and present social media 1310 can indicate a user's willingness to share certain types of information. Since the overall system 10 can benefit from connecting to a user's social media accounts and analyzing data available to those organizations via APIs, the system 10 can utilize the user's decisions regarding social media to inform algorithms for recommending security settings. For example, a user can provide the system 10 with access to a social media account, and the system 10 can analyze the information to determine what types of personal information the user shares and refuses to share.

Once baseline information on behavior, attitudes, and knowledge has been completed, targeted multiple-choice or Likert scale questions 1315 can be presented to the user to delve deeper into specific issues and scenarios that may impact the security and privacy decisions the user can make. The content of these questions can be dynamically generated to fill in gaps in the user's knowledge and continue to require multiple questions to complete the conceptual query line.

Some questions may not involve constructed responses. Instead, these questions may be more conversational in nature 1320 and may form open-ended answers that may require semantic analysis and natural language processing techniques to extract the user's meaning. This type of interaction can be used to narrow the attitude gap by applying, for example, semantic analysis and sentiment classification techniques. The results of these and any other questions can be combined 1325 in a data risk tolerance quotient module, which can apply absolute classification and mathematical calculations to the user's responses to produce a multidimensional similarity matrix for clustering users into multiple groups of similar people. The following attributes can be used to define the risk tolerance of a particular user. Each attribute can be obtained from the user using direct interview questions presented on the screen. Because response values can vary widely, each attribute value can be normalized to a value between 0.0 and 1.0, where 0.0 indicates "low" and 1.0 indicates "high". Each can be associated with a different formula for reducing the complexity of the attribute, so that the value of the attribute is mapped to a normalized range of 0.0 to 1.0. Attributes may include, but are not limited to, the following:

Number of Internet "friends"

Willingness to share income/tax information

Willingness to share health information

Number of email addresses (greater than 2 is indicative)

The perceived benefits of sharing various types of data

Age

The perception of control

Culture (location) - different weights for different cultures

Each attribute may also have its own weight value. The weights may be adjusted to increase or decrease the perceived importance of each attribute. Once the weights and mapping function have been established, the accumulation of risk tolerance scores may be performed according to the following function:

Where: w _i = weight of the attribute, and _vi = mapped value of the attribute.

In many cases, the sum of the weights may equal 1. In cases where the sum of the weights does not equal 1, the sum of the weights multiplied by the values may be divided by the sum of the weights to correct for bias. The accumulated personal bias may be used in conjunction with the user's assessment of the perceived risk associated with the set of scenarios to calculate a final risk tolerance.

A scene containing some activity or situation may be presented on the screen so that the user can indicate whether the scene seems dangerous to them. Depending on the context of the scene, different presentation formats may be used, but in any case, the user may be allowed to indicate their perception of the level of risk associated with the scene. In addition to being tagged to group scenes with a keyword classifier, each scene may also be tagged with a value for a separate risk factor that objectively indicates the true risk of the scene. The examples shown below may be used as weights in the overall calculation of risk tolerance. If the user is more accepting of true risk, the risk tolerance quotient may go up. If the user is less accepting of true risk, the risk tolerance quotient may go down. Risk factors may include, but are not limited to, the following:

1. Voluntary-Involuntary: Do users feel they have a real choice about whether to take the risk?

2. Immediate Effects vs. Delayed Effects: Will the bad consequences affect users immediately, or will they only become apparent over time?

3. Chronic-Catastrophic: Do the bad consequences affect users slightly over a long period of time, or do the bad consequences occur in quick bursts with a large impact?

4. Conventional-Fear: Can users learn to accept bad outcomes and think calmly about them, or do bad outcomes lead to fear and emotional thinking?

5. Severity: Minor to Fatal: How big will the impact of the bad outcome be?

6. Can be Migrated: Very Likely - Very Unlikely: Do users believe there is an easy way to prevent the bad outcome?

7. Within Personal Control: Very Likely-Very Unlikely: Do users believe they have the ability to prevent bad outcomes through their personal skills, knowledge, and actions?

8. Risk/Reward: Very High – Very Low: Do users believe the benefits are worth the risks?

Each scenario may receive a cumulative risk score, which may be calculated as follows:

When a scenario is displayed, the user can select the perceived inherent risk in the scenario by indicating whether the scenario is 1) dangerous, 2) safe, or 3) neutral. Categorizing each displayed scenario into one of these three categories can indicate the user's risk tolerance. Using the formula below, the risk scores from each category can be averaged and compared to the standard risk score for each category.

The ranges for the three risk categories can be:

Dangerous = 1.0-0.6

Neutral = 0.59-0.41

Safe = 0.4-0.0

For example, if the risk for a classification of a scene selected as dangerous is below 0.6, the user may have perceived the risk in the scene to be higher than the user's desired average, and therefore that particular user may have a lower risk tolerance quotient. If the risk for a classification of a scene selected as safe is greater than 0.4, the user may have perceived the risk in the scene to be lower than the user's desired average, which may result in a high risk tolerance. Although this example only references one classification process, in some embodiments, the scenes may first be grouped into similar contextual groups by keyword tags before calculating the classification risk factor. This additional step can help illustrate how perceived risk varies based on context.

Finally, the two risk factors (personal bias and perceived risk) can be used to match users with other users based on the overall similarity of the two scores. Each group can represent a different type of user with different privacy and security concerns. Security and privacy setting recommendations can be distributed to all PAs and applications 1330 based on the specific cluster in which the user is located. There can be hundreds of different user clusters in the system, each containing slightly different users with slightly different attitudes about security and privacy.

However, individual users may have a desire to review and potentially modify the recommended security and privacy settings. A user's privacy and security report 1335 may allow the user to view the recommended settings in absolute terms, via multiple pivot tables that stratify the data in various ways, or via an extended drill-down approach with respect to applications, personal attributes, or recommended privacy settings, or in some other manner. By drilling down into any of these measures, the user can see the attributes and applications affected by the recommendations. If adjustments are desired, automatic categorization adjustments 1340 may be made, for example, by adjusting sliders associated with the primary dimensions of security and privacy. The user may also choose to use the system's manual sharing adjustment tools 1345 to locate specific applications or personal attributes and manually set their permissions.

Regardless of how security and privacy settings are established, they can provide a starting point for risk tolerance assessment. As the user continues to use the system 10 to learn new materials, launch applications, share information, adjust permission settings, etc., the system 10 can continue to monitor and learn about the user 1350 and can automatically suggest potential adjustments to security and privacy settings. This monitoring and adjustment cycle can continue for the life of the user's account.

Contextual Risk Tolerance

When humans make decisions about what information they will share with each other, they may individually consider details such as who will view the information, how it will be used, how trustworthy each entity in the transaction is, and how long the information will be retained after it has been used for its original intent. The system 10 can apply security and privacy filters to take such details into account based on the permission setting recommendation and adjustment tools described above. Figure 9 is a block diagram describing how permission settings control data sharing according to an embodiment of the present invention. As an example of how these filters can work, Figure 9 shows a subset of applications that a particular user can use to help him manage his health and well-being. He uses four different applications to manage different aspects of his health. The applications used in this example are purely fictional and are intended only to provide context for the data sharing example. It is not intended to be connected to any existing application.

The four applications are:

● Health Tracker 1505 - A general purpose quantified self-report and assessment application that allows users to track multiple aspects of overall health and well-being, including diet, exercise, personal habits, vital statistics, and high-level mental states over time. This is a standalone application that users discover and purchase on their own.

Fitness Buddy 1510 and 1515 - An exercise-oriented fitness app that helps users manage their workout schedule, cross-training, recovery time, and basic body chemistry. The user's health club has provided the app to the user for free as a membership benefit. If the captured data shows that employees become more active (if they track their workouts), the user's employer may also have provided the app as a benefit that also happens to reduce insurance costs for their employees.

• Restaurant Finder 1520 - A search engine application that helps users find restaurants and food services based on social reviews and each user's specific needs regarding allergens, intolerances, and preferences. The user's health club offers this application as another benefit of its membership.

● Virtual Doctor 1525 - A convenient assistant application provided by the user's healthcare provider. The application assists the user in making appointments when needed, and also provides automated suggested nurses and triage services, as well as direct access to medical specialists when needed.

Together, these four applications can provide all the services that this particular user needs to effectively manage their health and well-being, but to achieve that goal, those applications may need to share data about the user. However, as a result of the system's risk tolerance assessment 1535, the system 10 has learned that the user is unwilling to share all of their health data with each of these applications in this example. Therefore, permission settings can be established to control the flow of data between applications so that each application receives exactly what it needs to effectively serve the individual user, but no application receives more than it needs to know to complete its mission.

The process may begin when a user enters health data into the health tracker application 1505. In this example, the user enters the following data, among other things:

●Weight

Height

Body mass index

Blood pressure

Cholesterol levels

Resting breathing rate

Respiratory rate under stress

Resting pulse rate

Pulse rate under stress

Hydration statistics

Dietary issues (allergies and intolerances)

When a user updates their information, the data can be sent to the user's personal record in the user model 17 for subsequent use. During the storage process, security and privacy one-way and two-way gates 1530 can be implemented, as described above. Data can be stored in the personal record 1545, and security rules derived from the user's risk tolerance assessment 1535 can be applied to the input data to assign appropriate permissions to each individual piece of data received. The user's individual response to the classified risk scenarios described in the previous section can drive decisions regarding which security rules to invoke. The developed security and privacy categories 1540 can be applied to ensure that each application receives only the information it needs and only the information the user is willing to share with each combination of application and sponsoring organization.

Later, when the user goes to his health club to work out, he uses his fitness buddy app 1515 to help plan his workouts. Since the user realizes that the most effective type and duration of his workouts often depends on multiple factors, such as his recent exercise history, his weight, and various components of his blood chemistry, he is willing to share this information 1555 with his fitness buddy 1515 at the health club. However, he does not see a reason to share information about his food allergies or intolerances to certain foods with the health club. Therefore, he manually adjusts the permissions for the app so that food information is not transmitted to his fitness buddy when this data is requested.

In order to receive a small price break on health insurance premiums through his employer, the user has agreed to participate in the fitness partner program 1510 at work. This is the same application that the user uses at his health club, so all the data the insurance company needs is easily available. However, since the incentive program only requires exercise history to confirm a more active lifestyle, and since the user has shown concerns about sharing personal information with his employer during the permission setting exercise (discussed in the previous section), the user model 17 indicates that the user may feel that his cholesterol is higher than normal and may affect his employee insurance benefits. Therefore, the system 10 determines that the instance of the employer-sponsored fitness partner does not have a high enough benefit-risk ratio to share this detailed health information with the employer and insurance company. Therefore, the healthcare data associated with the user's employer organization record is limited to the user's exercise history 1550. When using the employer instance of the fitness partner application, other information is not available.

After leaving the health club, the user launches his restaurant finder app 1520 to find a good place for dinner. The app could use considerable personalized data to make recommendations, but the user has communicated to the system, via risk tolerance assessment 1535, that he is only comfortable providing his food allergy history and intolerance issues to food-related applications. Therefore, in this case, the app's request for data about the user is filtered out and only returns the fact that the user requires a gluten-free diet and that he is allergic to shellfish 1560. All other requested information is suppressed by the rules established during the risk tolerance assessment.

The final application in this subset of applications is a virtual doctor application 1525, which is made available to the user's medical team at the user's healthcare provider. The application requests access to all available medical and health-related information about the user. Since the user has indicated that they want an open and free dialogue with their doctor, the permissions set for the application allow for the free exchange of all medical and health data 1565 as provided by the user's healthcare provider, thereby ensuring the best possible healthcare.

As shown in this example, the type and amount of personal attribute data received by each application can depend entirely on the results of the user's risk tolerance assessment, and this assessment can be sensitive to the fact that a user may not want to share the same information with the same application in different contexts. Since the fitness buddy is used in two different contexts (health club and employer), security and privacy rules can automatically adjust the data that can be released in each context. Even in the case where the same organization has launched multiple applications (such as fitness buddy 1515 and restaurant finder 1520 for health clubs), the usage context of each application can indicate a different level of trust and willingness to share certain types of information. This can be true when differentiating between different contexts in which different categories of applications request similar data. The user's response to the risk tolerance assessment can drive the system's decision on what to release to each application. The specific context of each data use can inform the data sharing decision process, similar to when humans make information sharing decisions every day.

Predictive analytics and modeling

Figure 2 is a block diagram of an analysis process according to an embodiment of the present invention. In some embodiments, user model 17 may represent low-level attributes that can be combined in various ways to provide higher-level attributes. When applications 14 and 15 make new observations of a user, platform 16 can analyze those observations and draw predictive conclusions about what those observations might mean. When a new PA observation 201 arrives at user model 17, user model 17 may access the user model manager database to evaluate which analysis events may be relevant to observation 202. Based on this evaluation, user model 17 may trigger one or more analysis events 203 in analysis processor 20. Analysis events may be associated with many different potential predictive models. Because not every predictive model will be affected by changes in a particular PA, the multiple available predictive models may be filtered 204 by user model 17 to include only those affected by the input PA. User model 17 may access data provided by PA catalog 18 to determine which models are affected by the new PA observation. Analysis processor 20 may then apply the filtered predictive models 205. Each selected model can react to new observations by potentially performing many different calculations that exploit the graph of relationships between individual attributes to determine a score and confidence factor for the prediction for each relevant attribute.

FIG3 illustrates a simple model 301 that may be capable of predicting scores for four different PAs based on the observed scores for a single PA. As shown in 302, the input parameters for this example are the direct observation that PA 2 has been observed to have a score of 0.75 and a confidence factor of 1.0. In some embodiments, the scores may be normalized to values between 0.0 and 1.0. In this case, the user has only demonstrated three-quarters of the skills represented by PA 2 (e.g., the user answered 75% of the test questions correctly, scored in the 75th percentile on a skill assessment, etc.); thus, the score is 0.75. However, the user has been able to demonstrate those skills robustly and has therefore received a confidence value of 1.0, meaning that the user has consistently performed the associated tasks.

In the directed graph of model 301, the arrows indicate that PA 2 has two prerequisites, namely PA 3 and PA 4. Prerequisites can be manipulated so that if a user can demonstrate a certain skill level in PA, there can be a known probability that the user must have a given skill level in the prerequisite PA. For example, if a user can dunk, it is highly likely that the user can jump high enough to reach the rim of the basketball hoop. Since PA 3 and PA 4 are required to be able to perform PA 2 in this example, it can be assumed that each of those prerequisite PAs has a value at least as high as PA 2. The confidence factor for each possible prerequisite is multiplied by the confidence factor for PA 2 to yield confidence factors of 0.9 and 0.5 for PA 3 and PA 4, respectively. The same process can then be used to calculate the scores and confidence factors for any prerequisites for PA 3 and PA 4. In this case, there is only one prerequisite for each, and it happens to be the same PA 5. Therefore, the value for PA 5 is calculated twice, once using the score and confidence factor from PA 3 and once using the value from PA 4:

PA5 _score = PA3 _score = 0.75

PA5 _{confidence level} = PA3 _{confidence level} * 0.1 = 0.9 * 0.1 = 0.09

PA5 _score = PA4 _score = 0.75

PA5 _{confidence level} = PA4 _{confidence level} * 0.5 = 0.5 * 0.5 = 0.25

Since the highest confidence factor of the two possible channels is 0.25, the best path between PA 2 and PA 5 is through PA 4, so the final score for PA 5 is 0.75 and its confidence factor is 0.25.

Similarly, the score and confidence factor for PA 1 can be calculated from direct observations of PA 2, but in this case, PA 2 is a prerequisite for PA 1. Therefore, the confidence factor and score are penalized during the calculation as shown below:

PA1 _score = PA2 _score * 0.9 = 0.675

PA1 _{confidence level} = PA2 _{confidence level} * 0.9 = 1.0 * 0.9 = 0.9

Therefore, there is a 90% chance that the user can properly perform 67.5% of the skills required for PA 1. The change in PA score (from 0.75 to 0.675) results in a probability that a new skill not present in PA 2 is associated with PA 1, and a downward adjustment of the confidence factor, since the estimate of probability is the product of two confidence factors. Table 303 shows the scores and confidence factors calculated for each PA.

As a practical example, if an application observes that a user has mastered the ability to "write a function that describes the relationship between two quantities" and also the ability to "determine an explicit expression, recursive procedure, or computational steps from context," then there's a high probability that the user has mastered the high-level personal attribute of "building mathematical functions." Furthermore, once a prediction for this high-level PA has been made, it can be used as an observation in another analytical model that combines "building mathematical functions" with values representing the user's abilities in the areas of "properties of circles" and "expressions and equations" to predict the probability that the user will be able to perform algebraic math problems. This simple example can be visualized in a hierarchy of attributes:

Algebraic Mathematics

○Expressions and equations

○Properties of a circle

○Create mathematical functions

■Write a function that describes the relationship between two quantities

■ Determine explicit expressions, recursive procedures, or computational steps from the context

In this exemplary hierarchy, writing functions that describe the relationship between two quantities and determining explicit expressions, recursive procedures, or computational steps from context are prerequisites for building mathematical functions. In turn, building mathematical functions, expressions, and equations, as well as the properties of circles, are prerequisites for algebraic mathematics.

The platform 16 may include many different analytical models that may be triggered whenever a new observation is sent to the user model 17. The exemplary models discussed above are simple models intended for explanation purposes only. The platform 16 may include many different models that vary widely in complexity and design and may involve any number of individual personal attributes and any number of detailed mathematical operations.

Example use cases

The following paragraphs describe different exemplary uses of system 10 according to some embodiments of the present invention. The following examples may be applied alone or in one or more combinations with each other.

In one example, system 10 can customize third-party applications 14 in a way that improves the user experience. User 11 may have a personal user model 17 that stores multiple PAs. User 11 can then grant third-party applications 14 access to portions of the data in their personal user model 17. Third-party applications 14 can use attributes to gain an understanding of user 11. Therefore, when user 11 launches application 14, third-party application 14 can make appropriate changes to tailor the presentation of material specific to user 11. For example, third-party application 14 can react and present information and tasks within application 14 at a level appropriate for a person with the user's PA. Third-party application 14 can also track the user's history as they use applications 14 and 15, submitting tendencies, performance, and other data back to system 10. User model 17 can again track the user's tendencies, performance, and other data and update the user's personal genome data.

In some embodiments, the above examples are used in teaching applications. The third-party application 14 can create a performance enhancement environment in the form of a learning course. When the user 11 performs different tests (i.e., assessment tools) in the learning course, the user's attributes can be assessed by the third-party application 14. The competencies assessed by the third-party application 14 can be defined by the system 10, and individual attributes in the user's personal user model 17 can be created to store the competencies. The output data (scores, assessments, etc.) from the learning course can be analyzed by the analysis processor 20, assigned to the corresponding attributes in the user's personal user model 17, and later evaluated by the third-party application 14 for further testing.

In another example, a third-party application 14 or the system 10 itself can query the system 10 to search the user's personal user model 17 and automatically suggest specific applications 14 and 15 to the user that target specific data elements that are not currently represented in the user's personal user model 17 or that may have changed since the user 11 was last evaluated on a specific topic (e.g., due to a long period of inactivity).

Following the above example, system 10 (either independently or in conjunction with third-party application 14) can perform a user-authorized internet search for information related to user 11. System 10 can then store such information, alert user 11 to the availability of such information and its source, and/or perform other user-authorized tasks, such as automatically deleting user information from that source or requesting that the information be hidden. For example, system 10 can use information from social networking sites to update a user's personal attribute data. User 11 can be given the option (e.g., upon system startup) to authorize system 10 to search social networking sites and other websites and update the user's personal genome data accordingly. Furthermore, when user 11 enters their phone number into user profile 17, they can have the option to place their phone number on a global "do not call" list. If authorized by the user, system 10 can search the internet as a background task to ensure that the user's phone number is not publicly available. Furthermore, if authorized by the user, system 10 can search the internet for the user's credit rating available on the internet through various sources. System 10 can alert user 11 to the various sources and what credit rating is available through each source.

In yet another example, the system 10 can be used to collect and generate detailed human behavior, knowledge, skills, and attitude data related to anonymous users suitable for corporate and academic research work. The system 10 and/or third-party application 14 can select the specific research group of the user 11 and extract target data elements (e.g., raw data or aggregated data) from the selected research group. The user 11 can have the ability to specify which data elements can be extracted in their entirety (i.e., as raw data) or in aggregated form before releasing the data for research work. In addition, the user can receive monetary payments or in-kind value transactions for releasing their data. Such payments can be tracked and managed by the system 10 or third-party application 14 that receives and evaluates the data.

In another example, a third-party application 14 can interact with the system 10 to act as a personal agent to assist the user 11 in making personal and/or professional decisions based on the content of the user's personal user profile 17 and/or any available third-party information. The application 14 can capture events and knowledge about the user's activities and then provide suggestions and recommended subsequent activities based on the captured knowledge in the areas of learning, education, training, performance, and/or work support. The application 14 can also apply intelligence to the personal user profile 17 and provide guidance and recommendations to the user 11 based on the data available in the user profile 17. The system 10 can reference competencies, professional activities, and performance of professional activities and then provide mappings between professional activities and performance, as well as between performance and competencies. Thus, a formal assessment of competencies can be conducted based on the performance of identified activities. The application 14 can determine a formal rating for the activity and which expected performance will best improve the target competency. The application 14 or system 10 can also provide recommendations based on inferences determined by the mappings.

Continuing with the above example, third-party applications 14 may interact with the system 10 to act as a personal agent that assists the user 11 in making decisions regarding leisure activities and everyday activities, such as at retail stores, museums, travel websites, and the like.

In the retail store example, a user can access their user profile 17 on one or more of their mobile devices and visualize and decide what information from their personal attributes they would like to make available to the clothing store (e.g., measurements, shoe size, shirt size, personal style preferences, previous clothing type transactions, other related transactions, etc.). A third-party application 14 associated with the clothing store can include a scanner or reader, and the user's mobile device can provide a visual barcode. The visual barcode can include a temporary password that can be deciphered by the scanner or reader. The third-party application 14 can then use the temporary password to access the personal attribute information that the user 11 made available. The third-party application 14 can then evaluate the available personal attribute information and, based on this evaluation, make recommendations to the user 11, such as items that may be of interest to them, specific areas of the clothing store that would include items that may be of interest to them, sales on items similar to items they recently purchased, etc. This information can be made available to the user via an application computer (e.g., at a kiosk in the clothing store, which may also include a scanner or reader) or via the user's mobile phone (e.g., the third-party application 14 can send the information directly to the user 11 via email or SMS message, or via a hosted application 15). If the user 11 purchases any item at the clothing store, the third-party application 14 can submit the transaction details to the system 10 for updating the user's personal genome data. The user 11 can later review the transaction details and may have the option to delete the details from their user model 17.

"User model-enabled" retail stores can allow for a better shopping experience for users. Users can also enhance their user model by shopping at user model-enabled retail stores because the user's transactions can be tracked and added to their user model. In addition, because a user's individual user model 17 can store all user information and transaction history, purchases from one store can be used to improve the user's shopping experience at different stores. For example, a third-party application 14 associated with a bookstore in a shopping mall can use transaction data from a user's online book purchases as well as purchases from that particular bookstore to perform a better overall assessment of the user's reading preferences, rather than using only the user's transaction history from that particular bookstore.

In the museum example, a user can access their user model 17 on one or more of their user devices and visualize and decide which information from their personal attributes they want to make available to the museum (e.g., education, recent travel history, book preferences, general preferences, etc.). A third-party application 14 associated with the museum can include a scanner or reader and the user's mobile device can provide a visual barcode. The visual barcode can include a temporary password that can be deciphered by the scanner or reader. The third-party application 14 can then use the temporary password to access the personal attribute information that the user 11 made available. The third-party application 14 can then evaluate the available personal attribute information and make recommendations to the user 11 based on the evaluation, such as attractions that they may be interested in. In addition, the third-party application 14 can act as a virtual museum tour guide to create a tour that can be played on the user's mobile phone or separate device to enhance the museum experience customized to the user's educational background and personal preferences.

In the travel website example, user 11 may allow a third-party application 14 associated with the travel website to access various portions of their personal attribute information (e.g., interests, recent travel, etc.). Third-party application 14 may then evaluate the user's information and suggest customized travel plans that user 11 may be interested in. If user 11 makes a purchase on the travel website, third-party application 14 may communicate the transaction to system 10.

In another example, the system 10, by itself or in interaction with a third-party application 14, can act as a global software agent that constructs affinity groups and interpersonal inferences for each subscribing user 11 based on similar anonymous user information in the central user model processor 17. The system 10 can provide automatic selection and recommendation of possible items of interest. The system 10 can include a probability-based algorithm that anonymously matches similar users 11 to fill gaps in personal attributes based on information stored in the user model 17 for matching users 11. The system 10 can also include a probability-based algorithm that recommends activities that will improve the user experience based on data from similar users and targeted user groups.

Continuing with the above example, in addition to interacting with other third-party applications 14, the system 10 can also act as a social networking application. The system 10 can allow a user to make certain portions of their individual user model 17 publicly available for other users to view and provide feedback. A user 11 can apply various filters to their personal attribute data so that different users 11 see different aggregates of data, for example, based on their relationship or connection to the user 11. Applying filters to a user's personal attribute data and/or other users' attribute data can create affinity groups of multiple users grouped together according to common attributes. When appropriate, the system 10 can use feedback from other users 11 to update a user's individual user model 17. For example, when a user has additional attributes shared by other users in an affinity group, the attributes shared by the affinity group can be applied to the attributes in the user model 17. These suggestions can increase the scope of the user's individual user model 17, thereby providing the third-party application 14 with more detailed information about the user.

Continuing with the above example, when executing the assessment tools within applications 14 and 15, user 11 can view the completeness level of their user model 17 (e.g., how many attributes user 11 has stored compared to how many attributes are available globally). User 11 can also invite other users 11 to execute the same applications 14 and 15 to assess user 11 or themselves on the same topic.

In yet another example, in addition to including user attributes for assessment tools, the user model 17 can also serve as a secure global repository for the user's medical records. Upon request, an application 14 associated with a particular doctor, clinic, or hospital can be allowed to access the user's medical records. Because records from different doctors and clinics can all be stored in one place, there can be fewer medical errors caused by doctors who are provided with incorrect information (who have not yet received sufficient medical history), and there is less need to send paperwork from one doctor to another, etc. Moreover, when the user 11 receives the results of a medical test, the doctor (or hospital or clinic) can give the user the option of saving these results in the user's individual user model 17. If approved, the application 14 and application 15 associated with the doctor can communicate with the system 10 to enter the user's medical results. The analysis processor 20 can classify the entered medical results into the appropriate location in the user's individual user model 17.

It should be understood that the present invention is not limited in its application to the details of the construction and the arrangement of parts proposed in this specification or shown in the accompanying drawings. The present invention is capable of realizing other embodiments and can be practiced or performed in various ways. Moreover, it should be understood that the phrases and terms used herein are for descriptive purposes and should not be considered as limiting. The use of "including", "comprising", or "having" and its variations in this article is meant to cover the items listed thereafter and their equivalents as well as additional items. Unless otherwise specified or limited, the terms "install", "connect", "support", and "couple" and their variations are used in a general way and cover direct installation, connection, support and connection as well as indirect installation, connection, support and connection. In addition, "connect" and "couple" are not limited to physical or mechanical connections or connections.

The foregoing discussion is presented to enable those skilled in the art to make and use embodiments of the present invention. Various modifications to the illustrated embodiments will be apparent to those skilled in the art, and the general principles herein can be applied to other embodiments and applications without departing from embodiments of the present invention. Therefore, embodiments of the present invention are not intended to be limited to the embodiments shown, but rather to be accorded the widest scope consistent with the principles and features disclosed herein. The detailed description is read with reference to the accompanying drawings, in which identical elements in different drawings have the same reference numerals. The drawings, which are not necessarily to scale, illustrate selected embodiments and are not intended to limit the scope of embodiments of the present invention. It will be appreciated by those skilled in the art that the examples provided herein have many useful alternatives and fall within the scope of embodiments of the present invention.

Although various embodiments have been described above, it should be understood that these embodiments have been presented by way of example and not limitation. It will be apparent to those skilled in the relevant art that various changes in form and detail may be made without departing from the spirit and scope. Indeed, after reading the above description, it will be apparent to those skilled in the relevant art how to implement alternative embodiments.

Furthermore, it should be understood that any drawings highlighting features and advantages are presented for illustrative purposes only.The disclosed methods and systems are sufficiently flexible and configurable such that they can be utilized in ways other than those shown.

Although the term "at least one" may often be used in the specification, claims, and drawings, the terms "a," "the," "said," etc. also mean "at least one" or "the at least one" in the specification, claims, and drawings.

Finally, Applicant intends that claims that include only the phrase "a method for" or "a step for" be interpreted under 35 U.S.C. 112(f). Claims that do not expressly include the phrase "a method for" or "a step for" are not to be interpreted under 35 U.S.C. 112(f).

Claims (42)

1. A data flow method, comprising: The user module, executed by a processor connected to the database and associated with the access-controlled service, receives values for attributes of a user having an account related to the access-controlled service; The user module is used to determine whether the value is derived from an assessment initiated by an organization associated with the user, wherein the organization has at least one account with respect to the access-controlled service; When the value is derived from the evaluation initiated by the organization associated with the user, the user module is used to store the received value in a record in the database that is associated only with the user and is inaccessible through the organization's at least one account, and the user module is also used to store the received value in a separate record associated with the organization and the user, wherein access to the separate record by a third party is controlled by the user. When the value is derived from a source different from the evaluation initiated by the organization associated with the user, the user module is used to store the received value in the record in the database that is associated only with the user. Using the analysis processing module executed by the processor, it is determined whether the attribute is associated with the prediction model; In response to determining that the attribute is associated with the prediction model, the analysis processing module uses the received value to execute the prediction model associated with the attribute to generate a predicted value using the attribute's score and confidence factor; When the value is derived from the assessment initiated by the organization associated with the user, the analysis processing module is used to store the predicted value in the database in the record associated only with the user and in the record associated with both the organization and the user; and When the value is derived from an assessment not initiated by an organization associated with the user, the analysis processing module uses the predicted value to store it in the database in a record associated only with the user. 2. The method of claim 1, further comprising: The user module is used to determine whether a second organization with at least one account related to the controlled access service is authorized to view the received value; and When the second organization is authorized to view the received value, the user module is used to store the received value in the database in the record associated only with the user and in the record associated with the second organization and the user, wherein access to the record associated with the second organization and the user by a third party is controlled by the user. 3. The method of claim 2, further comprising: performing a risk tolerance assessment for the user using a data risk tolerance module executed by the processor to generate a risk tolerance for the user; Specifically, determining whether to authorize the second organization to view the received values using the user module includes: Using the user module, a privacy filter is assigned to the user based on the risk tolerance; and The user module is used to determine whether the privacy filter allows the received value to be shared with the second organization. 4. The method of claim 3, wherein performing the risk tolerance assessment for the user using the data risk tolerance specialist module includes: receiving answers to risk tolerance questions from the user using the data risk tolerance specialist module. 5. The method of claim 4, wherein performing the risk tolerance assessment for the user using the data risk tolerance quotient module comprises: calculating a risk tolerance score associated with the answer to the risk tolerance question using the data risk tolerance quotient module. 6. The method of claim 3, wherein performing the risk tolerance assessment for the user using the data risk tolerance module includes: monitoring user behavior using the data risk tolerance module. 7. The method of claim 3, wherein performing the risk tolerance assessment for the user using the data risk tolerance provider module comprises: receiving an adjustment to the risk tolerance from the user using the data risk tolerance provider module. 8. The method of claim 1, further comprising: The user module is used to determine whether a second organization with at least one account related to the controlled access service is authorized to view the predicted value; and When the second organization is authorized to view the predicted value, the user module is used to store the predicted value in the database in the record associated only with the user and in the record associated with the second organization and the user, wherein access to the record associated with the second organization and the user by a third party is controlled by the user. 9. The method of claim 8, further comprising: performing a risk tolerance assessment for the user using a data risk tolerance module executed by the processor to generate a risk tolerance for the user; The process of determining whether to authorize the second organization to view the predicted value using the user module includes: Using the user module, a privacy filter is assigned to the user based on the risk tolerance; and The user module is used to determine whether the privacy filter allows the predicted value to be shared with the second organization. 10. The method of claim 9, wherein performing the risk tolerance assessment for the user using the data risk tolerance specialist module comprises: receiving answers to risk tolerance questions from the user using the data risk tolerance specialist module. 11. The method of claim 10, wherein performing the risk tolerance assessment for the user using the data risk tolerance quotient module comprises: calculating a risk tolerance score associated with the answer to the risk tolerance question using the data risk tolerance quotient module. 12. The method of claim 9, wherein performing the risk tolerance assessment for the user using the data risk tolerance module comprises: monitoring user behavior using the data risk tolerance module. 13. The method of claim 9, wherein performing the risk tolerance assessment for the user using the data risk tolerance provider module comprises: receiving an adjustment to the risk tolerance from the user using the data risk tolerance provider module. 14. The method of claim 1, further comprising: using the user module to receive permission from the user to store the received value. 15. The method of claim 14, further comprising: using the user module to determine whether a user permission is required to store the received value. 16. The method of claim 1, further comprising: The user module provides a first personalized assessment tool for execution by the user, wherein the result of the first personalized assessment tool includes the received value; and The user module provides records associated with the organization and the user, which, when authorized by the user, are used to create a second personalized assessment tool for execution by the user. 17. The method of claim 1, further comprising: encrypting the received value using the user module before storing the received value in a record in the database that is associated only with the user, in a record that is associated with the organization and the user, or in a combination thereof. 18. The method of claim 1, further comprising: providing a temporary password using the user module, the temporary password allowing access to the received value stored in the record associated with the organization and the user. 19. The method of claim 1, further comprising: assigning an identifier to the record associated with the user using a directory module executed by the processor, wherein the user module uses the identifier to locate and access a portion of the record associated with the user. 20. A data flow system, comprising: database; A hardware processor connected to the database and associated with access-controlled services; User module, which is executed by the hardware processor and configured to: Receive values for attributes of users with accounts accessing the controlled services; Determine whether the value is derived from an assessment initiated by an organization associated with the user, wherein the organization has at least one account with respect to the access-controlled service; When the value is derived from the evaluation initiated by the organization associated with the user, the received value is stored in a record in the database that is associated only with the user and is inaccessible through the organization's at least one account, and the received value is also stored in a separate record associated with the organization and the user, wherein access to the separate record by a third party is controlled by the user. When the value is derived from a source different from the assessment initiated by the organization associated with the user, the received value is stored in the database in a record associated only with the user; and Analysis and processing module, which is executed by the hardware processor and configured to: Determine whether the attribute is associated with the prediction model; In response to determining that the attribute is associated with the prediction model, the prediction model associated with the attribute is executed using the received value to generate a predicted value using the attribute's score and confidence factor; When the value is derived from the assessment initiated by the organization associated with the user, the predicted value is stored in the database in the record associated only with the user and in the record associated with both the organization and the user; and When the value is derived from an assessment not initiated by an organization associated with the user, the predicted value is stored in the database in a record associated only with the user. 21. The system of claim 20, wherein the user module is further configured to: Determine whether to authorize a second organization with at least one account regarding access to the controlled service to view the received value; and When the second organization is authorized to view the received value, the received value is stored in the database in the record associated only with the user and in the record associated with both the second organization and the user, wherein access to the record associated with both the second organization and the user by a third party is controlled by the user. 22. The system of claim 21, further comprising a data risk tolerance specialist module executed by the hardware processor, the data risk tolerance specialist module being configured to perform a risk tolerance assessment for the user to generate a risk tolerance for the user; The user module is configured to determine whether to authorize the second organization to view the received value in the following manner: The privacy filter is assigned to the user based on the aforementioned risk tolerance; and Determine whether the privacy filter allows the received value to be shared with the second organization. 23. The system of claim 22, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by receiving answers to risk tolerance questions from the user. 24. The system of claim 23, wherein the data risk tolerance quotient module is configured to perform the risk tolerance assessment for the user by calculating a risk tolerance score associated with the answer to the risk tolerance question. 25. The system of claim 22, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by monitoring user behavior. 26. The system of claim 22, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by receiving adjustments to the risk tolerance from the user. 27. The system of claim 20, wherein the user module is further configured to: Determine whether to authorize a second organization with at least one account regarding access to the controlled service to view the predicted value; and When the second organization is authorized to view the predicted value, the predicted value is stored in the database in the record associated only with the user and in the record associated with both the second organization and the user, wherein access to the record associated with both the second organization and the user by a third party is controlled by the user. 28. The system of claim 27, further comprising a data risk tolerance specialist module executed by the hardware processor, the data risk tolerance specialist module being configured to perform a risk tolerance assessment for the user to generate a risk tolerance for the user; The user module is configured to determine whether to authorize the second organization to view the predicted value in the following manner: The privacy filter is assigned to the user based on the aforementioned risk tolerance; and Determine whether the privacy filter allows the predicted value to be shared with the second organization. 29. The system of claim 28, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by receiving answers to risk tolerance questions from the user. 30. The system of claim 29, wherein the data risk tolerance quotient module is configured to perform the risk tolerance assessment for the user by calculating a risk tolerance score associated with the answer to the risk tolerance question. 31. The system of claim 28, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by monitoring user behavior. 32. The system of claim 28, wherein the data risk tolerance module is configured to perform the risk tolerance assessment for the user by receiving adjustments to the risk tolerance from the user. 33. The system of claim 20, wherein the user module is further configured to receive permission from the user to store the received value. 34. The system of claim 33, wherein the user module is further configured to determine whether a user license is required to store the received value. 35. The system of claim 20, wherein the user module is further configured to: Provide a first personalized assessment tool for execution by the user, wherein the result of the first personalized assessment tool includes the received value; and Provide the records associated with the organization and the user, when the user authorizes, for creating a second personalized assessment tool for the user to perform. 36. The system of claim 20, wherein the user module is further configured to encrypt the received value before storing it in the database in a record associated only with the user, in a record associated with the organization and the user, or a combination thereof. 37. The system of claim 20, wherein the user module is further configured to provide a temporary password that allows access to the received value stored in the record associated with the organization and the user. 38. The system of claim 20, further comprising a directory module executed by the hardware processor, the directory module being configured to assign an identifier to the record associated with the user, wherein the user module uses the identifier to locate and access a portion of the record associated with the user. 39. The system of claim 20, wherein the database is located in at least one data storage server. 40. The system of claim 39, wherein the hardware processor is located in a server communicating with the at least one data storage server. 41. The system of claim 39, wherein the hardware processor comprises a plurality of processors, the plurality of processors comprising at least two of the following: At least one directory processor, which communicates with and provides access to the at least one data storage server; At least one user model processor that communicates with the at least one directory processor; At least one analysis processor that communicates with the at least one user model processor; At least one network processor communicating with the at least one user model processor; At least one application processor communicating with the at least one user model processor; and At least one user device that communicates with at least one of the at least one network processor and the at least one application processor. 42. The system of claim 41, wherein: The at least one directory processor is placed in at least one directory server; The at least one user model processor is placed in at least one user model server; The at least one analysis processor is located in at least one analysis server; and The at least one network processor is located in at least one network server.