Online identity management

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application No. 61/411,957, filed Nov. 10, 2010 the disclosure of which is hereby incorporated by reference in its entirety.

BACKGROUND

It is increasingly common for people, especially younger individuals including children, to have one or more online profiles. However, many parents do not know if their child's profile is visible to all and have set no rules for their children's use of social networks. As usage of this medium has exploded and adoption has accelerated, the risks for misuse have also grown. One need only read the latest headlines to see the impact that social media has had on children who have been exposed to cyberbullying, predators, pedophiles, identity thieves, and other dangerous individuals. These risks and activities are exacerbated by the fact that teens are increasingly using these online services from their mobile phones, which makes it more difficult for parents to protect their children from devastating consequences. This combination of mobility, lack of privacy, and viral messaging has made risks to children and their safety and reputation greater than ever.

SUMMARY

Described herein are systems and methods for enabling parents to monitor online activities across multiple sites and multiple platforms, as well as monitor activities of other children that may involve their children, such that they can protect them from inappropriate content that can be intercepted in real time, for example.

In one embodiment, a method of providing information to a guardian of a minor regarding activities of a minor comprises receiving information from a guardian of a minor indicating one or more delivery mediums for receiving information regarding activities of the minor, receiving information from the guardian identifying one or more events of interest to the guardian, scanning a plurality of online data sources including at least one social network for information regarding the minor, wherein information regarding the minor includes information provided by the minor and information provided by one or more third-parties that refers to the minor, parsing text portions of the information to identify text matching one or more keywords or patterns indicative of one or more of the identified events, scanning image portions of the information to identify objects matching one or more objects indicative of one or more of the identified events, and determining a risk score for the minor based on at least a quantity of identified text and identified objects.

In one embodiment, a method of providing real-time information regarding activities of an individual comprises receiving, from a computing device of a monitoring entity, at least a name of a target individual for which information is desired, periodically accessing or receiving information from one or more social media networks for information regarding the target individual, analyzing the information regarding the target individual to determine whether any of the information is indicative of a high risk activity, and in response to determining that one or more high risk activities are in the information, initiating transmission of a real-time alert to a computing device of the monitoring entity.

In one embodiment, a system for monitoring online activate impacting a user comprises a discovery engine configured to discover one or more networks in which the user is involved or mentioned, a data extraction engine configured to extract data from the networks discovered by the discovery engine, an analytics engine configured to interpret the data extracted by the data extraction engine to identify information that may help or hurt the user's privacy, reputation or safety, and a reporting engine configured to capture the data generated by the analytics engine and presenting it in a single unified view.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an identity scanner in communication with multiple data sources.

FIG. 2 is a flowchart illustrating one embodiment of a method for accessing data from one or more data sources and determining when alerts should be provided.

FIG. 3 is a sample user interface that provides information regarding a target's activities online.

FIG. 4 is a sample mobile interface that provides a real-time stream of events and/or alerts regarding a target individual.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Embodiments of the disclosure will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the disclosure. Furthermore, embodiments of the disclosure may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the embodiments of the disclosure herein described.

Although the description provided herein refers to individuals, consumers, or customers, the terms “user,” “individual,” “consumer,” and “customer” should be interpreted to include groups of individuals, such as, for example, married couples or domestic partners, organizations, groups, and business entities.

FIG. 1 is a block diagram of an identity scanner 100 in communication with multiple data sources. In this embodiment, a monitor user device 102 is in communication with the identity scanner 100, which is configured to scan various data resources to identify information regarding a target, such as a minor. A monitoring entity, such as a parent, guardian, organization, or other person that is responsible for a target individual (or simply “target”), such as a child or other minor, operates the monitor user device 102 that is configured to receive monitor information from the identity scanner 100. In this embodiment, the identity scanner 100 scans one or more of the data sources 106-109 for information regarding activities of the target. The information scanned on the various data sources may include information provided by the target (e.g., posts from the target on a social networking site) and/or information provided by third parties that relates to the target (e.g. photos uploaded by a party host that include images/information associated with the target or information provided by friends of the target). Thus, the identity scanner 100 can access many different sources of information, identify information indicative of risks to the target (or, in some embodiments, can identify positive activities of the target), and alert the monitoring entity to the identified activities, possibly preventing harm or other adverse actions towards the target.

The example configuration of FIG. 1 includes one or more phone networks 106, one or more weblogs (or simply “blogs”) 107, one or more social networks 108, and one or more other networks 109. Each network includes one or more data sources, such as publicly available data (e.g., publicly available social networking information), privately accessible data (e.g., private data on a blog) accessible through browsers, ftp software, specialized APIs, and/or other means. Thus, some data sources may be accessed by the identity scanner 100 without receiving credentials from the monitoring entity (for a blog associated with the target), while others may require that the monitoring entity provide credentials (e.g., login and password) to allowed the identity scanner 100 to access. In other embodiments, any number of data sources may be accessed and scanned in order to identify information associated with the target.

Social networks 108 are web services and/or websites that are configured to permit users to post or otherwise transmit information (e.g., about themselves) and publish and share information on a one-to-many basis in real-time (or near real-time). A few current examples of social networks include Facebook™ Twitter™, Friendster™, Yelp™, Myspace™, LinkedIn™, and ShutteryFly™. Information submitted to social networks may be in text, images, audio files, video files or any number of other multimedia files that may relate or otherwise be shared by the user.

Phone networks 106 include information regarding phone traffic, such as phone calls, SMS (short messaging service), MMS (multimedia messaging service), files (e.g., apps) downloaded on mobile phones, data transmitted or received from mobile phones, usage information such as number of calls made, phone numbers called, time of day, number of text messages sent, amount of data transmitted, features that are enabled on the phone, phone make/model information, and/or any other data related to phones. Phone data may also include geolocation data from mobile phones, such as from the target user device 104 and/or devices of friends/family/affiliates of the target. Phone data may be provided by mobile services providers.

Weblog networks 107 include data from weblogs (or “blogs”). Often data on blogs is publicly available, but some blogs require authentication (similar to authentication that may be required to access social networks or phone networks).

Other networks 109 may include any other types of data sources. For example, location data may be received from location-based services such as Foursquare™ and Gowalla™, or could also be extracted from other sources such as posted digital pictures (cameras often stamp location data on pictures), phone network 106 data (e.g., call origination information), location information set forth in one or more posts on social networks 108 (e.g., “I am in Los Angeles”) or any number of other means for establishing the location of the target at a given day/time.

In one embodiment, the monitor (e.g., the guardian of the target child), provides preferences for scanning the data sources for information regarding the target and/or rules for reporting locate information. In one embodiment, the identity scanner 100 scans at least some of the data sources frequently (e.g., constantly or periodically) in order to obtain information regarding the target that can be reported to the monitor and 80 real-time manner.

Example System Configuration

In the embodiment of FIG. 1, the network 160 may include any combination of communication networks, such as one or more of the Internet, LANs, WANs, MANs, etc., for example. In the embodiment of FIG. 1, the identity scanner 100 includes a computing system having one or more computing devices (e.g., computers). The computing system may include, for example, a single computing device, a computer server, or a combination of one or more computing devices and/or computer servers. Depending on the embodiment, the components illustrated in the identity scanner 100 may be distributed amongst multiple devices, such as via a local area or other network connection. In other embodiments the identity scanner 100 may include fewer and/or additional components that are illustrated in FIG. 1.

The exemplary identity scanner 100 includes one or more central processing units (“CPU”) 105, which may each include one or more conventional or proprietary microprocessor(s). The identity scanner 100 may further include one or more memories 130, such as random access memory (“RAM”), for temporary storage of information, a read only memory (“ROM”) for permanent storage of information, and/or a mass storage device 120, such as a hard drive, diskette, or optical media storage device. The memory 130 may store software code, or instructions, for execution by the processor 105 in order to cause the computing device (e.g., the identity scanner 100) to perform certain operations, such as determining collection actions for respective consumers.

The methods described and claimed herein may be performed by any suitable computing device, such as the identity scanner 100, or possibly the monitor user device 102, or the target user device 104. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer readable medium. A computer readable medium is a data storage device that can store data, which can thereafter be read by a computer system. Examples of a computer readable media include read-only memory, random-access memory, CD-ROMs, magnetic tape, flash drives, and optical data storage devices.

The identity scanner 100 is generally controlled and coordinated by operating system software, such as Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Vista, Windows 7, Windows Server, Windows Mobile, Unix, Linux (including any of the various variants thereof), SunOS, Solaris, mobile phone operating systems, or other operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X or iPhone OS. In other embodiments, the identity scanner 100 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.

The exemplary identity scanner 100 may include one or more input/output (I/O) devices and interfaces 110, such as a keyboard, trackball, mouse, drawing tablet, joystick, game controller, touchscreen (e.g., capacitive or resistive touchscreen) touchpad, accelerometer, and/or printer, for example. The computing device may also include one or more multimedia devices 140, such as a display device (also referred to herein as a display screen), which may also be one of the I/O devices 110 in the case of a touchscreen, for example. Display devices may include LCD, OLED, or other thin screen display surfaces, a monitor, television, projector, or any other device that visually depicts user interfaces and data to viewers. The identity scanner 100 may also include one or more multimedia devices, such as speakers, video cards, graphics accelerators, and/or microphones, for example.

In the embodiment of FIG. 1, the I/O devices and interfaces 110 provide a communication interface to various external devices via the network 160. For example, the identity scanner 100 may be electronically coupled to the network 160 via a wired, wireless, or combination of wired and wireless, communication link(s). The network 160 may allow communication with various other computing devices and/or other electronic devices via wired or wireless communication links.

In the embodiment of FIG. 1, the identity scanner 100 includes a discovery module 180, an extraction module 150, an analysis module 170, and a reporting module 170, which are each described in further detail below. The term “module,” as used herein, refers to any combination of software, firmware, and hardware. For example, certain modules comprise only software code that may be executed by a computer processor, such as the CPU 105. Modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Hardware modules may include connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.

Example Modules

In the embodiment of FIG. 1, the identity scanner 100 includes four modules: a discovery module 180, an extraction module 150, an analysis module 170, and a reporting module 170. In this embodiment, each of the modules is shown as part of the identity scanner 100. However, in other embodiments, the modules may be distributed across multiple devices, and may be controlled and/or operated by multiple different entities. In other embodiment, the identity scanner 100 may include fewer and/or different modules than are illustrated in FIG. 1.

In one embodiment, the identity scanner 100 is configured to receive information from a monitoring entity (e.g., guardian of a minor) requesting monitoring of activities of a target (e.g. a minor). For example, the request may be received via a web interface, by phone, in person, or in any other manner. In some embodiments, the monitoring entity must have a relationship with the target that justifies monitoring. For example, the monitoring entity may be required to be a parent or guardian of the target, and the identity scanner 100 may require authentication information that satisfactorily proves that the monitoring entity truly is the guardian or parent of the target.

In one embodiment, the monitoring entity provides one or more identifiers that are connected with that target (“Target Identifiers”). Target Identifiers may include, for example, the name, address, cell phone number, online identities, email address, handles/nicknames, friends, and the like. The monitoring entity may also provide one or more preferences or settings, such as the frequency and/or urgency of notifications, mobile alerts, and other settings that can impact when a user receives a report, as well as a format (e.g., SMS, MMS, email, web pages, mobile apps, etc.) for receiving alerts and/or other reports from the identity scanner 100. Depending on the embodiment, the monitoring entity may establish rules that indicate any combination of delivery mediums and delivery timing (e.g., urgent, daily, weekly, etc.) for activities matching particular criteria. For example, the monitoring entity may indicate that urgent alerts are transmitted via SMS messages to a mobile device of the monitoring entity (e.g., a cell phone of a guardian) in response to detection of a high risk event (also referred to as high risk “activities”) of the monitored individual, while also indicating that lower risk events, such as activities related to use of profanity, are only provided in a weekly report provided via email to an email address of the monitoring entity. In other embodiments, any other user rules may be established for reporting of various data related to the target individual.

The discovery module 180 is configured to identify one or more data sources, such as the data sources 106-109 of FIG. 1, to scan, monitor and/or receive information from, in order to potentially identify information regarding the target. In one embodiment, one or more of the data sources may be supplied by the monitoring entity, such as via a web interface that allows selection of social networking sites and possibly authentication information that is usable to access private information of the target on the social networking sites. In some embodiments, the discovery module 180 scans a plurality of data sources to determine which sources may have information regarding the target, without the monitoring entity providing information regarding the plurality of data sources. For example, the discovery module 180 may scan various (hundreds, thousands, or more) data sources (e.g., the data sources 106-109) using various portions of the target identifiers for any accounts that may be linked to (or otherwise associated with) the target. In one embodiment, the discovery module 180 can optionally present one or more potential “hits” to the monitoring entity for confirmation. For example, if Cindy Smith is the name of the target and the discovery module 180 discovers thirty-three different “Cindy Smith” profiles on various social networks, the discovery module 180 may present a short summary of each possible matching account and ask the monitoring entity to select which account, or accounts, are associated with the target. Once one or more accounts have been discovered, the discovery module 180 accesses and/or retrieves data that can be extracted from the various data sources that are indicated as associated with the target (e.g., by manual input from the monitoring entity and/or by automatic scanning of data sources by the identity scanner). In one embodiment, the identity scanner 100 has access to application programming interfaces (APIs) that may be used by various data sources so that data may be more easily accessed from the respective data sources.

The extraction module 150 receives information located by the discovery module and extracts meaningful data from the raw data. In other embodiments, the extraction module 150 also periodically accesses data from one or more of the data sources. The extraction module 150 is configured to remove the noise and convert useful data into a form and format that can be stored for further analysis. For example, the extraction module may be configured to determine that there is an abundance of contextual information that often gets jumbled with relevant information when making complex queries and reduce the impact of such data by the analysis module 170 (or entirely remove such “noise” data).

In one embodiment, the extraction module 150 establishes and monitors one or more activity feeds 215 to monitor and extract data realtime data from various data sources. For example, APIs for the various data sources may be used to received realtime information from respective data source. In one embodiment, activity feeds may include automated instruction to retrieve and store data generated by the target on one or more monitored data sources. Activity feeds could include status updates, posted pictures, videos, comments, phone called, geolocation-based check-ins, or any number of other forms of electronic content. Activity feeds may include any content posted by the user being monitored and may also include information that is posted about the user by a third party. For example, certain social media sites enables photo “tagging” on their service. An activity feed may be to retrieve picture that tag the target and perform analysis of the picture as discussed below.

The analysis module 170 accesses the extracted data and applies one or more rules and/or algorithms to identify data of interest in the data. In one embodiment, the analysis module 170 applies rules to identify “factors” that are usable to generate one or more risk scores for target. In one embodiment, rules are configured to represent respective events associated with the target. For example, a first rule may have criteria configured to detect alcohol use and a second rule may have criteria configured to detect a high risk of physical danger to the target. Such rules may include analysis of natural language processing and/or image processing algorithms in order to identity such factors, which may include positive factors (e.g., reward factors) and/or negative factors (e.g., risk factors). Factors may be weighted to indicate a severity, strength, or importance of a particular factor. For example, factors may be associated with a weighing, such as 1-100, on 1-10, A-F, or any other scale. Similarly, factors may be weighted into low risk, medium risk, and high risk factors, for example. Identification and weighing of factors may be based rules for identifying various factors. For example, the analysis module 170 may identify a risk factor for a target in response to receiving an image that was taken at a party and using an image processing algorithm to identify the presence of one or more risk items, such as a beer bottle, nudity, weapons, drug paraphernalia, in the image. Depending on the embodiment, presence of multiple objects related to a negative factor (e.g., risk factor) even and/or the same objects in multiple images, may result in recording of multiple negative factors and/or or change of the weighting of the factor to indicate an increased risk (e.g., a negative factor may be changed from a low risk factor to a high risk factor in response to identifying risk items in photos from multiple friends of the target within a short time period.)

Similarly, the analysis module 170 may employ one or more natural language processing algorithms to “read” data (e.g., posts or links of the target or referring to the target) and map them back to one or more “topics” that may each be associated with negative or positive factor. For example, topics may be parties that the target wants to attend, events that the target commented on, slang drug terms, profanity, discussion of family members, or any number of other suggestive or provocative information that can be interpreted associated as a risk item. Similarly, the analysis module 170 could be employed to identify positive factors, such as in response to identifying pictures from family events, sharing links to reliable news stories or educational sites, or otherwise engaging in conversations that appear to have a positive influence and reflect well on the target. Factors associated with natural language processing may be weighted in a similar manner to those discussed above with reference to image processing.

In one embodiment, the analysis module 170 analyses the factors that have been identified in the extracted data, and uses the factors to generate one or more risk scores that may be provided to the monitoring entity in various manners. Additionally, the underlying data, e.g., photographs, text, phone calls, etc., that triggered the factor may also be provided to the monitoring entity in various manners. In one embodiment, a scoring report provides a summary of the located negative and positive factors, and/or provides details of the data that was analyzed to trigger each factor. For example, a report may be provided to the monitoring entity that includes a list of risks and rewards associated with the target with links to stored data (e.g., from the data sources) that can be view, as desired by the monitoring entity. In one embodiment, only certain types of factors may be reported to the monitoring entity, such as based on system defaults and/or preferences of the monitoring entity. For example, low risk factors may not be individually reported to the monitoring entity, but may still be used in determining one or more risk scores for the target.

Example Methods

Depending on the embodiment, the methods described with reference to the flowchart of FIG. 2, as well as any other methods discussed herein, may include fewer or additional blocks and/or the blocks may be performed in a different order than is illustrated. Software code configured for execution on a computing device in order to perform the methods may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, hard drive, memory device or any other tangible medium. Such software code may be stored, partially or fully, on a memory of a computing device, such as the identity scanner 100, and/or other computing devices illustrated in the Figures, in order to perform the respective methods. For ease of explanation, the method will be described herein as performed by the identity scanner 100, which should be interpreted to include any one or more of the computing devices noted above and/or any other suitable computing device.

FIG. 2 is a flowchart illustrating one embodiment of a method of identifying and scanning data sources, such as data sources 106-109 of FIG. 1, for information regarding a target individual, and providing alerts to a monitoring entity in response to identification of information that matches rules.

Beginning in block 210, the identity scanner 100 receives information regarding the target individual (“target”). In some embodiments, multiple targets may be identified by a monitoring entity. For example, a parent of four children may provide information regarding each of the four children so that each child is a target of the identity scanner 100, and the parent receives alerts regarding each of the four children. However, for ease of discussion, the methods and systems discussed herein are refer to only a single target. All systems and methods should also be interpreted as covering monitoring of multiple targets at the request of a single monitoring entity. As noted above, the target identifiers may include various types of identification information, such as name, address, social networks frequented by the target, blogs operated by and/or visited by the target, nicknames, login names, credential information for sites having private information regarding the target, and/or any other information that is useful in allowing the identity scanner 102 to identify and analyze information regarding the target.

Next, in block 220, the identity scanner scans the network sites for information regarding the target. In the embodiment of FIG. 1, the identity scanner 100 includes a discovery module that identifies data sources to be monitored for activity related to the target, and an extraction module that extracts data regarding the target. In other embodiments, these modules may be combined or further separated. Thus, various hardware and software configurations may be used to identify data sources to be scanned and/or scan those data sources for information regarding the target. As noted above, the information regarding the target may include publicly available information (e.g., information posted on a publicly accessible blog) or privately held information (e.g., information on a social networking site that is only accessible to the target or a group of friends to the target). Depending on the embodiment, the identity scanner 100 may retrieve the information by scraping websites or other data structures provided by the network sources, or may use APIs, or other interface protocols, to access data structures that are not necessarily displayed in user interfaces.

In one embodiment, the information regarding the target includes not only raw data from the data sources, but also includes derivative data that is generated based on the raw data. For example, image processing software may be used to process image data from the data sources in order to identify one or more of various objects of interest to monitoring entities. For example, the image processing software may include a list of hundreds, thousands, or more objects each having respective criteria for locating the objects in image data. As noted above, negative or positive factors, which may be associated with various information, may be used to generate risk scores for reporting to the monitoring entity. In one embodiment, the analysis module 170 accesses rules (e.g., system default and/or custom rules from the monitoring entity) for identifying positive of negative behaviors or events to report to the monitoring entity, such as based on types and/or quantity of positive and negative factors identified in the information.

In one embodiment, factors may be identified based on objects being identified in a photo, or possibly a series of photos having a defined relationship. For example, a negative factor (possibly having a high weighting) may be identified in response to location of a photograph including the target (using image processing software or based on text describing content of the photo) and two or more alcoholic beverages (e.g., using image processing software to identify likely alcoholic beverages in the image data). Thus, the negative factor may be stored with an association to the images that triggered the risk factor, and may be the basis of one or more alerts that are transmitted to the monitoring entity. In a similar manner, language processing software may be used to process text data from the data sources in order to identify one or more of various keywords or phrases of interest to monitoring entities. For example, the text processing software may include a list of keywords of interest, as well as various combinations of words and/or patterns of words (e.g., using regular expressions or any matching logic). The keywords, or combinations of keywords or patterns, may be linked individually, or as groups, to positive or negative factors. For example, a combination of three words (possibly within a defined proximity to one another) from a list of 20 words related to alcohol use may trigger a negative factor for the target. The negative factor me then be used as the basis for matching an alert rule (see discussion of block 230 below) and/or may be used in calculating one or more risk scores for the target.

In block 230, the identity scanner determines whether factors associated with the target, and possibly other information regarding the target, match one or more alert rules. Alert rules may be established by the monitoring entity and/or may be based on the default monitoring rules established by the provider of the identity scanner functionality. Alert rules may indicate multiple types of alerts, mediums of delivery of alerts, and criteria for sending such alerts. In one embodiment, the monitoring entity may indicate that negative factors are reported to the monitoring entity in a real-time manner, such as via SMS messages to a mobile device of the monitoring entity. Similarly, the monitoring entity may only want alerts in a realtime manner if a certain combination of factors are identified with a certain time frame and/or factors with a certain weighting. For example, alert rules may indicate that alerts are transmitted in response to a risk factor sum of a predetermined amount within a predetermined time period. For example, a real-time alert may be transmitted if negative factor sum exceeds 20 within any 60 minute time period. Depending on the embodiment, the negative factor sum may be offset by positive factors within the same time period, and certain factors may be weighted such that they add less than one or more than one to the negative factor sum.

If one or more alert rules are matched in block 230, the method continues to block 240 where an alert is transmitted to the monitoring entity (or other entity identified by the monitoring entity, such as a law enforcement agency). The alert may be transmitted according to default rules or based on preferences of the monitoring entity. For example, the identity scanner 100 may have default rules to transmit alerts reporting factors of a first type (e.g., those categorized as high risk or having a certain weighting) by SMS, while sending alerts reporting factors of a second type (e.g., those categorized as low risk or having a certain weighting) in weekly e-mail digest and on a web portal. In one embodiment, the monitoring entity can customize the delivery mediums for various alerts.

FIG. 3 is a sample user interface that displays information regarding a target. The sample user interface 300 may be available to the monitoring entity after logging into a network accessible portal, for example. The user interface may be made available to the monitoring entity and any other available manner, such as in a standalone application on a computer or mobile phone. The information illustrated in FIG. 3 is exemplary. In other embodiments, additional information, less information, other types of information, information formatted in different manners, etc. may be provided in similar user interfaces.

In the example user interface of FIG. 3, recent activities of the target are displayed in a window 310, in this example data regarding Mary Minor. The first alert indicates that Mary Minor texted a user on a “no-contact” list of individuals provided by the monitoring entity. For example, the monitoring entity may establish a list of individuals that, when contacted by the target in any manner (e.g., text messages, phone calls, online chat, etc.) triggers a factor that matches an immediate alert rule. The alert rules may include frequency criteria for contacts with the indicated individuals, temporal criteria, criteria requiring contact with two or more individuals, or any other combination of criteria that must be met before an alert is transmitted. While factors may not trigger an immediate alert, the factors may still be included in information provided to the monitoring entity (e.g., the user interface of FIG. 3) and/or used in calculating one or more risk scores.

In the embodiment of FIG. 3, the recent activities window 310 provides a real-time “ticker” of factors identified for the target. In this example, high risk factors are highlighted, such as by bolded text, as used in the last factor shown in the recent activities window 310. As discussed above, the high risk factor may be provided to the monitoring entity in one or more other mediums, such as by a SMS or automated phone call.

The sample user interface of FIG. 3 also includes a score window 320 that provides various risk scores for the target. In this embodiment an overall Risk Score of 80 has been assigned to the target, and category particular risk scores of 56 for privacy, 93 for reputation, and 87 for safety are also displayed. These category risk scores provide the monitoring entity with information on risk levels for particular attributes of the target's identity. In one embodiment, “privacy” indicates how private a target's profile on one or more social media sites is and how many friends can see the target's updates, “reputation” indicates the extent to which the target is doing things to help or harm their reputation, and “safety” indicates the extent to which the targets safety is at risk. In other embodiments, fewer or additional category risk scores may be provided. For example, a health risk score may be provided.

The score window 320 also includes an indication of a risk setting for the target, in this case “strict.” In one embodiment, the identity scanner includes one or more pre-set (and/or user-customizable) scrutiny levels (e.g., strict, moderate, lenient, etc.) that may be selected by the monitoring entity in order to calibrate the identity scanner to the particular needs of the monitoring entity. For example, a “strict” scrutiny level may be selected for a young teenager with very conservative parents, while a “moderate” or “lenient” scrutiny level may be selected for older teenagers, possibly with less conservative parents. The scrutiny levels may affect criteria for identifying factors, alert criteria for determining when and how to transmit alerts, and how one or more risk scores are calculated. For example, Mary Minor may have a risk score of less than 80 if the risk settings are changed from strict to moderate or lenient.

In one embodiment, each of the risk scores includes a link that provides additional information regarding calculation of the respective risk score selected. For example, if the safety risk score is selected, a new user interface (e.g., a pop-up window or a separate window) may be provided, which indicates factors that contributed to the calculated risk score and possibly the underlying data (e.g., text, calls, messages, photos, posts, etc.) that caused the factor to be recorded.

In the embodiment of FIG. 3, the user interface includes an option to view historical risk scores, such as in a chart, graph, or other format. The historical risk scores may be provided in a separate user interface, a pop-up window, or in any other format. The historical risk scores may include one or more category risk scores, as well as the overall risk or.

FIG. 4 illustrates an exemplary mobile device with alert messages received from the identity scanner 100 displayed. In the embodiment of FIG. 4, the alerts are in the form of text messages that are delivered in realtime (or substantially realtime) after an alert rule is matched. For example, the alert 410 may have been sent in response to triggering of a negative factor detected by posting of a photo in which Mickey is tagged. The negative factor may alone be enough to trigger an alert rule. In other embodiments, the alert rules may include other requirements, such as presence of alcohol or other substances in the photo. The alert 420 may have been sent in response to geo-location data from Mickey's cell phone indicating that she is outside of an allowed region defined by the monitoring entity (e.g., an area around Mickey's home and school). The alert 430 may have been sent in response to analysis of an image posted by Mickey that is believed to include a knife. In other embodiment, alerts 410, 420, 430 are transmitted in other manners and include less or additional information regarding the match rule and/or the associated factors.

SUMMARY

Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, and partially or fully automated via, software code modules executed by one or more general purpose computers. For example, the methods described herein may be performed by an Information Display Computing Device and/or any other suitable computing device. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer readable medium. A tangible computer readable medium is a data storage device that can store data that is readable by a computer system. Examples of computer readable mediums include read-only memory, random-access memory, other volatile or non-volatile memory devices, CD-ROMs, magnetic tape, flash drives, and optical data storage devices.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated. The scope of the invention should therefore be construed in accordance with the appended claims and any equivalents thereof.