SOCIAL NETWORK DRIVEN INDEXING SYSTEM FOR INSTANTLY CLUSTERING PEOPLE WITH CONCURRENT FOCUS ON SAME TOPIC INTO ON TOPIC CHAT ROOMS AND/OR FOR GENERATING ON-TOPIC SEARCH RESULTS TAILORED TO USER PREFERENCES REGARDING TOPIC
A machine-implemented social networking system builds up and repeatedly refreshes a hierarchy tree containing topic nodes. New nodes are added as new topics emerge in online public forums. Each topic node can link to an on-topic real time chat room whose occupants are currently discussing the topic of the node. A chat room can be pointed to by more than one node if the room is discussing multiple topics. Rooms can migrate from node to node as room topic dynamically changes. A system user who explicitly or inferentially wishes to be invited into a chat room which is on-topic with what the user is currently focused upon can do so by use of a node-seeking automated process. The process operates in the background and seeks out nodes of the hierarchy tree that currently have topics appearing to be the same as or similar to what topics the user appears to have in mind. Content browsing experience of the user is enhanced by addition of an invitations displaying subsystem that automatically invites him or her to co-compatible chat rooms currently discussing the topic(s) the user appears to have in mind. One of the many topics that a user may inferentially have in mind is that of being at a given location as reported by the user's GPS and wondering what best to do at that location and time.
The present disclosure of invention relates generally to real time social networks and to production of on-topic search results including that of automatically producing matches between currently online people for instant engagement in real time with one another in forums such as chat rooms. One aspect of the disclosure relates more specifically to helping isolated online users of a network (or even strangers at a social gathering, e.g., a large business conference) in automatically finding one another at times when they are in the mood to do so and when they have roughly concurrent focus on same or similar content and/or when they have approximately concurrent interest in a same or similar particular topic or topics and/or when they have current personality co-compatibility for instantly chatting with, or for otherwise exchanging information with one another in short order online (or even in person) and for example with regard to the content and/or topic of shared current focus or with regard simply to a likelihood that they have current personality co-compatibility for instantly chatting online (or even in person) with each other and potentially developing focus on a particular topic of common interest. Another aspect of the disclosure relates to providing a real time changing indexing tree having hierarchically interconnected nodes representing topics, where the configuration of the tree changes dynamically in response to real time reactions of users to online content. In one embodiment, nodes of the tree correspond to topics in a dynamically changing topic space and the nodes link to on-topic chat rooms and/or to on-topic search results. Domain and topic nodes in the tree may include unconventional ones such as, My Current Location Is: . . . (fill in the blank with location determined by GPS or other means) and topics under that domain may include, Fun Things to do for My Demographic Group at this location and this time or soon after.
CROSS REFERENCE TO PATENTSThe disclosures of the following U.S. patents are incorporated herein by reference:
-
- (A) U.S. Pat. No. 5,890,152, issued Mar. 30, 1999 to Rapaport, et al. and entitled “Personal feedback browser for obtaining media files”; and
- (B) U.S. Pat. No. 7,430,315 issued Sep. 30, 2008 to Yang, et al. and entitled “Face recognition system”.
The disclosures of the following U.S. patent publications are incorporated herein by reference:
(a) U.S. 2008/0262364 entitled, “Monitoring Apparatus for Monitoring a User's Heart Rate and/or Heart Rate Variation; Wristwatch Comprising Such a Monitoring Apparatus” published Oct. 23, 2008 on behalf of Aarts; Ronaldus Maria;
(b) U.S. 2008/0266118 entitled, “Personal emergency condition detection and safety systems and methods” published Oct. 30, 2008 on behalf of Pierson; Nicholas J.; et al.;
(c) U.S. 2008/0097235 entitled, “Subjective Significance Evaluation Tool, Brain Activity Based” published Apr. 24, 2008 on behalf of OFEK; Einat; et al.;
(d) U.S. 2007/0013652 entitled, “Integrated Chip for Detecting Eye Movement” published Jan. 18, 2007 on behalf of Kim; Dongsoo; et al.;
(e) U.S. 2008/0091512 entitled, “Method and System for Determining Audience Response to a Sensory Stimulus” published Apr. 17, 2008 on behalf of Marci; Carl D.; et al.;
(f) U.S. 2008/0234976 entitled, “Statistical Methods for Multivariate Ordinal Data Which are Used for Data Base Driven Decision Support” published Sep. 25, 2008 on behalf of WITTKOWSKI; Knut M;
(g) U.S. 2005/0149459 entitled, “Automatic creation of Neuro-Fuzzy Expert System from online analytical processing (OLAP) tools” published Jul. 7, 2005 on behalf of Kofman, Gene I.; et al; and
(h) U.S. 2008/0288437 entitled, “Perspective-based knowledge structuring & discovery agent guided by a maximal belief inductive logic”; published Nov. 20, 2008 on behalf of Siregar; Edouard.
The internet is one example of a network supported, public communication and data exchange system that enables isolated users to individually browse through an almost unlimited volume of informational content. Users can peruse through daily, hourly, or even minute-by-minute updated news publications, industry journals, blogs, tweets, list serves, video galleries (e.g., You Tube™), photo galleries (e.g., Flicker™), and so forth. For almost any general or unique topic a given first user may be currently interested in, or focused on, corresponding content is usually available somewhere out on the internet (or via another public information distributing means) for looking at by the first user (if the user knows its URL or other content access pathway to that informational content). The same content is typically available for concurrent study by other users. The specific topic areas that are of interest to each user may span from those that are socially popular (i.e., the latest fads), socially acceptable and/or economically valuable to ones that might be taboo or even border on the illegal. It is not the intent of this disclosure to pass judgment on what topics of focus people may approve of or not approve of, but rather to point out that people's interests and immediate areas of focus (current attention) can be wide, varied over time and can often coincide by happenstance with the same interests of many others or with a same esoteric interest of a highly esoteric handful of other people, where the people who share a topic of interest may be situated (clustered) in a same local community or sparsely spread around the world.
Much of online content (and/or content that is locally stored on a user's local data storage device) is accessed by human users in a relatively non-social framework. That is to say, and by way of example, that a first isolated user in suburban Utah may have been scanning through large volumes of online content while for most of the time exhibiting little interest in the browsed through content. However, surprisingly, in the last few minutes (or longer, or shorter), she began to keenly study and with great interest a particular article in an online posting of “Celebrity Sensations Magazine” (here, a fictitious name for a possible online magazine and not to be confused with a magazine of same or similar name if any exists). Unbeknownst to the first user, another isolated user in rural Nevada (whom the first user has not met) is doing the same thing at about the same time, namely, having settled into looking at the same web page, the same article and also becoming substantially engaged emotionally or otherwise involved with the same material (the same content). The content intake and information appreciation experience for each of the first and second isolated users might be much richer and more satisfactory if only these isolated users could connect online essentially instantly with one another and exchange ideas or insights or even develop new ideas about the specific article that they are now reading and are now substantially engaged with. However, heretofore there was no automated and easy-to-use mechanism available for bringing such isolated online users together at the moment of their concurrent focus on same or similar content and at the moment of their concurrent substantial involvement (e.g., emotional or other involvement) with that content, where for example, the mechanism invites both of them to join a mutually acceptable, real time online chat or another such online informational exchange forum that focuses on the content and/or topic of their concurrent mutual focus.
As known to those skilled in the art of internet chat rooms, so-called instant chats can be invoked in numerous ways, including but not limited to: IRCs (Internet Relay Chats), HTML rooms and Java rooms. When such chat rooms are employed, it appears to a first user that one or more other persons are substantially instantly reading (or otherwise perceiving, e.g., within one or a few seconds) what the first user posts into the chat room frame and that the other person(s) are responding in substantially real time to those actions by, for example, almost instantly writing back (instant back and forth messaging).
As is further known to those skilled in the art of internet chat rooms, such person-to-person interconnections can be private ones or ones open to the public. People who do not know each other (in the real world, in a virtual reality world, or otherwise) generally cannot meet one another for a first time in a private chat room because one must know the other ahead of time (and/or have some pre-existing “friendship” or “chat buddy” relationship with the other) in order to post an invitation and thus induce entry into the private chat room. Thus, in the example given above, the two isolated and concurrent readers of same content in the online Celebrity Sensations Magazine (a fictitious name) will heretofore not have had a convenient means by way of which to join in a private room because they do not know of each other's existence or identity. Moreover, they do not know about the concurrency and commonality of their attention on same content or their interest in apparently the same topic (content and topic are not always the same thing as will be seen below). Thus they have essentially nothing to entice them to then meet in a same online chat room. (private or public). On the other hand, public chat rooms often allow just about anyone who is aware of the room to join in its transactions (e.g., electronic conversations). Because of this complete openness, public chat rooms are often quickly overtaken by so-called “trolls” (a pejorative term for offensive or impolite personalities) and these discussion-hogging people tend to reduce the discourse to a relatively low level of common denominator (e.g., ad hominem attacks, profanity, digression from original topic of discussion, etc.). Thus, useful interchange is very difficult to obtain in wide open public chat rooms and many users who would otherwise enjoy polite and civil discourse with similar minded peers in an online chat room avoid public ones at least for this reason.
The latter situation is unfortunate because much could be gained from exchanges between people (e.g., peers) who may meet each other electronically for a first time and have a concurrent common focus on same or similar content and/or interest in a same or similar topic that they wish to discuss and/or collaborate with others who are also engaged with the corresponding subject matter at that moment. Also, it would be helpful if meeting strangers can somehow increase the odds that they are co-compatible with one another in terms of chat personalities and/or in proficiency regarding the topic or content of common interest.
Online is not the only place where strangers can meet. Large business conferences is another example. Two people can be at a same large business conference and in short walkable proximity of each other but surrounded by hundreds of other people. The two attendees to the conference may not know each other, and yet they may have much to gain if they were to meet in person and exchange information in real time about specific topics of concurrent common interest. But since they don't know each other and are not aware of their mutual concurrent interest in certain specific topics and of their physical proximity to one another, as well as of their co-compatibility for chatting with one another, it is likely that without more, they will not meet. It will be a missed opportunity for mutual gain. Heretofore, an easy to use automated system was not available for joining together people who have same topics of concurrent interest on their minds and who are co-compatible for chatting with one another either online or even in person.
SUMMARYStructures and methods are provided in accordance with the present disclosure of invention for creating a social network driven indexing system that can, as one option, instantly cluster people with concurrent focus on a same topic into currently on-topic chat rooms and that can additionally or as an independent option, generate on-topic search results tailored to user preferences regarding the topic of current interest. In one embodiment, the system almost instantly provides first links (e.g., invitations) to online chat rooms (or to other substantially real time informational exchange forums provided via a wired or wireless communications network) for people who happen to be focused on same or similar content at substantially the same time, and/or who happen to be interested in a same or similar topic and/or who are chat-wise co-compatible with one another. The offered first links or invitations allow such people (including those who probably would not have otherwise linked to each other) to meet within the offered chat rooms (or even in person in some instances) and to share information or discussion regarding, for example, same or similar content of current mutual focus and/or same or similar topics of current mutual interest. In the same or another embodiment, the system almost instantly provides second links (e.g., further research and/or activity suggestions) to online data resources whose content currently substantially relates to a topic that appears to currently be on the user's mind. The offered second links or further research/activity suggestions allow people to locate on-topic additional material (e.g., the most current on-topic material) even without joining a chat room. In one embodiment, the provision of invitations and/or recommendations occurs by machine autonomous action—in other words, the user is not consciously participating in generation of the invitations and/or recommendations, except perhaps to consciously approve activation or continuance of a benign form of spyware that will spy on the user's current activities and infer from those activities what content, if any, is currently of interest to the user, what topic, if any, is currently on the user's mind and/or what kinds of other people are currently co-compatible for chatting with the user online or otherwise (e.g., even in person).
It is to be understood, Incidentally, that when this disclosure mentions an online web page (online content) that a given user is focusing his or her attention on, the disclosure is not intended to be limiting its scope to HTML or otherwise coded web pages or to content provided exclusively by a user's one computer or exclusively through the internet. Any form of network-provided or broadcast-provided or multi-cast-provided presentation of informational content to users (whether digital or analog) is contemplated. All that is needed is that the user can focus his or her attention on the presented content, that the user's focus can be automatically detected by machine means and that the content can be automatically identified by machine means as content that is substantially similarly also available to other users in roughly the same time span. In other words, the present disclosure contemplates situations where two or more separated users are watching a same live broadcast of a television show (analog or digital), or are almost concurrently watching a same YouTube™ or other online video stream, or are concurrently viewing a pre-recorded show from their personal recording devices (e.g., TiVO™) or are listening to a same radio show, and so forth, and where the identity of the content can be automatically determined by machine means and preferably where the degree of user involvement with the content can also be automatically determined by machine means.
The point being made here is that two or more users can be focusing at roughly the same time on same or similar machine-generated content (e.g., digital content) and an automated means is present for identifying the content they are focusing their attention on at the moment and reporting the occurrence of the same automatically to a reports-collecting and match-making centralized system. The disclosure will be easier to understand however, by first starting with the case where the content presenting apparatus is a user's local data processing machine system (e.g., a user-operated and user-servicing digital computer such as one having a CPU, memory & network interface) and the content being provided can be identified by means of a URL code (Universal Resource Locater code) or other such page identifying code and where the content identifying code (e.g., URL) is already in possession of or directly accessible by software executing on the user's local data processing machine. Also, because the inclusion of heading markers, meta-tags and the like in HTML (HyperText Markup Language) or XML (Extensible Markup Language) coded web pages is understood by those skilled in the art, it will be easier to start with such a commonly understood form of content presentation and explain how topical hints are often invisibly embedded in such content in the form of meta-tags, heading start/stop braces, and the like. In a more complex situation where plural users are watching or listening to a live analog broadcast, for example, of a soccer game, hints about the topic(s) associated with what is being watched (and/or listened to) may have to come from an ancillary real time digital source (e.g., automated captioning text for the deaf for that same content providing channel) whose output can be time-wise synchronized with the analog broadcast content that the users are focusing upon and whose digital output can thus be used to infer a probable topic of common interest then probably present on the plural users' minds. It will be seen that the users can be linked to one another through an on-topic node and that, because the on-topic node serves as sort of a portal for identifying and/or joining together groups of people who probably have a same topic in mind, the on-topic node can also serves as sort of a common collection point for collecting most-current data about the topic where the collected data (e.g., recent or common URL hints) can be collected and ranked based on the type of people who implicitly pass through the portal-like node (e.g., where one type of such people are licensed and/or otherwise credentialed experts in the topic being handled by the on-topic node).
Moreover, it is to be understood that the initial embodiments discussed herein will assume single users each privately positioned in front of his or her personal computer. However, it will be seen later that face recognition software may be used in group situations where different people are taking turns in interfacing with a same computer and the computer may then automatically switch user profiles upon automatically recognizing that a different user is now sitting in front of the computer webcam and computer screen and interfacing with that local client machine.
In one embodiment, structures and methods for collecting content-identifying reports and/or reports about a given user's level of focused interest in that content, operate under the auspices of a distributed and automated match-making and invitations-generating system (MM-IGS). The MM-IGS collects (e.g., uploads) information (Current Focus information, also referred to herein as CFi data) about the content that participating individual users are currently focusing on, about their emotional reactions to the focused upon content, and also additional personhood information about their backgrounds and preferences. Using this information, the MM-IGS automatically generates clustering maps which cluster together in an appropriate co-compatibility space, various ones of plural users who appear to be co-focused on same or similar content, and/or who appear to have same or similar topics on their minds and/or who appear to have co-compatible personalities and/or who appear to have same or similar emotional reactions regarding the topic or content being focused upon. The MM-IGS automatically generates invitations and sends the invitations to closely clustered together ones of its users to thereby invite them to join each other in an online chat room (or other network supported information exchange forum, e.g., a restricted access blog, a peer-to-peer forum) whose occupants are or are expected to be focused upon the same or similar content, on the same or similar topic and/or to exhibit same or similar general emotional reactions to the topic and/or to the focused upon content. Users who accept the invitations are automatically linked to the real time informational exchange forums (e.g., chat rooms) that contain other, similarly invited persons. In this way, people who are interested in same or similar things and who may have not otherwise met each other, are automatically given opportunities to meet and chat in real time in online rooms and perhaps benefit from the exchanges. In one embodiment, if an invitation/recommendation confidence score assigned to a given invitation (or corresponding recommendation) exceeds a predefined threshold, the linking to the chat room or other real time informational exchange forum (or linking to recommended further search results) is performed instantly without waiting for acceptance of the invitation/recommendation. (The invitation/recommendation confidence score can be one that increases as a function of scores assigned to indicate how on-topic the corresponding invitation/recommendation is deemed to be, how co-compatible the corresponding invitation/recommendation is deemed to be, and how interested in the topic the user is deemed to be. If the confidence score is high enough, the corresponding invitation/recommendation is deemed to be sufficiently urgent that the user will want to see it instantly. In one embodiment, the user can switch instant showing of high confidence chat rooms and/or instant showing of high confidence recommended other material on and off as desired and/or change the threshold value needed to trigger instant showing.)
One of the expected benefits of users accepting invitations to, and/or being instantly linked to high confidence ones of chat rooms or other real time information exchange forums is that occupants of chat rooms (or other forums) which initially focus upon a first topic will evolve, develop the topic material and eventually migrate their focus to one or more new topics or subtopics. Migration to new topics or subtopics can result in the adding of new topic nodes to a hierarchical tree containing logically linked topic nodes. The tree thus comes alive to grow and evolve dynamically in response to the dynamic and self-evolving current activities taking place in online chat rooms which run under auspices (patronage) of the tree. Aside from automatically generating invitations to currently on-topic chat rooms, the MM-IGS may also automatically generate links to currently on-topic informational resources such as the latest editorials or blog comments or tweets on a recently emerging topic.
Incidentally, it is to be understood here that when the disclosure mentions online chat rooms to which specific users are invited to enter, the disclosure is not intended to be limiting its scope to internet provided textual chat rooms. Any form of network-provided or broadcast-provided or multi-cast-provided cross-exchange of relatively current informational content between clustered groups of users can benefit. This includes live video conferences and the like. While relatively current online information exchanges (e.g., chat rooms) are preferred, topic nodes of the system may also provide logical links to slower moving (less current) on-topic information resources such as private blogs and private forums or list serves to which occupants gain entry to by invitation only. The point being made here is that users who may have not known of each other or may have not known that they share a concurrent focus in same or similar content and/or a concurrent interest in same or similar topics are automatically identified and are automatically clustered together in a topic space so that common on-topic information they posses (if any) can be conglomerated and so optionally they can be invited to join with each other in some form of machine-assisted current cross-exchange of informational content. While invitation into an online forum is one outcome in accordance with the present disclosure, it is also within the contemplation of the disclosure to independently or supplementally provide recommendations pointing to new online content that corresponds with a topic of current interest to the user, where the new online content is likely to be content that the user has not recently considered.
Once again, for sake of simplicity in this introductory summary, it is assumed that single users are each privately positioned in front of their personal computing devices (e.g., laptop, palm-top, PDA, 3G-cellphone, etc.) and interfacing with a network (e.g., the internet) via that one device and reviewing online informational content and/or privately stored informational content. In such a case and according to one embodiment, so-called Local Activities Monitoring Service(s) (LAMS) software is provided in and executes in each user's on-network and local automated data-processing machines (e.g., client computer). The Local Activities Monitoring Service(s) (LAMS) predominantly executes in the background as a benign form of spyware. The LAMS automatically detects one or more on-display specific content areas of current focus by the local user and/or other portions of content that the user appears to be focusing upon, (e.g., audio output) during a given stretch of time. The specific stretch of time can vary from user to user because some users tend to move quickly through large volumes of content (e.g., many web pages visually scanned per minute) and other users tend to step more slowly through web or other informational content; perhaps reading just a few paragraphs on a same web page over the course of 5 minutes. In one embodiment, behavioral trend determining services are provided either in the LAMS or in the MM-IGS or in both for automatically determining the speeds at which specific users intake different kinds of content and also the speeds at which the users react emotionally or otherwise to the intaken content. The determined speeds are recorded in so-called PEEP files. For example, one user may laugh out loud instantly to a funny cartoon he sees on a web page as he scans through many pages in a single minute. Another user may take several minutes to digest and become angry about some upsetting story she read on another web page (showing her reaction by for example silently frowning). Each user tends to have his or her own personal style for intaking content at a personal intake speed and for reacting to it (at a personal reaction speed), as well as tending to have their own personal styles regarding how they exhibit or express their reactions to the content. So Personal Emotion Expression Profiles (or PEEP's) are developed over time (by local and/or remote trending services) for each user and used to determine the appropriate stretches of time over which each user's local activities are to be gauged. In one embodiment, PEEP's include a minimal focus persistence time specification that defines a minimal amount of time that the given user is required to be detected as focusing upon corresponding content before a corresponding CFi record is recorded for the focused upon content. Content that is focused upon for less than the PEEP specified minimal focus persistence time is ignored in that embodiment and a corresponding CFi record is not recorded for it.
Incidentally, the term “benign spyware” as used above and elsewhere herein is a bit of a misnomer because conventional spyware seeks to make its presence unknown to the spied-upon user and/or spied-upon program. By contrast, the benign spyware discussed herein generally makes its presence and persistent activities known to the spied-upon user and/or his programs, by for example, a blinking “monitoring on” warning being presented on the user's screen. In one embodiment, the user can elect to hide the warning during a session. It is to be understood then, that use of the term, “benign spyware” herein conveys something other than conventional spyware where the latter seeks to conceal its presence from the user.
While the benign spyware is busy detecting and identifying the specific content that its local user is focusing attention on and recording the same (as a Current Focus information or CFi data), the encompassing LAMS is also working in the background to automatically detect one or more indicia of current emotional engagement with, or reaction to, the focused-upon content by the local user. This automated detection of emotional involvement/reaction may be based, for example, on current machine operating activities of the user (e.g., mouse use, keyboard use etc.) and/or on current biometrically detected states of the local user (e.g., increased heart rate, increased breathing rate, increased depth of breathing, increased fidgeting, unusual skin blushing or paleness, up-tilted head and diverted eyes while listening to audio, etc.). The LAMS automatically attaches time stamps (and optionally, geographic location stamps) to each detected and to-be-reported activity (each item of Current Focus identifying or indicating data, or CFi data for short). The detected and to-be-reported activities may be single or compound ones. Examples of single activities might be that the user has been focusing his or her eyeballs (pupils) on the upper left quadrant of the web page for the past one minute or that the user vocalized a sigh over the last 2 seconds. A compound report may indicate that the user just launched a search engine search with certain keywords and at the same time the user's heart rate had increased substantially. Cause and effect are not always concurrent though. Chronological spacings between the two may be indicated for certain users based on their PEEP's and/or other developed profiles. The collected and time-stamped report information (CFi data) can be used for automatically determining what collected pieces of reported user activity probably correlate with other ones (strongly cross-correlate). The collected and time-stamped report information can be ultimately used for automatically determining whether two or more users have sufficient concurrency with regard to same or similar focused upon content and/or with regard to same or similar topic of interest probably on their mind, etc., so as to justify inviting them into a same chat room. If the detected degree of attentive focus on a particular portion of available content and/or if the indicated current emotional involvement with or reaction by the user to that focused-on content output is scored to be above a predetermined threshold, the LAMS (Local Activities Monitoring Service) may automatically generate and store in a buffer one or more Current Focus identifying and/or indicating records (CFi's) where the latter data objects contain data representing the collected physically-based information (about current focused upon content, current biometric behavior, etc.). The CFi's are locally stored by the LAMS in the client machine and then made available for collection (uploading) by one or more on-network Remote Activities Monitoring Services (also referred to as an AARMS) of the MM-IGS system. (In one embodiment, rather than deciding on its own which user activities warrant being reported to the MM-IGS, the LAMS records all activities as buffer-stored CFi's and lets the MM-IGS (the remote match-making and invitations-generating system) sort through the information to determine what might be relevant and what not so relevant for match-making or other purposes.) The AARMS typically executes on one or more remote servers, where the servers are located either at a geographically local data center or at a far away data center. Data centers may be interlinked to form a network interconnected, data processing cloud that provides automated match-making and invitations-generating services (or other services such as that of making automated further research recommendations to users of the MM-IGS system).
Uploaded CFi's from different users are automatically parsed in the AARMS to determine which CFi-contained first data of a given user is to be merged with other recent CFi-contained data of the same user, if at all (and optionally on a weighted basis), so as to provide a more complete and meaningful sampling of current user activities for understanding what content the given user is most likely focusing his or her attention on and what biometric reaction data most likely correlates with the content and with cotemporaneous user activities. As indicated above, for some fast-paced users, a single CFi record or snapshot of content taken over say, a 3 second stretch of time may be sufficient for determining degree of substantial focusing of attention on corresponding content and biometric reaction data that correlates to it (because this user tends to read and react quickly). For other users, a plurality of CFi records or multiple sampling snapshots taken over say, a 10 minute stretch of time may be deemed to be more appropriate because this other user tends to intake content more slowly (especially if it is for a difficult subject area) and/or to respond with additional user activity (e.g., a follow-up search engine use) more slowly and/or to exhibit biometrically detected reaction to the same more slowly. The automated determination of which CFi snapshots (or parts of snapshots) to merge with others can vary with time of day, current user mood (e.g., is the given user sleepy, upset, etc.?) and/or topic (e.g., is the user reading a dense science article or light fiction?). Since each user can be different, in one embodiment, a personalized set of adaptively modifiable knowledge base rules are stored in one or more profiles of each user (for example, in local and/or remote PEEP's of the given user and/or in a personhood defining CpCC profiles of the user, which CpCCp data structure will be detailed below.) A simple example of a CFI's data merging rule might be: IF time=late_evening and topic_type=complex and mood=groggy THEN merge CFi data over time_stretch=15_minutes; IF time=early_morning and topic_type=simple and mood=caffeinated THEN merge CFi data over time_stretch=90 seconds; ELSE merge CFi data over default time_stretch=3_minutes. These personalized CFi data merger rules (knowledge-base rules) may be periodically adaptively changed as the system learns of each given user's personal traits and/or as each user's traits change over time.
The uploaded and optionally parsed and merged CFi-provided data items obtained from each of the different users are then automatically compared to that of other users (or against composite data of ongoing chat rooms) in the MM-IGS for purpose of matching with one another (user-to-user match-making or clustering) and/or for purpose of matching with predefined chat rooms (user-to-room match-making). In one embodiment, closeness of matching or closeness of clustering of users to one another and/or to available rooms is expressed as a machine-utilized co-compatibility distance between users, where more closely matched users are deemed to be less distant from one another in a co-compatibility space and thus are deemed to be closely clustered to one another for purposes of being automatically invited into a common chat room. In other words, when data gleaned from the respective collected Current Focus information records (CFi's) of two or more users indicate a substantial match with regard to content of current significant focus and/or with regard to topic of concurrent interest; or when the collected Current Focus information records (CFi's) of a given first user are found to substantially match the content-related focus and/or topic-related attributes of a preexisting chat room by an online match-making service, the same (or another) online service further compares Current personality-based Chat Compatibility profiles (CpCCp's) of the to-be-joined users (or of the to-be-joined first user and of the averaged members in the potential chat room to which the first user may be invited) to thereby determine if the personalities of the to-be-joined plural users are sufficiently compatible with one another such that they may beneficially (as they see it) exchange information in a common chat room regarding the material of common concurrent focus. If yes, the user(s) having the identified and currently common focus on same or similar content and/or having the same or similar topic of interest currently on their minds, are automatically invited to join in a system-spawned chat room or to exchange information using another real-time and system-supported information exchange mechanism (e.g., a live video web conference or a live voice only conference, etc.), where in one embodiment the invitations are sent to users who also have current personality-based co-compatibility for chatting with each other. While personality-based co-compatibility may be one attribute tested for prior to inviting users to join into a live chat room, it is within the contemplation of the disclosure to generate invitations that are filtered on the basis of other co-compatibility factors such as level of proficiency in a given topic or reputation regarding a hierarchically categorized subtopic within a hierarchal tree having predefined domain nodes, topic nodes and subtopic nodes, etc., as will be detailed below.
Incidentally, throughout this disclosure reference is made to averaged or median or other statistically computed attributes of rooms. In this regard it is to be appreciated that different users may be continuously entering or leaving a given room at relatively fast pace, particularly in the more popular chat rooms of the system. As such the instantaneous average or other statistically computed attributes of the room can be theoretically changing very fast. It may consume too much of system resources to constantly keep track of the instantaneous average or instantaneous other statistically computed attribute(s) of each room. In one embodiment, running averages or the like are recomputed for successive and chronologically spaced apart time windows. The widths of the windows and the spacings may vary from room-to-room, or topic node-to-topic node or domain-to-domain in accordance with system maintained knowledge-base rules. In one embodiment, each chat room's attributes are deemed to be frozen in time for regular intervals; such as frozen in each one of successive 5 minute stretches whose statistics were computed over a window covering, say, the last 2 minutes; as frozen in each of successive 10 minute stretches whose statistics were computed over the last 4 minutes, every 15 minutes as computed over the last 5 minutes, etc., even though users may be constantly entering and leaving the room. The time points at which new room attributes are recomputed and frozen into place may be referred to herein as attribute checkpoints.
In one embodiment, invitations to join one or more chat rooms (or to join other forms of real-time or non-real time informational exchanges) appear on a side area of each user's computer screen in the form, for example, of incoming and enlarging radar blips, dots, growing bubbles, etc. or as otherwise displayed icons. The positions, shapes, sizes, colorations, enumerations, etc., of these icons may be fixed or they may change. The icons may be structured to indicate what on-screen content of current focus they belong to, and/or what general topic they belong to. Alternatively or additionally the icons may be structured to dynamically indicate (e.g., by temporarily glowing) that they logically belong to certain on-screen content when the user hovers a mouse cursor over the content. The invitation icons may be structured to indicate how strongly they correlate to the user's current content area of specific focus or current topic of interest and/or indicate how strongly the chat compatibilities of other invitees correlate with chat compatibility preferences of the user. In one embodiment, invitations to join one or more chat rooms (or to join other forms of real-time informational exchange) first appear as tiny, perhaps semi-transparent and slow moving dots moving in from opposed edges of the user's screen (or window) toward a central area of a top or side banner. As they move inwardly, if they indeed continue to do so, they may grow in size, in degree of nontransparent coloration, and also in degree of on-screen agitation or movement thus becoming larger and more noticeable centralized bubbles (a disposition that represents being at the center of a hypothetical radar scope). This happens as the local user's current point of focus and the local user's current topic of interest (inferred) and the local user's current co-compatibility converge with those of the invitation's chat room or vise versa. On the other hand, if the user's focus on content diverges away from that of the invitation's chat room or if the user's apparent topic of interest moves away from that of the invitation's chat room, or vise versa, the corresponding bubbles reverse direction and they stream away from the center and revert back to less colorful ones, less agitated and sidelined ones that ultimately disappear off of the peripheral edge of the screen or window (beyond the recognizable event horizon from which they emerged). In one embodiment, each of incoming radar dots morphs into an enlarging image of one or more animated talking (silently talking) heads or faces or avatars where the speed of talking or other movement by the avatar heads indicates an attribute of the invitation such as urgency or relevance of the invitation to on screen other content. The talking heads may wear hats and/or labels indicating their related topic and/or name of associated chat room. If the user indicates partial interest in the invitation, by for example hovering a mouse cursor over the invitational image (e.g., talking head), a speech balloon with a snippet of current chat room content may appear and/or a vocalized version of that snippet may be output from the client machine's sound system.
If the user accepts one of the invitations (e.g., dancing bubbles, franticly talking but silent heads, etc.), by for example mouse clicking on an invitation-offering icon or otherwise gesturing acceptance of the corresponding invitation, a corresponding chat room (e.g., a chat window frame) is automatically opened on the user's screen, where the chat room is populated by co-compatible other users such as by current invitation-accepting other users. In this way, two or more co-compatible users such as the above exemplified users who were simultaneously reading a same article in Celebrity Sensations Magazine (fictitious name) in isolation can be united online with one another substantially instantaneously with the understanding that they are interested in a same area of focus if not also in a same topic of interest and that they have been deemed to be co-compatible personality-wise and/or otherwise for chatting with one another about the content material and/or topic of common interest based on a machine-automated matching of their current chat compatibility preference profiles (CpCCp's and/or optional DsCCp's—which are topic related profiles described below) by a centralized online matching service.
While the above teaches an in-the-background and thus user transparent system for generating invitations, it is within the contemplation of the present disclosure to allow users to explicitly request invitations. In other words, a given user may highlight certain in-web-page content; right click his or her mouse and pick an option (in a pop-out menu, not shown) that asks the system to find matching chat rooms for the highlighted content and to invite the given user into at least one personality-wise co-compatible room among the matching chat rooms. It is further within contemplation of the disclosure to allow users to explicitly search for chat rooms under specific hierarchy nodes of the system where the searched for chat room meets explicit search requests of the user. For example, the user may explicitly request an invitation to a chat room under the domain “sports” and topic “soccer” where other user “Sam” is already a participating occupant inside that chat room. In other words, if users want to be explicitly involved in the decision making of which rooms they get invited into, they can. More generally though, the invitations generating process is intended to occur in the background by autonomous machine operations and without direct (explicit) user participation most of the time so that the user can unobtrusively go about with his or her routine content browsing activities and so that the user may be occasionally surprised (e.g., once every 15 minutes) to discover that the system has magically (and autonomously) located a chat room where other people are discussing essentially the same topic the user is studying on his or her local computer. The user is also surprised to discover that magically, the people in the chat room (if entered, if the invitation is accepted) are of the civility and/or proficiency that the given user prefers for this topic. Of course, none of this happens by magic but rather by a series of background machine-implemented processes as is detailed herein. In one embodiment, each user can turn off the invitations generating system for a predetermined time length (e.g., one hour, one day, etc.) if he or she finds it annoying and can change their minds and turn it back on at any time they want. Moreover, each user can ask the system to provide invitations at a faster or slower rate as fits the mood of that user. (In one embodiment, users must be subscribed to a premium service if they want the invitations presentation rate to exceed a predefined limit.) In most embodiments however, users cannot explicitly force their way into a given chat room or other online forum running under auspices of the MM-IGS system. They must be invited into the chat room by the system. One reason is that other already participating occupants in that room may not want more new corners (due to room population limits) or may not want that specific newcomer (due to personality conflicts for example). Additionally, in one embodiment, when a user explicitly requests an invitation, the user does not need to be focusing upon any content at all. Instead the user may have already developed a personalized co-compatibility profile (e.g., a CpCCp as will be described below) which by itself allows the match-making and invitations-generating system (MM-IGS) to locate at the time of request, co-compatible other people with whom the first user will more likely than not enjoy conferencing with online about no specific initial topic at all. Closely co-compatible users who request such a topic-less invitations are automatically clustered into a catch-all chat room with other users where profiles of the invitees indicate they are highly likely to be co-compatible for such open ended conferencing. By way of example, they may wish to confer generally about current events. Eventually, the online conference may evolve towards focusing upon a specific topic, in which case the catch-all chat room they joined may be migrated towards a specific topic node as will be described below. However, the point is that the MM-IGS system can be used to automatically bring together people who are chat-wise co-compatible to confer about no specific topic or content at all.
In one embodiment, the centralized online match-making and invitations-generating system (MM-IGS) operates as a distributed cloud computing environment wherein workloads are distributed amongst plural servers and/or data centers based on resource availability and service demands by local user populations. In one embodiment, current chat compatibility preference profiles are automatically updated in a data center with which a user's client machine currently interacts, the modification to the chat compatibility preference profiles are time stamped, and then the time stamped modifications are propagated in the background through the cloud to be included in shadow copies maintained at other data centers of the user's chat compatibility preference profiles. If a user's home default data center is unable to appropriately service him or her for any reason (e.g., power outage, too far away, too overworked, etc.), the user's client machine is redirected to another data center that contains a relatively up-to-date copy of the user's chat compatibility preference profiles. That alternate data center then provides appropriate match-making and invitations-generating services in place of the home default data center.
In one embodiment, current chat compatibility profiles (e.g., personality related CpCCp's) are computer readable digital data files (each accessible by the corresponding logged-in user and partly modifiable by the respective logged-in user) that contain demographics information about that local user and preference information specifying generically the kinds of other users which the local user may or may not wish to connect with at the present time for chatting or other forum like informational exchanges; i.e. blogging, twittering, etc. The personality related compatibility profiles (CpCCp's, PEEP's) may also contain adaptively changeable knowledge base rules indicating how uploaded CFi's are to be parsed and/or merged. In one embodiment, the local user's co-compatibility preferences may be automatically changed based on detected mood of the user, surrounding environment (e.g., work, home, coffee shop), current date (e.g., a special holiday for the user), passage of time, accumulated trending information, etc. and thus in one embodiment the remote match-making service uses monitored user activities and user surroundings to determine the user's mood or other profile selecting attribute to automatically select an appropriate CpCCp matching that current mood and/or other preferences-determining attribute. The system also adaptively changes individual knowledge base rules for personality and/or topic co-compatibility processing based on accumulated trending information. The current chat compatibility profiles (e.g., CpCCp's) of one embodiment further include reputation files or pointers to such files where the corresponding reputations are ones that are built over time for the local user by votes (e.g., biometrically inferred votes or explicit votes) cast by other online users. The current chat compatibility profiles (CpCCp's) of one embodiment further include credential files or pointers to such files where corresponding credentials (including those indicating proficiencies for specific topics or subject areas) are ones that are initially declared by their users but can afterwards be validated or invalidated by system operators and/or by challenges or affirmations by other users of the chat rooms spawning system. CpCCp's may further include identities of a user's favorite topics when in a given mood. These identified favorite topics may be used to better guess at what the user's current topic of interest is (not to be confused with current area of focus) as will be described below.
In one embodiment, one or more of a user's current area of focus (CFi), current mood (Cm) and current voting intent (CVi) are automatically inferred at least from biometric data obtained in real time from the local user, but could additionally be inferred from other information combined with the biometric data such as time of day and surrounding environment (e.g., type of background music, its volume, its beat, etc.). The utilized biometric data may be obtained from visual scanning of the user's face (e.g., detecting grimaces, eyebrow lifts, or other facial expressions) and/or from mechanical detection of the user's sitting posture (i.e., fidgeting) and/or detection of the user's pulse/heart rate, breathing rate (CO2 exhalation detection), depth of inhalations and/or exhalations, galvanic skin response, hand gesturing or the like. Thus if a user is smiling and has eyes wide open, such may indicate a high degree of satisfaction with what the user is currently focused upon on the user's local screen (or with what is otherwise being perceived by the user through a user interface of a local data processing device, i.e., a client computer). On the other hand, if a user is detected to be grimacing and gesturing wildly and breathing rapidly and shallowly, such may indicate a high degree of dissatisfaction or anxiety with what is currently being focused on through viewing of the screen and/or through other user interface means. The specific meaning of biometric data gathered from a local user may vary from user to user, from one surrounding environment to another (e.g., work versus home), from culture to culture (e.g., in some cultures, shaking of head from side to side does not mean disagreement), and so forth. Accordingly, Personal Emotion Expression Profiles (PEEP files) which may include translation data and/or biometric data processing rules are formed, stored and used to determine what the biometric data collected from a given user at the instant or over a stretch of time probably means regarding each local user's cognitive state. PEEP's may be stored locally in the user's client machine and/or remotely in an in-cloud data storage facility. Automatically inferred guesses of what the local user's current interest is (physical focus spot plus mental topic selecting state) and/or what the local user's current conscious or subconscious voting intents are, are automatically generated and respectively recorded in uploaded data objects such as Current Focus identifying records (CFi's) and Current vote indicating records (Cvi's). Incidentally, CFi's do not have to be generated from one same client machine. A local user can have a plurality of automated machines arrayed around him where one machine is watching head and eye (pupil) movements and reporting those to the cloud via a first stream of uploaded CFi's, a second machine is watching posture changes and reporting those to the cloud via a respective second stream of uploaded CFi's, a third machine is watching what content is being made available to the user (through the third machine itself and/or through action of one or more other machines or devices) and reporting those to the cloud via a respective third stream of CFi's. In one embodiment, yet another machine watches or otherwise monitors the biometric sensing devices in its locale to determine which if any user the other sensing devices are monitoring and reports as to the same and the respective machine identification numbers to the cloud. As will be seen, in one embodiment each CFi (
While the above teaches an in-the-background and thus user transparent system for automatically determining the probable emotional and/or physiological state of the user (e.g., angry, tired and hungry), it is within the contemplation of the present disclosure to allow users to explicitly declare their emotional and/or physiological state to the system. In other words, a given user may right click his or her mouse and pick an option (in a pop-out menu, not shown) that allows him or her to tell the system about his or her self-perceived emotional and/or physiological state. He or she may explicitly ask the system to locate chat rooms occupied with other people who are equally emotionally involved with a same or similar topic (e.g., angry over a recent news development or joyous about a local sports team winning the championship). Of course, when caught in the throws of a highly emotional state, users in general may not be able to step back, truthfully assesses their emotional state and explicitly declare it to the system, which is why it is preferable to rely on background collected biometric data. In one embodiment (as detailed below), the system automatically determines when to include current emotional and/or physiological state as one of the parameters for finding a matching chat room.
If a user accepts a chat invitation (Cciv) from an online match-making service (e.g., from the in-cloud MM-IGS) and the user shifts his focus (mouse, eyeball focus, keyboard focus, etc.) into the corresponding chat window or frame then in one embodiment, the inferred meanings of his in-chat focal activities become different from those inferred for non-chat focal activities. The user's bursts of focused and emotional engagement with in-chat transactions are interpreted as implied votes for the content being focused upon within the chat room window. (User reactions to system-made recommendations for further research—See
In one embodiment, if users search on same or similar search terms through a same search portal (e.g., the Google™ web search page) and the searches are initiated within a prespecified chronological distance form each other (e.g., 5 minutes or less apart) and/or the users are within a prespecified geographic distance from each other (e.g., 50 miles or less apart), then invitations are automatically sent to those users to chat about their search results irrespective of what topic the users are actually thinking about. In another embodiment, personality wise co-compatible users who perform such searches are clustered together and the invitations are sent to the clusters to join respective chat rooms. Personality co-compatibility may be determined through use of CpCCp personhood files as shall be detailed below.
Invitations into real time online chat rooms are not a necessary part of all embodiments of the system disclosed here. At least in one embodiment it is sufficient that further research recommendations are autonomously made by the system to the user based on content the user is detected to have been apparently focusing upon.
Other aspects of the disclosure will become apparent from the below detailed description.
The below detailed description section makes reference to the accompanying drawings, in which:
The local client computers 115, 125, 135, etc. of
The local client computers: 115, 125, 135, etc., each also includes appropriate client software 105, 105′, 105″, etc., that is installed in that computer by one or more means including but not limited to: insertion into the local computer of a compact disc (CD) that contains at least part of the client executable software 105 and/or by downloading of at least part of the executable client software 105 into the local computer through use of manufactured instructing signals transmitted from the server cloud 150. As will be explained in more detail below, the loading-in of part or all of the client software 105 transforms the local computer into one or more altered states wherein the altered computer operates at least part of the time as an automated generator of Current Focus identifying records (CFi's), as an automated generator of Current Vote indicating records (Cvi's), as a receiver of chat room invitation records (Cciv's) and/or as an automated displayer of radar-like invitation blips that represent received ones of the Cciv's. The client software 105 may comprise a plurality of components including, but not limited to: a Local Activities Monitoring Service (LAMS) 105x. In one embodiment, the LAMS 105x includes an automated current focal point detector module 105a (a CFid, shown elsewhere in
User focus and/or interest in a particular item may be indicated by a variety of mechanisms including those disclosed in the here incorporated U.S. Pat. No. 5,890,152 (“Personal feedback browser” by J. Rapaport et al). In other words the interest indicators may comprise or may be functions of an amount of time spent by a given user in viewing a particular on-screen article, time spent scrolling through the article, time spent moving a cursor or other location indicator through the article, number of mouse clicks on items within the article, amount of highlighting of various parts of the article, and so forth. Scroll rate and mouse agitation rate may also be used as indicators of current level of interest. Time spent apparently listening to related audio content may also be used as an indicator of current level of interest.
Each user is different and thus may indicate heightened interest in one form or another of informational content that is being displayed and/or otherwise output to the user by his local machine by means of a different set of local user activities. Accordingly, in one embodiment, the local client software 105 includes a local Personal Emotion Expression Profile (L-PEEP) 107 which correlates different ones of locally expressible and detectable physical activities of the user with different kinds of interest and/or emotional indications, be they negative, positive or neutral. The meanings of detected user state may also change as a function of user mood or user surroundings. Alternatively or additionally, the Remote Client Access and Accessible-Resources Monitoring Service (AARMS) 150a in the cloud 150 may link to a client account database that stores an online or remote Personal Emotion Expression Profile (rPEEP) where the latter is made responsible for carrying out, or for supplementing the correlations made for different ones of locally expressed and detected physical activities of the user with different kinds of interest or emotion indications. In one embodiment, standardized interest indications are established by the online match-making service such as a spectrum of interest indications spanning from substantially not engaged to fully engaged and such as from substantially negatively disposed to substantially positively disposed when used for representing level of emotional disposition. In one embodiment, a neural network adaptive model or the like includes trend and erratic departure detectors and is used for determining best guess correlations between locally detected indicia of user focus and/or emotion with otherwise indicated levels of focus and/or emotional disposition. In the same or an alternate embodiment, a statistical model is used for scoring on an ordered probabilities basis, correlations between locally detected user activities and/or biological states and corresponding states of the user's mind (e.g., engaged versus bored, happy versus disappointed or upset, etc.). In one embodiment, the neural network adaptive models and/or statistical models are used to adaptively alter knowledge base rule sets for individual users where the knowledge base rule sets dictate how various pieces of information will be combined and processed.
In terms of a more concrete example, reference is now made to PEEP record 107 of
In one embodiment, a first table column 196 of the PEEP database record 107′ (
In addition to ordering the monitorable biometric parameters according to which are more telling in given circumstances, the average latency between cause and effect are recorded for each in time stretch column 197 of the table. some biometric parameter changes may occur long after an instigating event (e.g., viewing emotion creating content) while others may take root soon after. The time stretch needed between time-stamped ones of start and stop CFi's may be determined based on the average latency times recorded in column 197. The actual time stretch employed may be varied according to adaptively adjusted expert system rules provided in a knowledge rule base 199 that may be embedded in each PEEP record (or stored elsewhere and logically linked to the PEEP). As known to those skilled in knowledge rule databases and automated expert systems, IF-THEN-ELSE statements can be nested one in the other and each containing conditional expressions plus conditionally actionable consequences. The nesting can be changed, the conditional expressions can be changed and the data ranges or other data values inside the conditional expressions can be changed. Accordingly a very flexible system is made available for adaptively learning what monitorable biometric parameters work best (or good enough) for each individual user under various surrounding conditions, what ranges or trigger limits of data values inside the conditional expressions work best (or good enough) for each individual user, and what nesting of rules works best (or good enough). In one embodiment, before less important other parts of a given PEEP record (e.g., 107′) are processed, a PEEP record switching rule (e.g., IF Surroundings=Work THEN . . . ) is automatically executed so as to conditionally swap in a different PEEP record (e.g., 107.2, not shown) in place of the default PEEP record when certain predefined conditions are met, such as when it is determined that the user is at his or her work place rather than at home, that the user is using a handheld data processing machine (e.g., cell phone) rather than the usual desktop computer at home or at work, that the user is not alone, that the time of week is a weekend rather than a weekday, and so on. In this way wholesale changes of PEEP defined behavior can be made before finer determinations of user state are made based on in-PEEP knowledge-base rules and/or based on in-PEEP primary physical state definitions.
Here are some nonlimiting examples of knowledge base rules that may be provided in a PEEP record and used for determining via automated means what the user's current emotional state is: (1) IF Heart_Rate increased by 2% in last 5 minutes THEN increment Anxiety_score by +1, ELSE IF Heart_Rate decreased by 3% in last 4 minutes THEN adjust Anxiety_score by −1. (2) IF posture_change shifted weight bearing 20% or more asymmetrically to one body side more than what average of last hour was THEN increment Jumpy_score by +1, ELSE decrement Jumpy_score by 0.5. (3) IF Words_per_minute_read increased by more than 10% over base_reading_rate_of_current_content_displayer in last 2 minutes THEN increment Interest_score by +1 ELSE IF Words_per_minute_read decreased by more than 30% below base_reading_rate_of_current_content_displayer in last 2 minutes THEN increment Interest_score by +2 AND increment CFi's time stretch by +3 minutes ELSE decrease adjust Interest_score by −0.3. (4) IF eye dilation increased by 10% or more while reading last paragraph AND same paragraph was reread THEN increment Interest_score by +5 AND increment CFi's time stretch by +2 minutes. (5) IF user interrupted reading to type notes and then quickly returned to reading same content and then proceeded to make further notes THEN increment Interest_score by +10. (6) IF user's eyes tracked paragraph without interruption for more than 1 minute AND Respiration_rate decreased by more than 20% THEN increment Interest_score by +8 AND increment Concern_score by +3. (7) IF user read last paragraph uninterrupted AND eyes dilated AND microphone(s) detected utterance of swear word by user AND user put hands to face and shook face, THEN increment Upset_score by +50. (8) IF user stopped reading (eye sweep stops) and stared into monitor for more than 45 seconds (thus appearing to concentrate on thinking) AND then user resumed reading with increased Heart_rate THEN increment Interest_score by +10. (9) IF user stopped reading (eye sweep stops) and user quickly changed web site (new URL) and became engaged in activities unrelated to currently displayed content THEN adjust Interest_score by −25. (10) IF user returned to original web site (old URL) and user resumed reading same (eye sweep resumes) and user ceased unrelated activities THEN adjust Interest_score by +25 (to wipe out earlier negative due to newer showing of continued interest in content of old URL, perhaps due to user re-evaluation of value of that older content). (11) IF user Heart_rate in range of 117 to 123 beats per minute, THEN set Extreme_excitement to True. (12) IF user inhalation depth is greater than normal by 25% and respiration rate is Regular THEN set Deep_interest to True.
In one embodiment, initial knowledge-base rules sets may be hand coded and stored into respective stereotyping or template profiles together with pointers pointing to rule parameters that are to be automatically fine tuned by the system over time on the basis of experience with a given user's behavior. In one embodiment, pattern discovery and/or rules generation are automatically carried out in accordance with Rough Sets theory and/or other expert system knowledge base development techniques. In one embodiment, a combination of automated knowledge base development techniques and hand coded refinement may be used to produce the initial knowledge-base rules sets.
In one embodiment, table column 198a identifies the mental state (typically expressed as a numerical score by the data processing machines described herein) that most closely correlates with the monitorable biometric parameter of column 196 for the given individual user. The correlations can change from person to person, from one environmental setting to another and even for a same user over the course of time. Thus these listed correlations are adaptively changed by the system over time using feedback obtained from user filled surveys, obtained from emotion evoking test content and/or from rate of invitation acceptances. In one embodiment, table column 198b identifies room matching keywords that are best employed for that person to find chat rooms having emotional states empathetic to the correlates ones of the given user whose PEEP record 107′ is shown. The correlations of column 198b can change from person to person, from one environmental setting to another and even for a same user over the course of time. Thus these listed correlations 198b and utilized keywords are adaptively changed by the system over time using feedback obtained from user filled surveys, obtained from emotion evoking test content and/or from rate of invitation acceptances. In one embodiment, each PEEP file may include an early executed knowledge base rule that swaps out the current PEEP file 107′ and replaces it with another PEEP file (e.g., 107.2, not directly shown) in response to, for example, time of day, primary client machine being currently used by the user, detected surroundings of the user and so on. More specifically, a given user's normal reaction times may vary as a function of such parameters and by substituting in the appropriate PEEP file the system can automatically make whole sale adjustments to finer PEEP parameters by first picking the context-appropriate PEEP file.
A PEEP database record or file may have a variety of different fields filled with various correlations and/or adaptively changeable rules. As seen in the example of
Referring again to
Aside from using the locally stored browser use history 105d and/or in-cloud stored history of the user's browsing activities (and/or mouse use activities 105g) to determine probable topic of interest, automated determination of the user's probable topic of interest may be based on a locally stored history of the user's chat room activities (e.g., stored in local chat history file 105f) and/or in-cloud stored history of the user's chat room activities, where the latter histories may contain information about the identities of the chat rooms that the given user had recently entered into (whether invited or not) and that information may include duration of stay in the room, level of contribution to room content and indications of positive or negative reactions by the user to the contributions of others within that chat room. The latter gathered information can be used to automatically infer certain preferences of the client user (e.g., 121). In one embodiment, one or more adaptive neural networks and/or statistical analysis models are established in the cloud 150 for each user for determining from a host of input parameters, that user's current, most probable topics of interest; that user's current, most probable emotional state; and that user's current, most probable voting intentions (inferred ones rather than explicitly stated ones). The host of input parameters may include data provided in current CFi's, data obtained from the user's most recent or earlier browsing, searching and chatting histories and data regarding apparent success of earlier guesses made by the neural network or other models (for example, based on the user accepting an invitation into a chat room and the user demonstrating satisfaction with the choice, such as by the user participating for a relatively long time in that chat room). As already mentioned, one of the database records that the user models periodically try to tweak based on feedback are each user's PEEP record (107′ of
Another aspect to be recalled here is that the informational content to which a user is exposed; and to which content he or she may pay more or less attention to (degree of focus); and in which content he or she may take greater or lesser interest in; and with which content he or she may become emotionally involved to a greater or lesser degree; does not necessarily come all or partially from the local computer (e.g., 115) on which the user is performing searches or on which the user is participating in chat rooms. The user could be watching a soccer match on a nearby television set and at the same interacting on his local computer (e.g., 115) with a chat room populated by soccer enthusiasts. Or the user could be listening to a nearby radio over which the soccer match is being telecast. It is the job of the local computer (e.g., 115) to determine what one or more content-providing devices (e.g., TV, radio, computer monitor 117) the user is focusing attention on over PEEP-defined stretches of time and to determine the degree of that attention (e.g., high, medium or low) and to determine the degree of interest that the user is taking in the focused upon content. To this end, various local range networking schemes such as wireless BlueTooth™ or the like may be used so that the local computer (e.g., 115) can interrogate nearby other content-providing devices (e.g., TV, radio, other computers including XBox™ or other game playing machines) to determine if they are turned on or not, and if yes to determine what content they are currently providing and/or what their audio volume setting is and/or how often and how the user is interactively interfacing with them (particularly the game playing devices). Additionally, microphones (soon described) of the local computer (e.g., 115) may pick up noises emitted by these various devices and relay samples of the same to the cloud 150 for analysis and determination of what specific content the local user (111) is being exposed to. More specifically, as mentioned above, the user may be surrounded by background music. The background music may be fast paced heavy metal rock and roll or slow paced classical symphony music. These different types of music or even their primary beat may be indicative of the kind of mood the user is in. Also the volume of the music or the rate at which the music changes from one type to another (e.g., because the user is fidgeting with the station selection controls) may be indicative of current user mood. Alternatively, there could be loud machinery noise in the background or screaming young children which could place the user in a bad mood. Provided on the microphones, on the computer display monitor, or separately, there may be room lighting detectors which detect the brightness and pervasiveness of surrounding room lighting, where the later is automatically reported to the cloud as being potentially indicative of current user mood.
As an alternative or addition to use of BlueTooth™ or the like for interrogating other local machines and obtaining reports from them, the user's primary local computer (e.g., 115) may include an RFID detector (radio frequency identification interrogator) that tests for presence of RFID tags in the surrounding equipment and thus determines the nature of the surrounding equipment (and perhaps their distances from the RFID detector). This coupled with sound picked up by the microphones, room lighting detected by room lighting detectors or controls and imagery picked by the primary local computer's web camera (116) may be sufficient for identifying the external content to which the local user is being exposed to and for determining when the local user is directing his or her attention to that other content-providing device. So to summarize, although discussion herein centers on content provided by web pages displayed under control of the user's primary local computer (e.g., 115), the present disclosure is not limited to web-page encoded (e.g., HTML, XML) presentations. Content to which the user is exposed and to which he or she may pay greater attention to, take greater interest in, and so on, can come from any automatically identifiable source and the user's primary local computer (e.g., 115) may have means for identifying the content produced by that source (e.g., via listening in with the microphones, via BlueTooth™ interrogation, etc.) and may have means for determining when and to what degree the local user (111) is paying attention to that externally provided content and reacting to it. In one alternate embodiment, each external content providing digital device may automatically feed CFi's (wirelessly or otherwise) to the user's primary local computer (e.g., 115) for uploading to the cloud or one or more of those external content providing digital device may automatically feed CFI's directly to the cloud 150 for integration in the cloud of those CFi's with CFi's uploaded from the user's primary local computer. (It will be seen in
As seen in
The local client software 105 may use one or more of these or various other biometric indicators to infer what the local user (e.g., 111) is consciously or subconsciously thinking (111a) with regard to material 117a that is being displayed on the screen 117 or otherwise presented by the local computer and on which the user's eyeballs (his pupils) are currently focusing upon (and/or on which the user's mouse cursor is dwelling or keyboard cursor is dwelling upon or highlighting). The local client software 105 may use the various biometric indicators to also determine how focused and emotionally engaged or not the user is on that particular area 117a and/or what positive, negative or neutral emotional attributes the user 111 is assigning to that focused-upon content 117a by virtue of the user's currently expressed and detected biometric and/or other activities (or later detected biometric and/or other activities that are logically associated as effect and cause pairs with earlier content in accordance with the user's PEEP record, e.g., 107 and/or in accordance with other effect and cause pairing data. Additionally, the local client software 105 may use various context cues, such as by detecting the location of the user via a GPS sensor 111z or other means (e.g., nearby RFID tags, nearby other equipment detected by wireless coupling via BlueTooth™ or the like) and determining from the identified surrounding location (e.g., at home, in the office, on the road, alone, in a crowd, etc.) what the probable topic of the focused upon material is. (Topic and/or topic domain may be automatically determined by the DLUX service module 150b which will be discussed later below.)
Some users' computers may include one or more microphones 129 for not only picking up voice communications by the user (e.g., 121) but also for detecting voice stress patterns in the user's speech and/or detecting non-verbal grunts or other sounds which the user may make to express enjoyment, dismay and so forth. Additionally, the microphone(s) may be used to determine the surrounding environment in which the user is situated. Are there noisy children in the background and/or a barking dog? Is a TV or radio blaring in the background? What type of music is being played? What current broadcast TV show is being watched or listened to? Alternatively, is the user relaxing at a quite poolside of a luxury hotel or in a darkened room while sipping a fine wine (whose odor may be detected by an optional odor sniffing device that reports to the cloud)? Much can be determined by picking up and analyzing background noises and/or odors and/or lighting cues. Knowledge-base rules can be provided in the cloud for analyzing uploaded background noises, etc., and for determining probable user mood based at least in part on such background noises, etc. In the case where plural microphones 129 are present, these may be directional ones and used for detecting the direction and/or location from where a noise came as well recording the sound for analysis. It is possible for a verbal utterance to come from someone other than the primary user, where the primary user is the person closest to the display 127. Plural microphones can be used to discriminate and ignore unrelated background noises. Also if a startling noise comes from behind or to the side of the user, the plural microphones can detect this and determine that an immediately responsive change in biometric data (e.g., the user turning away from the screen to look at the source of the sound) is unrelated to on-screen content. Client software 105′ may include interface components for receiving the audio signals from microphone(s) 129 and for using these to determine current emotional states 121a of the user and/or to determine when a current emotional state is unrelated to on-screen content. Once again, because emotional expression by each user may vary due for example to gender, culture, surroundings, etc. and may vary from day to day, the client software will often include a local personal emotion expression profile (L-Peep, see also
Some users of system 100 may elect to wear a biometric timepiece 111tp such as one shown to appear as a wristwatch on the wrist of user 111. However this biometric time piece 111tp may be configured not only to reveal the current local time and date (and optionally time in standardized Greenwich Mean Time (GMT) format) but also to perform one or more of the following: wirelessly relay to the computer the current pulse rate of the user, relay the current galvanometric skin resistance of the user, relay strain or tightening of the wrist band which may indicate flexure of forearm muscles, relay acceleration of the time piece 111tp which may be detected by integrated miniaturized electromechanical devices (MEM's) and may represent hand gestures and speed thereof by the user and/or relay a Doppler signal from an integrated Doppler ultrasound blood flow detector which detects rates of blood flow in the user's hand, pulse, etc. Additionally or alternatively other medically related devices and/or methods may be used to pick up for example the user's current rate of respiration, blood pressure, state of agitation, distribution of weight on weight bearing surfaces within a properly configured chair 121s or sensor-riddled floor mat (not shown) and so forth for the purpose of determining the user's current emotional state. In one embodiment, specially configured chair 121s is further configured to communicate to the local computer 125 the seating posture of the user 121, for example using sensed weight distributions to indicate whether the user is leaning forward on the edge of the chair or relaxed and leaning backwards on the back of the chair, leaning to one side or the content and/or for how long. Additionally, or alternatively some users may elect to wear special biometric measuring clothing, shoes, gloves, etc., which wirelessly report to the computer 125 (or directly to the cloud) various aspects of the user's external body language and or internal medical state (e.g., EKG, EEG, etc.). As already mentioned, in one embodiment the display mounted digital camera 116 may include means for capturing local imagery in more than one optical band, for example in the IR band in addition to normal visuals captured in the visual (e.g., RGB) band. IR captured imagery may indicate flows of warm blood to different parts of the user's face, rate of exhalation of warm air, depth of exhalation, and/or other biometrically related information. In one embodiment, the software 105 includes a privacy consent agreement which must be digitally signed by the user before such privacy challenging information is collected and relayed to the match-making service in cloud 150. Since the numbers and kinds of biometric data gatherers (e.g., 111tp, 129, 121s, 126, etc.) can vary from one user computer (e.g., laptop) to another (e.g., third or later generation cell phone or personal digital assistant PDA), the match-making service (150c) may include software for dealing with various permutations of available biometric data gatherers and different knowledge-base rules (e.g., 199) may apply depending on which biometric data gatherers are available and being used for reporting on the biometric state of the user. For example, a same user on one day may be using his full featured desktop computer with a large array of available biometric data gatherers and another day the same user may be using his potable PDA (or intelligent cell phone or other intelligent mobile phone/device based on appropriate other technologies such as WiFi, satellite, etc.), which intelligent mobile device has a substantially smaller number of available biometric data gatherers with perhaps more limited capabilities. More specifically, the hand held intelligent mobile device may be limited to capturing a low resolution image of the user's face and to detecting how the hand held device is being gripped by the user, how hard it is being gripped and in what orientation. The system has to make due with this limited amount of gathered biometric data. The match-making service automatically detects the available (operable) biometric data gatherers for each user session and adaptively adjusts its data processing accordingly (e.g., by using knowledge-base rules provided in the user's PEEP record(s), e.g., 199). Biometric data gathering devices may be integrated into the user's mouse or keypad so that biometric information is automatically detected and gathered each time the user's hand comes into proximity with such a user interface (e.g., GUI) device. For example, a mouse may have an IR subsystem embedded on a side surface thereof where the user's thumb normally comes to rest when manipulating the mouse. The IR subsystem detects proximity of the thumb and lights up at that time to pick up the user's pulse rate, skin temperature (indicative perhaps of vessel constriction or sweating) and other parameters. Skin resistance at the thumb may be detected capacitively. On the other hand, if the primary local user client machine is a cell phone, it may not have a mouse or its equivalent for purpose of determining gripping stress in the hand. However, the cell phone is not without ability to determine user state by other means such as detecting stress tones in the user's voice, detecting what angle the user is holding the portable device relative to gravity, detecting what mechanical stresses the user differentially applies to different parts of the portable device, detecting whether the user is employing public speaker mode as opposed to private earpiece mode and if in earpiece mode determining how the user is shaking his or her head and/or hand based on change of orientation of the handheld portable device. Knowledge-base rules for processing these various situations may be embedded in the user's PEEP record(s) and/or logically linked to the PEEP(s).
Beyond the relatively less intrusive biometric detecting devices (e.g., pulse-detecting wrist watch, wrist band or mouse), some users may be willing to have their biometric state monitored by more intrusive means. For example, a user may elect to wear special eye glass frames (not shown) that are structured to detect relative head angles and/or relative eyeball angles and/or relative degree of pupil dilation. More specifically, a set of detectors on eye-facing side(s) of the frames may watch eye movement and pupil dilation and report these wirelessly to the client machine 115. Integrated motion detectors (e.g., MEMs—miniaturized electro mechanical sensors) inside the frame may detect absolute head direction and/or relative changes of head angles and report these wirelessly to the client machine 115. Magnetic resonance detectors (e.g., of a functional fMRI kind) or other kinds of electromagnetic brain probing devices may be embedded in the special eye glass frames or in a helmet (not shown) worn by the user so as to detect when certain parts of the brain (e.g., amygdala, orbitofrontal cortex, dorsal striatum, etc.) become more active or light-up so to speak and thereby discriminately indicate different emotional or cognitive states (e.g., fear, doubt, joy, etc.). These brain activity indicating signals may also be reported wirelessly to the client machine 115 and processed thereby or relayed to the cloud and processed in the cloud 150.
Referring now more specifically to the first user 111 shown in
The local client software 105 may sort the collected Current Focus identifying records (CFi's) according to locally determined intensity of interest or emotional involvement scores. Prior to the start of content scanning by the user (e.g., 111), the user had logged into an online interest matching and compatibility matching service (e.g., 152 of
It was noted above that the actions of direct polling of client machines and of pulling from their buffers is not always possible. For example, when the client machine connects to the internet through one or more conventional routers (i.e., when multiple computers are on a local LAN accessing the network through a single access point that has a single IP address as seen on the internet) there is often no way for a server in the cloud to uniquely address each of the individual machines behind the router (and optional firewalls) or to uniquely address each of the buffers within those machines and determine their states. Instead, in one embodiment, the server can emulate the client CFi's buffer at the server's end of the communications network and can selectively poll those emulated buffers and selectively pull from them. Alternatively or additionally, the server can selectively drop CFi packets sent from the client as a substitute for the action of not pulling CFi data. Yet alternatively or additionally, the client machine sends buffer status packets with upload requests to the server. For example, the client machine sends a buffer status and upload packet indicating something like: I have 10 Kb of CFi data for you to upload with the data having an aged data range of 3 seconds to 4 minutes. In response, the server may send different handshake responses including for example: (1) OK send all of it to me now; (2) OK send all of it to me during the following time slot . . . ; (3) My bandwidth is somewhat limited now, send to me only your most important 5 Kb or less of CFi data and drop the rest; (4) My bandwidth is somewhat limited now, send to me only your most recent 2 minutes worth or less of CFi data and drop the rest; (5) My bandwidth is very tight now, discard all the CFi data you currently have and do not send me another request until the following time slot . . . . These are some examples of how the in-cloud server can control upload data flow. Other communication control mechanisms such as the server sending buffer slack indicators to client machines or sending backpressure messages to the client machines can also be employed. It is to be understood that different router and firewall configurations may be used in home and/or business LANs installations and that different specific actions may need to be adaptively taken to emulate various ones of the actions described herein involving communications between the client machines and the match-making servers. It is to be understood that even when clients have unique IP addresses and are uniquely identifiable by the server in the cloud, there may often be hardware or software firewalls preventing direct access in which case the server may emulate direct access at its end and use some form of end-to-end automated synchronization of data sets or handshaking in order to effectuate the desired outcome.
The first user's involvement with the given article (117a) and/or the first user's involvement with other associated content that the user 111 for example hyperlinked to, or found by way of a search engine search, may be greatly enhanced if the first user 111 was merely informed that there are other users out there (e.g., on the internet) like him who are studying the same article with approximately the same focal intensity and/or approximately the same emotional involvement at the same time. In other words, the first user is informed that he is not alone in having interest of a particular intensity in this particular material and/or topic at this particular time. In one embodiment, the first user is informed of how many other users the matching service 152 has identified as having a matching focal point of interest (e.g., 117a) and/or having a matching interest in a corresponding topic correlated with the focal point in a recent time period (e.g., in the last 5 minutes, in the last hour, last 3 hours, last day, last week, etc.). This information alone can enhance the user's experience. However, there is more.
The first user's involvement may be even more greatly enhanced if the first user 111 could communicate with some of those other, still unknown to him, users about the same or similar topic of interest or even about just the same focused on material 117a. To this end, the in-cloud matching service 152 (or more correctly one or more online servers (virtual and/or real) that provide the corresponding services) may push one or more current chat room invitations (Cciv's) 118c over a network and to the local computer 115 of the first user 111. These chat room invitations may appear as moving icons (e.g., small blinking semitransparent dots, larger more solid bubbles, or yet larger animated talking heads etc.) flowing on a side banner of the user's screen 117 from edge to center or from one end of the banner to the other. In one embodiment, these chat room invitations appear as blips (e.g., 117c, 117d of
Referring to
With the popped-out chat window frame (not shown in
Alternatively, user 111 may provide explicit feedback to the system by informing the matching service 152 of his actual topic of interest (e.g., it is not the current poker tournament in Las Vegas but rather the Hoover Dam engineer's special interest group called HD.spig) and in response the matching service 152 may then alter its behavior (learned behavior) accordingly with regard to the meanings of the recent actions by the given user 111. If the matching service 152 correctly inferred what the user's topic of interest is, the first user 111 will usually keep the chat room (e.g., 316a) open for a while. Such a prolonged open state can be used as feedback by the match-making system indicating that the system had made a good match. The user may elect to just observe from the sidelines the current interactions by other chatterers within the opened up room. Alternatively, the first user 111 may elect to participate on a more active basis by voting on room content, by contributing to the room content or conversing (virtually) with other people who are currently in the room and appear to be as heavily interested in the same topic 117a as he is. In one embodiment, even if the matching service 152 did not bring the first user 111 to exactly the kind of room he would have preferred to join, the first user 111 is given the opportunity to manually browse along adjacent nodes of a topic categorizing, hierarchy tree full of roughly similar chat rooms (see briefly
Referring to second user 121 of
Servers within cloud 150 may automatically determine co-compatibility between users 121′, 131′, 141 by comparing their associated profiles including Current personality-based Chat Compatibility profiles (CpCCp's) 105h.1 etc., 105h′ and so forth (see also
Before discussing in detail data structures of profile records such as CpCCp's 105h—etc. (see
If a first set of one or more users express persistent displeasure with a second set of users within a given chat room (e.g., 162 of
Just as some users may prefer small rooms (e.g., 5 or less participants), others may prefer larger rooms. The cloud 150 automatically detects this from the CpCCp's or other profiles of the users. If two rooms each have too few of a number of participants in view of the user desires expressed in their profiles, the system automatically detects this and automatically fuses (combines) two small parent rooms (e.g., say room 162b containing 3 participants and room 163 containing 2 participants) into one larger room 164 of co-compatible and larger-crowd seeking participants. Preferences are determined based on user Current Chat Compatibility profiles directed to personality and topic (CpCCp's and DsCCp's) which are stored in database 151 and whose data structures are now detailed with reference to examples, first in
Referring to
The currently-in-effect personality-based chat compatibility profile (CpCCp) (i.e., having mood or surrounding related to identification number 105h.1) may be viewed as having a plurality of horizontal regions, e.g., those designated as demographics rows 171, reputation rows 172 and credentials rows 173. Additionally, as seen in
The demographic data of the local user 121″ is stored in a database region represented in
Referring to vertical column 155 (desirable chat buddies), user 121″ has indicated that the chat rooms she would like to be invited into preferably should include another user whose username happens to be MBGFFL (which may stand for My Best Girl Friend For Life). The preferred inclusion list could have plural usernames in it. User 121″ has also indicated that the stated demographic age groups for desired people in the ideal chat room should be in the range of 15 to 18 years old and that these should be validated age indicators. Additionally, she has requested that most of the chatters be of the female gender (this being reinforced in column 157) and that this gender designation be a validated one. When a co-compatibility finding server (one containing database 151 of
As mentioned above in some embodiments the users can provide suggested weights to be applied to the various stated preferences or stated dislikes. However, a user's actual behavior may show subconscious preferences (or dislikes) that are quite different from the stated ones and/or weighted differently than the user-state weights. In one embodiment, the cloud 150 includes trend detecting services that run in the background and analyze each user's actual behavior (e.g., which chat rooms she or he actually joins and engages in forcefully). The trend detecting services (see for example 437 of
When the match-making services score the weighted (or unweighted) preferences positively and the weighted (or unweighted) dislikes negatively and add these scores together (or apply them to a more complex function for determining co-compatibility, the resulting co-compatibility score signals (could be along different dimensions such as one for topic co-compatibility and another for personality co-compatibility) tends to increase as more of the desired chat buddy properties are met and decrease as more of chat buddy dislikes (column 156) are met. A relatively high co-compatibility score indicates a greater likelihood that user 121″ will find the other chat buddies in the proposed chat group to be co-compatible with her desires at the current moment. Near the end of the process (detailed more below), different co-compatibility scores based on personality will have been developed for a given user i.e., 121″ and the proposed groups of other users (e.g., 131′, 141′ of
Since various permutations of not-yet-joined users and rooms may be possible, in one embodiment co-compatibility distance graphs are formed and represented by stored digital data.
While first vector 512 is drawn from Sally-to-Sam with a respective first distance (in a one or two dimensional co-compatibility space or in a space of 3 or more dimensions, where each dimension is a different kind of co-compatibility factor), a different second vector 521 is drawn from Sam-to-Sally based on a system generated, weighted score (Score21) that represents how well Sally's demographic attributes correlate with Sam's preferences. In this case, Sam is shown in phantom at location 111* and a dashed distance vector 521 is shown to represent the corresponding counter distance. The reciprocal (1/Score21) of the Sam-to-Sally score, if positive and finite, may be taken to represent distance vector 521 that originates with Sam's preferences (e.g., 505b, 506b), extends to Sally's demographic attributes, and is referred to here as the Sam-to-Sally distance. (Of course user-to-user distance values may be generated with functions other than the score reciprocal and still provide roughly similar results.) If the Sam-to-Sally score (Score21) is zero or almost zero, then distance goes to infinity (beyond a predefined maximum) and no linking vector 521 is created at all. Similarly, if the Sam-to-Sally score (Score21) is negative, then it is taken that Sam strongly objects to meeting up with Sally, and as a result, no counter-linking vector 521 is created at all. On the other hand, if the Sam-to-Sally score (Score21) is a relatively small positive number, then the Sally-to-Sam distance vector 521 exists but it is relatively longer (longer than first vector 512 in the illustrated case). This may be taken to mean (given the relatively large distance defined by vector 521) that Sam 111 is less willing to talk with Sally 121 than the vise versa condition concerning Sally's willingness to meet up with Sam 111 in a chat room (based on their respective profiles).
In this example (
Next, as seen In the example of
Next, as part of the trial and error clustering process, Sandra 141 is hypothetically linked to room 561 and that room's profiles (e.g., CpCCp 505e and DsCCp 506e) will be automatically readjusted again to pretend that all three of Sally, Sharon and Sandra have entered the room. Accordingly it is seen that user-to-room linking distances change as more users are hypothetically added to the room and also that the room's averaged (or otherwise formed) variable profiles (e.g., CpCCp 505e and DsCCp 506e) will change in response to trial and error addition of each further user. At some point, user-to-room linking distances may exceed one or more predefined limits and the trial and error process will be stepped back to return to acceptable distances and possibly halted at that time.
So one possibility is that free agent users (floating users) like 121, 131 and 141 have no pre-established room to join into and the system spawns an empty room (e.g., 561) for them and starts determining through trial and error how to populate the room with closely clustered users (closely clustered in the graph space) such as 121, 131 and 141. On the other hand, in the case of Sam 111, the system may find an already populated chat room B (563) where the linking distance (526/562) from Sam to the room (B) is within predefined limits. In that case, Sam will be invited to enter populated room 563, and if he accepts the invitation, the profiles of room 563 will be adjusted accordingly to reflect Sam as a new member.
Referring to
After users are segregated into respective groups based on sameness and/or substantial similarity of focused upon content in step 520, each group is respectively further processed in step 524. It is to be understood with regard to the illustration in
In step 524, the same/similar-content group is further segregated into subgroups of floating users according to sameness and/or similarity of the domain and/or topic that is probably on their minds. For example, one subgroup is formed of users who have similar probabilities that they are thinking about a USA soccer team in conjunction with the same/similar-content that has been identified by their CFi's, while a second subgroup is formed of users who have similar probabilities that they are thinking about watching an upcoming USA versus UK soccer (or “football”) game on TV this weekend. The number of subgroups that are formed depends on system resource availabilities. If the current workload is heavy and resources are strained, each subgroup may correspond to a low resolution domain. On the other hand, if more bandwidth is available, each formed subgroup may correspond to a higher resolution subtopic residing under a topic node which resides under a corresponding domain node (see
In an alternate embodiment (not shown), module 522 appears before module 520 and module 522 of this alternate embodiment provides scores for say, the three most likely domains (pre-established domains in the system hierarchy tree) each user is probably thinking about. These scores are used to define clustering distance vectors similar to those of
While it was mentioned above that topic-based distance scoring may be varied as a function of cloud workloads, it is also within contemplation of the present disclosure that topic-based distance scoring be varied as a function of CFi hint specificity and richness. More specifically, some uploaded CFi data sets may contain a rich set of topic hints that clearly point to a specific topic node within the system hierarchy tree. Accordingly, the user associated with this rich CFi set may be finely positioned among set of highly specific topic nodes and his finely-tuned score used to determine which of the highly specific topic nodes are the ones that most likely reflect what is on the user's mind. By contrast, the uploaded CFi data set of another user may contain only hints that are very vague as to what specific topic that user has on his or her mind. In the latter case, the user will be crudely positioned in topic node space next to a major domain or to a low resolution topic node but not next to a highly specific topic node. Accordingly, users whose uploaded CFi data sets contain only vague hints as to probable topic on that user's mind are float-wise positioned in topic node space next to a major domain (including the generic catch-all domain) or to a low resolution topic node (including a generic catch-all topic under a specific system domain) and such users therefore cluster close to one another. In one embodiment, the topic node space is defined as a polar coordinate space (see
A few more words are in order here regarding
By way of a more specific example of the use of the illustrated 2-D polar space 600, it is assumed that recent uploaded CFi hints belonging to Sam (611) position him close to topic node T1.2. Recent uploaded CFi hints belonging to Sally (621) position her midway between domain node D1 and topic node T1.2. Recent uploaded CFi hints belonging to Larry (651) position him at an angle of sub-topic ST1.45 but much further out in this solar system of domain and topic nodes, say at R=1000. Since Larry 651 is alone in the current overlaying of his determined topic of interest on polar space 600, a first automated step scales Larry's position radially back, but at his original angle, to say R=100 and a test is conducted to see if other users are nearby. If no, a next automated step scales Larry's position radially back, but at his original angle, to say R=10. Once again it is tested to see if Larry is all alone. This time the answer is no because Sam 611 is nearby. Ultimately Larry and Sam may be invited to join a chat room (not shown) running under the auspices of topic node T1.2. Sally 621 may be invited to join the same chat room. However automated determinations as to which room if any each user will be invited to join may be made on the basis of computed distances (e.g., 622-624) in topic space 600 between each user and nearby topic nodes and/or computed distances (e.g., 625) in topic space 600 between nearby users. In one embodiment, users who are much closer to each other (in other words, they are closely clustered) in topic space 600 than to nearby topic nodes are automatically invited into a newly spawned room that is automatically spawned for them because they are so closely clustered (e.g., within a predefined distance), topic wise to each other. Of course invitations may be predicated in some embodiments on personality co-compatibility and/or other attributes besides that of closeness within the topic space 600.
It was mentioned above that recent uploaded CFi hints belonging to Sally (621) position her midway between domain node D1 and topic node T1.2. Here is how the same is machine implemented in one embodiment. Actually and initially, a DLUX analysis of the recent uploaded CFi hints belonging to Sally (621) provide a first relatively high score associating her recently uploaded CFi hints with domain node D1 and a second relatively high and roughly the same score associating her recently uploaded CFi hints with topic node T1.2. The DLUX analysis may provide yet other scores that place her near, say domain node D6 (where such placement is not shown in
Returning back to the example of
Once the system computes the linking distances existing (if at all) between the various users in step 528, in one embodiment, the system also automatically generates a linked list for each user where the list items are sorted according to linking distance from the lead user, with the closets one or more other users appearing first in the list and the furthest appearing last. Thus the list provides an ordering of other users according to distance from the lead user of that linked list.
In step 528, for each subgroup formed by step 524, the system computes the linking distances (if any exist) between each of the users of that subgroup and available, populated chat rooms belonging to the node of the corresponding topic. In some instances there may be no already-populated chat rooms belonging to the node, particularly if it is a newly formed topic. However, if already-populated chat rooms exist for the node and a given user within the subgroup is determined (in test step 530) to be within acceptable linking distance of that room (where acceptable linking distance may be defined by user preferences or by the system), then control is passed to step 533.
In step 533, the subgroup member who is deemed to be within acceptable linking distance of a on-topic room is removed from the subgroup. In other words, if Sam 111 of
Still floating users (those not yet paired to a room) who have not been culled out from the subgroup by step 533 get passed on for processing by step 534. Here, the process mentioned above for Sally 121 is carried out if sally is one of the still floating users. Floating room 561 is spawned for her and she is deemed the foreperson of the room. Then the linked list that was earlier generated (in step 527) to identify the closest other users is stepped through, and the still floating other users remaining on her linked list are hypothetically added into the floating room 561 one by one with linking distance adjustments between the room 561 and users being made on the fly. At some point, one or more limits associated with the floating room will be approached, such as too many invitees or too many relatively long linking distances, etc. At that point control is passed to step 536. The limits of each hypothetically joined user to that room is also tested. It could be that although the room's distance limit was not surpassed, the user's personal limit was surpassed. so that user is returned to the floating users pool in hope that some other room will pick her or him up. In step 537, the still attached users are removed from the floating pool and their corresponding chat opportunities are handed back to the DsMS for final scoring and sorting. As in step 533, users whose identifications are passed into step 537 with an associated chat room (e.g., 561) may still nonetheless not get invited to that room. In some cases, a floating chat room (e.g., 561) may end up devoid of any potential users other than its original foreperson (e.g., Sally). There is no point in inviting Sally alone into her own private chat room. So the trial and error room matching gets undone in step 539 and that is the end of the trail for that room. It is dissolved. Sally may still get picked up by another floating room which has someone else as its foreperson (e.g., Sandra). If not, no harm arises. Sally merely does not get an invitation as a result of this one of many match-making runs. As mentioned above, in one embodiment, room median, average or other attributes are determined at predetermined attribute checkpoints in time and held constant as such until the next checkpoint.
It is to be noted that the floating room which emerges from step 537 with two or more invitees paired to it, may still never come into fruition. All of the invitees can turn down their invitations or not accept in a predefined time, in which case the reserved but still unfilled room is automatically dissolved. Moreover if only one user (e.g., Sally) accepts the invitation, an apology message may be returned to her explaining that the room has been terminated in the interim (because there is no point in inviting Sally alone into her own private chat room) and the reserved but still unfilled room is automatically dissolved. In one embodiment, users who turn down invitations or are the lone ones accepting for an otherwise empty room are automatically added back with their corresponding clustering data (old CFi's) into the floating users group of a later run of step 520 so they have a chance of being joined with new users also being processed by that later execution of step 520. In one variation, this add back feature is employed only if the age of the old CFi data sets of the uninvited or lone invited user does not exceed a system predefined aging limit. If the CFi data set is over aged, it is dropped. The user may get further invitations after submitting fresher CFi data.
Referring back to
Referring to vertical column 157 (chat room properties), these criteria are directed to statistically averaged or other global properties for the chat room (or proposed chat room), this being distinguished from the positive or negative criteria attributed to individuals already participating in such rooms. A user may leave columns 155-156 blank while only filling in criteria in column 157. In the illustrated example user 121″ has indicated that she prefers a chat room which has ten or fewer people (or alternatively she prefers a room with a “cozy” population range of 5 to 9 participants, but no fewer or no more). She has indicated a preference for a chat room where the average age is 16 years old. She has indicated a preference for a chat room where the male to female mix ratio is 20% to 80%. She has indicated a preference for a chat room where the average participant income is $50,000 per annum. Moreover she has indicated a preference for the mean location of the users within the chat room to be the central portion of the USA. Once again the server assigns positive or negative, weighted or unweighted values to these qualifiers that work to respectively increment or decrement cumulative scores for given chat room (whether already existing or proposed to be formed) relative to user 121″. The potential invite score goes up or down depending on how many of the desired or undesired properties are met by the proposed or preexisting chat room.
Referring back to vertical columns 154 (“mine”), 155 (desired them) and 156 (undesirable them) as well 157 (users in chat), there is one class of additional demographic information that is valuable to include at least in the “mine” column 154 if not in the other columns. This is the general favorites information which is shown in box 154-7a. Each user (e.g., 121″) may have certain system-defined “topics” of interest or topic domains of interest which that user is generally interested in. When the match-making service in cloud 150 is trying to associate a most likely topic of current interest with a received CFi (or recently received plural CFi's), the match-making service can look to the favorite Topics entries (represented by the dot in 154-7a that intersects with column 154) of the user's “mine” column and use that as one of the clues in determining automatically what topic the user currently is most interested in conjunction with the current content areas of engaged focus. Thus, even if a given user does not have DsCCp's filled out for use in providing automated inferencing of the user's topic, the favorite topics entry 154-7a in the user's CpCCp can be used as a clue.
Aside from listing favorite topics and/or favorite domains in box 154-7a (where same or different instances of the box apply respectively to columns 154, 155, 156 and 157, where for 157 it defines favorite topics of a potential preferred or non-preferred chat room), the user may additionally list favorite books, favorite movies, favorite (most often visited) URL's/web pages, favorite games, favorite TV shows, favorite music, favorite foods, etc., not only for him or herself (mine) but also as attributes for desired and undesired chat partners or predominant population attributes of desired or undesired chat rooms. By way of example, a given user may list “Gone With the Wind” as her favorite book and at the same time list the same book as being an undesirable favorite of other users in chat rooms she is to be invited into. This in essence says, I like “Gone With the Wind” but nonetheless I prefer not to enter chat rooms filled predominantly with others who like “Gone With the Wind”.
There is often a limit as to how much detailed information can be practically given in row 171 and its crossings with columns 155, 156 and 157. For example, in one embodiment, the number of names for desired chat buddies may be limited in column 155 to just three for a nonpremium user and seven for a premium user. More specifically, column 155 may list the following desirable chat partners: (1) Name:=MBGFFL, (2) Name:=Sharon and (3) Name:=Sandra for CpCCp owner Sally (121″). The match-making system may be pre-programmed to score these as linearly summed positive scores. More specifically, for each desirable chat partner already inside a potential chat room to which the current user is to be potentially invited, increase the Invitation_score by +1. So if only MBGFFL is in a potential room, that room's score is increased by +1. If all three of the listed desirable chat partners are present, then by +3. If the topic being discussed in that room doesn't closely coincide with the topic on the current user's mind (let's call her, Sally), that room's Invitation_score by reduced by a −5. However, suppose Sally wants to secretly impose the following special condition: If a potential room include MBGFFL AND Sharon BUT NOT Sandra, I want to be invited in irrespective of what the topic is. To this end, the knowledge-base rules set 175 may be embedded into or logically linked to Sally's CpCCp of the moment, 105h.1. The utilized knowledge-base rules set 175 may contain the following special rule: IF Room_member=MBGFFL AND Room member=Sharon AND Room member=! Sandra THEN Increase that room's Co-compatibility score by +25. (Here, the symbol=! is understood to mean, not equal to.) As seen the special rule is primarily personality based rather than topic based. Topics are topics of the room (if any topic at all, else it is deemed a “catch-all”) and not the topic which the current user is probably thinking about. (This is a subtle difference which will be better understood when DsCCp's are discussed below. It is to be noted that there are at least two different kinds of catch-all rooms, namely, those where even though the topics on its users' minds are not the same, at least the content of current focus is substantially the same; and those where neither the content of current focus nor the topic on its users' minds are the same but the in-room users are nonetheless chatting with each other and thus perhaps converging on a topic of common focus. In one embodiment, each chat room's attributes are deemed to be frozen in time for regular intervals; e.g., every 5 minute stretch, 10 minute stretch, 15 minutes, etc., even though users may be constantly entering and leaving the room.)
When combined with the base rule of column 155, row 171, the above IF/THEN rule concerning who the current room members are, and are not, basically says, Sally likes each of MBGFFL, Sharon, and Sandra alone and even more so when they appear in any combination in a room; but Sally especially likes it when both of MBGFFL and Sharon are present but Sandra is not. Perhaps this is so because Sally feels that a special social synergy exits for Sally when this particular combination of personalities is present in a chat room together with Sally. The personalities-directed rules set 175 may be formulated with aid of an electronic questionnaire that Sally fills out. The data storage capacity of the personalities-directed rules set 175 may be progressively increased to higher limits in accordance with higher level premium subscriptions that Sally pays for. Standard subscription users may be limited to having only relatively simple and small personalities-directed rules sets 175 while premium subscribers are allowed greater complexity and a greater number of rules and/or more storage space. Personalities-directed rules sets like 175 are not limited to specifying special rules about other users. They may be directed to personality quirks of the current user (e.g., Sally). Suppose for example that Sally does not want to be invited into Domain 5 chat rooms (a hypothetical domain name) if the time is between 2 PM and 5 PM and she is still at work. A corresponding rule might then read as follows: IF Room's_Domain_Name=5 AND (Time >2 PM AND Time <5 PM) AND My_Location=Work THEN reduce room's Co-compatibility_score by −30.
It is to be understood that just as system limitations may be imposed on the number of desired chat buddies who are individually listed in column 155, row 171 (essentially as equally weighted members of a linearly summed scoring value), there can be similar limits placed on the number of undesired chat buddies who are individually listed in column 156, row 171 (essentially as equally weighted members of a linearly summed and negative scoring value). Similarly, there can be system defined limitations imposed on the number of age ranges entered for the “Age” row of column 153 as it crosses with each of preference specifying columns 155, 156 and 157. There can be system defined limitations imposed on the number of socioeconomic class identifiers entered for the “socioeconomic class” row of column 153 as it crosses with each of preference specifying columns 155, 156 and 157 and so on. The knowledge-base rules set 175 may be used to expand on these limits and provide specialized scoring rules for specialized permutations of various ones of such preference parameters, including for cross subclass combinations. More specifically, one rule might read: IF Room's_Current Population <10 AND (Avg Age Range is 14-17 OR 35-39) AND M/F Mix is in range 20/80 to 5/95 THEN increase Room's Co-compatibility score by +100.
It can be bothersome for users, especially newcomers to the match-making and invitations-generating system (MM-IGS) to fill out long electronic questionnaires from which their respective CpCCp's can be automatically formulated. In one embodiment, so-called template CpCCp's and template knowledge-base rules sets (e.g., 175) are prestored in the system for initial assignment to new users. Each new user may be initially asked to fill out a very short demographics questionnaire (e.g., just name, age, gender and place of birth or residence) from which a stereotyping model of the user is developed. The developed stereotyping model is used to select for that user, one of the prestored template CpCCp's in the system and optionally also one of the prestored template knowledge-base rules sets. (The same stereotyping model may also be used to select for that user, one of prestored template DsCCp's and PEEP's and optionally also one of prestored and respective template knowledge-base rules sets for domain specific rules and emotional expression rules.) Then later, as each new user continues to use the system, corresponding models of the user's personality likes and dislikes are refined and improved over time as are also models for the user's topic likes and dislikes and for the user's personal ways of expressing different emotions or mind sets. The refined and more accurate models may be used to automatically pick for and assign to that user correspondingly better matching ones of the template profiles and/or template knowledge-base rules sets. Even later, as a user becomes more skilled in utilizing the match-making and invitations-generating system (MM-IGS), the user may be empowered to fine tune his or her personal CpCCp and DsCCp's and knowledge-base rules sets or the user may employ an authorized service provider authorized by system administrators to perform the fine tuning for that user. Additionally, background fine tuning service running automated in the background of the system may analyze trending data about the user and fine tune his or her rules even more. By way of example, suppose the user named Sally has created for herself a CpCCp rule (175, item 3) that says: IF Room's_Domain=Celebrity_Gossip and MBGFFL is a member inside the room THEN increase that room's co-compatibility score by +100. However, on analyzing Sally's actual behavior as stored in the system's trending storage (437 of
Unlike the demographics data 171 in vertical column 154 (“mine”) of
While reputation is generally earned as a matter of popularity, (voted on by either credentialed voters or non-credentialed voters and/or or by either voters with high reputations or with low reputations when in trustworthy states of mind), credentials and subject matter proficiency are another matter. Credentials (horizontal region 173) are mostly fact-based attributes of the given user. Credentials may define for example, what the educational qualifications of user 121″ are, what schools she attended, what grades she got, etc. These attributes can be validated by obtaining official transcripts from credential giving and validating authorities. In one embodiment, users have to pay service fees to the credential giving authorities in order to have their listed credentials displayed as having been validated to one validation level or another. Accordingly credentials may be of an officially validated type as well as of an unvalidated type. In one embodiment, each user gets 3 free nonvalidated credential files, for example, one relating to their educational background, one to their work resume or experience, and a third related to a first-chosen topic (A). Additional fees must be paid to the system operator to support additional credentials for further topic areas and also to support validated credentials as opposed to unvalidated ones. Proficiencies are determined based on community standards and community cast votes in different domain and topic arenas.
For some users, credentials (row 173) may be the most important type of preferences to indicate for being invited into a given chat room or not. Some users may prefer to deal only with chat rooms that contain other persons who are equally credentialed in a specific topic (e.g. topic B) and to have validated educations at the masters' degree level or higher. In the illustrated example, user 121″ has indicated in vertical column 157 that the desired chat room credential properties should be that of the lowest educational level being a validated high school graduate and the highest being a master's degree. Additionally she has requested that the chat experience of those being invited to join with her into an by-invitations-only chat room be ones who indicate little or no experience with chat rooms. Additionally, user 121″ has indicated a particular superior to subordinate participant mix. Most specifically she has requested that the 70% of the people in the chat room that she is invited to join (or host) should have peer credentials similar to her own and 20% may have superior credentials while only 10% or less have inferior or subordinate credentials. She has requested to be considered as one of the peers. (Complex invitation criteria, by the way, may be specified in rules set 175 rather than in the main body of the CpCCp.) Alternatively she could have requested that she be considered a subordinate user and that one or more persons with superior credentials should also be in the chat room to advise her on an area in which she is not an expert. Alternatively she could have requested that she be designated as a superior credentials or proficiency member of the group and everyone else be of a subordinate credentials class. These preference options can be very important because it allows the user 121″ to control the type of interchange that will occur in the chat room she is invited to join (or that she indirectly invites others to join). For example, if she wishes to obtain advice from other chatterers who have superior credentials in a particular topic area (e.g. Topic C) relative to her credentials in that topic area, then she may ask for a mix where she is part of the subordinate participant class. On the other hand if she wishes to converse with people of equal credentials to her own, then she may insist that most people in the chat room (e.g. 70%) including herself be of a specified peers class. Similarly, an expert in a particular field, say financial advice, may wish to chat only with people with lower credentials for the purpose of providing them with financial advice (perhaps for a fee). In this case that person would designate himself as the sole member of a superior credentials class within the group and allow for 99% subordinates (e.g., novice class) and also control the size of the group so as to keep the conversation small and controlled.
In general, it may be seen from
Thus far, for users 121′, 131′, 141 it was assumed in
A Domain-specific Chat Compatibility profile (DsCCp) such as the one 106h.1 shown in
More to the point, a root DsCCp such as 106h.1 in
Yet another of the topic-narrowing hints 188 provided by the user's root DsCCp 106h.1 may be a collection of recently used search terms entered into a search engine. Say for example that the user's recent search history includes the search term “economy” as one of the top three most recently used search terms. That in combination with DsCCp entry of “economy” in a corresponding row of column 186 can be taken as a hint that the user 121″ is most probably currently focused on either the Finance.002 domain or the Politics domain. This may be so if table 183 indicates those two domains as the most highly likely two tied to the “economy” search term entry placed in table column 186. The illustrated “economy” entry may be logically tied for example to a first probability weighting pointer 186b that shows 48% probability of linking to the Finance.002 domain, a second pointer (not shown) indicating 47% probability of linking to the Politics domain and further pointers (not shown) with 5% weight distributed to other domains.
Weighted pointers are way of linking keywords to most probable domains. A more flexible approach to determining what the more probable domain and topic of interest is uses a set of knowledge-base rules such as shown at 195. In one embodiment, topic likelihood scores are made functions both of the one-to-one horizontal correlation hints provided in columns 185 and 186 as well score adjustment rules specified in the DsCCp knowledge-base rules set 195. More specifically, reading across subrow 4 (“Poker”) of row 191 of
Data in the DsCCp's may be adaptively changed over time as the user's preferences change. For example, the ordering of domains (column 183, major row 191) may be changed to reflect different preferences in case where no additional hints (no keywords, no URL's etc.) are available. The more frequently associated URL's, keywords, meta-tags for each listed domain or topic of column 183 may be changed in response to detected changes of the user's preferences over time. One of the feedback mechanisms used for automatically detecting such changes is when the user turns down initially offered best-guess invitations and instead accepts an invitation with a substantially lower likelihood score. That tells the system that the user's mapping of hints to likely target topics have shifted.
Table column 184 indicates a length of user history associated with each domain and optionally includes pointers to history records for the respective domains and what priority positions they held in the past. If there is long history of one domain being in the top three for example, then this historical trend may generate a sort of inertia for domain reordering algorithms which works to keep the top three domain with long history of being there from suddenly being dropped say out of the top ten list. The illustrated domain and topic picking structures of
In addition to domain-narrowing hints such as shown at the top of major column 188 for main topic domains, the root or a child DsCCp may include hints such as shown at major rows 192, 193 for specific topics or subtopics under respective domains or topics. Thus the DsCCp may be used for automatically homing on the most probable topics of current interest by the given user.
As mentioned above, users may have weighted preferences (likes and/or dislikes) on a domain by domain or topic by topic basis, on a chat partner by partner basis (different weights for different partners, e.g., positive scores that involve MBGFFL get a +1.3 multiplying boost factor just because MBGFFL is Sally's best friend for life; and negative scores involving MBGFFL get a 0.9 watering down weight for the same reason). Users may also have weighted preferences on a room type by room type basis (e.g., if a potential room is limited to a range of 3 to 5 participating members, its positive co-compatibility scores are automatically boosted by a +1.5 multiplying factor because Sally considers this population range to be a sweet spot).
In one embodiment, in-profile weights are automatically updated based on determinations made by the system's trending data monitoring services. In other words, a given user (e.g., Sam) may expressly record that he prefers to chat with people his own age. However the system's trending data monitoring services may determine based on actual historical data regarding his chatting activities that he actually doesn't care so much about age and instead most prefers to chat with people who are history enthusiasts. In this case, a weight given to age may be automatically decremented while a weight given to history being a favorite topic may be automatically incremented in Sam's system-stored profile(s).
In
Referring to
The current focus identifier or indicator (CFi) may come in a variety of types. Type of indicator is specified in data field 215e. A number of examples are given although these are non-limiting. It is possible for one CFi packet to contain plural sets of fields like 215e, 216a-216g, 215f-215h all covered by a same time stamp 215d and one digital signature 215i. A current area of focus may be identified by providing only a URL (Universal Resource Locator) for a web page that the current user happens to be looking at. (Or as will be seen in
Because the actual focus and/or topic-of-interest indicating data field (as opposed to its type) may be of varying length or of multiple packets, a data length indicator 215f is provided within each CFi packet for indicating length of a current data field and/or a number of multiple packets or records through which the data field continues and perhaps where the last character is found. In other words, the referenced data field, 215g (which contains the indicator data whose type has been specified in field 215e) may be fully contained in the same single record as length indicator 215f or it (215g) may extend through plural subsequent records or packets. Following this variable length field 215g, is the specified data field 215g Additionally, one or more biometric data points and/or intensity indictors (along different dimensions, e.g., emotional versus topical) may be provided in following fields such as 215h. In one embodiment, the biometric data points and/or intensity of interest indicator(s) 215h may be each expressed as a whole number selected from a prespecified range, say 1-10, to indicate for example how strongly the user is interested, emotionally or otherwise in the identified topic area (for example the one whose identification and intensity is based on associated mouse activities and/or eyeball activities). Alternatively other forms of measurement for biometric data points and/or level of focus and/or interest indication may be used including positive and negative number ranges expressed in scientific notation form or otherwise. To prevent current focus indicator packets (CFi's) from being spoofed by users or machines other than the ones identified fields 215a, 215b a digital signature 215i covered by a user password (e.g., hashed) may be used to cover one or more of the fields in the CFi packet and to thereby assure its authenticity. The cloud system 150 securely stores the user's password so that generally speaking, only it (and authorized system administrators) and the user know the passwords. When the user logs into her local machine 211, she may be asked to supply the password and this is used to form the digital signature, for example by hashing packet data with the password. In one embodiment, although not shown, the cloud sends a random piece of additional data to the local machine during log-in and this random data is combined during a logged-in session with the password so as to assure that the password cannot be reverse engineered from the digital signature. In one embodiment, the client machine includes face recognition software and/or fingerprint recognition software and/or iris pattern recognition software for identifying the user currently operating the primary likelihood client machine. In one embodiment, the client machine automatically presorts the recent CFi's posted onto buffer 215 according to biometrically or explicitly detected level of interest so that recent CFi's with the highest degree of user expressed or inferred interest are presented closest to the output pointer of the buffer and thus pulled (207b) by the cloud first and given preferential treatment in this way over CFi's that are associated with substantially lower levels of user interest or user engagement with their content.
As the cloud system 150 scales to have larger and larger number of users (e.g., clients), it becomes possible to have millions of client machines (e.g., 211) arbitrarily uploading (e.g., requesting pull up of) their current focus/interest indicators (CFi's) in unsolicited manner into the cloud with the expectation of instant servicing. To avoid this possibility, it is preferable for the cloud 150 to control the rate at which it acquires current focus indicators (CFi's) from different user machines and/or for different domain and/or topic areas. In one embodiment, all current focus indicators (CFi's) generated by the generator 206 of client 211 are stored on a scrolling or circular buffer 215. The cloud 150 does not necessarily pull all new CFi's out of the buffer 215 at one time. Instead, the cloud 150 sends periodic CFi-Pull Requests 207a to records puller 207. (In one embodiment, the CFi-Pull Requests 207a are preceded by the client machine 211 sending a buffer status reporting packet to the cloud 150. Such a buffer status reporting packet (not shown) indicates how much uploadable buffer content is available and its nature. The cloud then responds in a form of a handshake by downloading the CFi-Pull Request 207a.) The CFi-Pull Requests 207a may contain filtering criteria for selectively pulling only those recent CFi's whose time stamps correspond to a certain time span and/or for CFi's whose topic hints correspond to a certain topic area or domain of interest and/or constitute a limited number N of most recent ones of such criteria matching CFi's that are to be pulled. In response, the puller 207 scans the local buffer 215 for CFi records that match the CFi pull request 207a and it uploads via path 207b only the CFi's that match the pull request 207a. In this way, the cloud can control the rate at which current focus/interest indicators (CFi's) are pulled from individual client machines and also it can limit the topic area(s) or other attributes of the selectively pulled CFi packets. In one embodiment, the puller 207 periodically uploads a pinging packet (not shown, sent for example once every 2 minutes) to the cloud 150 indicating “I am here and I want a pull request from you” where the pinging packet identifies local machine 211. If the cloud 150 (and in one embodiment, an AARMS portion of the cloud—described later) does not receive such periodic pings for more than a predefined length of time (say 5 minutes), it assumes that the client machine 211 has been turned off or has gone into an interest_monitor=off mode (see 312 of
Within cloud 150 there may be a plurality of different types of CFi pulling servers (or virtual services, not all shown) such as 151a and 151b of
Field 235J may contain a system recognized unique identification code for specifying the chat room (or other online forum) whose contents or participants are being voted on. Not all chat rooms necessarily have such a system recognized unique identification code fitting into field 235J (e.g., the topic node ID plus chat room number under that node) which is why URL or other identifications may be provided in fields 236a-236f. Once again, as in the case of CFi's, a user password plus random session number may be used to form a digital signature that covers the Cvi content and this prevents vote spoofing. The entire voting record (Cvi) may be covered by appropriate encryption when transmitted over an untrusted or public channel.
In order to control resource bandwidth usage and allow for scaling, the cloud system 150 controls the rate at which Cvi records are pulled from each of the local machines 211′. Accordingly, Cvi pull requests 237a are sent from cloud 150 to the Cvi records puller 237 of local machine 211′. The Cvi records puller 237 responsively returns the requested type of current vote indicator record(s) 237b to the cloud. In one embodiment, the Cvi records puller 237 routinely pings the cloud to let the cloud know that the local user is still engaged with one or more system associated chat rooms and is thus probably casting implicit or explicit votes regarding those chat rooms. In one embodiment, these pings come in the form of Cvi buffer status packets that report on the status of buffer 235, its size and nature of data stored therein. If the pings stop for more than a predefined stretch of time, the cloud can interpret that as the user having shut off his client machine or disengaged the monitoring function and the cloud stops trying to pull Cvi's from the Cvi buffer 235. Once again, the cloud may include standard and premium service servers 151d and 151e which provides Cvi pull requests at different rates depending on whether the user is using a standard service or pays for a premium service. The pulled Cvi responses 237b are forwarded to a chat room vote collecting server 151f. This server 151f sorts through the various votes and allocates them to various users or chat room content as indicated by the content of the pulled Cvi. Contributors who receive consistent thumbs up (positive votes) from other users in a given chat room generally have their corresponding reputations incremented. Conversely chat room contributors who have their contributions consistently voted down by other users receive negative scores and thus receive decreased reputations in the CpCCp “mine” records. Additionally, the content contributed by the various users may receive positive or negative votes and these votes are further accumulated. In one embodiment, the vote results are sent to a targeted advertisement server 151g which uses the collected information to better gauge how users are behaving relative to their viewing of various topics at the current time. In response, the advertisers may automatically or manually adjust their advertisements strategy and/or their offered product mix accordingly.
A complex set of operations may occur in the cloud 150 between the time that CFi's and/or CVi's are pulled and invitations come back or other responsive activities take place (e.g., automated bifurcation of a chat room to thus separate warring participants). Just briefly and with reference to
Referring to
An example of a possible invitation record data structure is shown at 255a-255k. Similar to the cases of
The focus/domain/topic identifier field 255f may denote which one or more focal areas of the user's screen content and/or which domain and/or topic/subtopic the incoming invitation (Cciv 257a) is directed to. As was the case with
As was the case with
Similarly, entry 255J indicates the degree of chat co-compatibility between the user and the cumulative attributes of the invited-to chat room. Not all users will be found to be exactly co-compatible with existing or to-be-formed chat rooms. However, the invitation generating services/servers 151h-151i may nonetheless have elected to send an invitation to the user with an indication 255J of how far apart the user's preferences are for an ideal chat room as opposed to the cumulative attributes (e.g., average chat partner education, age, etc.) of the actual chat room for which the invitation is directed. The degree of co-compatibility indication 255J may be used to determine how the invitation is displayed on the user's invitation radar (e.g., that of
By way of more specificity, user editing and/or saving functions enabled by the file control menus 311 may include menu options for performing invitation system related actions such as changing passwords, updating account subscription levels, entering or changing demographic information (e.g., user indicates he moved to a new address, his income level has changed, etc.), or entering preference data change requests (e.g., user indicates he no longer wants to chat with people under 25 years old). These invitation system related menu options under 311 (specific options not individually shown) would be saved locally in one embodiment and then uploaded to a cloud server when bandwidth opportunistically becomes available for such uploads of account changing data. The altered account settings would then be reflected back from the in-cloud server to multiple client computers of the user. Thus universal changes to account settings can be made from any user client machine. In one embodiment, an email is sent to a user selected email account informing of the account setting changes. In one embodiment, menu options for modifying account settings and/or profile preferences are provided as task orientated and context triggered options rather than as universal file orientated options. For example, a menu option for updating a list of other users whom the client likes or dislikes may be automatically provided in an instant messenger window under a simple “buddy list” menu entry. When the user adds, deletes or changes the local list, the changes are saved and uploaded to the cloud so as to become universal changes under that client's account settings.
In a menu bar area directly below menu bars 311 and 312, a chat opportunities banner or marquee 315 may be scrolling through. In an alternate embodiments, the opportunities banner 315 may appear along any one or more of a bottom, left or right side edge of the screen or as a pop-out menu bar that pops out only when the user moves cursor 335 to such an edge. The items in the illustrated banner area 315 may scroll for example from right to left to indicate chronological ordering, where items on the left side of the screen (e.g., shrinking bubbles 315z) disappear after crossing beyond the edge and new items (e.g., enlarging bubbles 315e) appear to emerge from the right edge of the screen. In an alternate embodiment, items (e.g., 315c) that are drifting towards and/or are positioned near the middle of the banner area represent the most important (most highly scored in terms of topic and chat co-compatibility) among the most recent invitations while less important and/or older items (e.g., 315a, 315z) are displayed as reduced in size, shrinking and moving off the end of the banner, this indicating they no longer correspond to the user's current area of focus in terms of content and/or topic of interest. In yet another embodiment (mentioned above) plural U-shaped-like flows (with possible short circuiting tributary flows between symmetrical halves of the U-shapes) may converge from edges of the screen or a window towards a central area such as 315c. The scrolling-in-and-through-and-out opportunity icons or items 315z, 315a-315d, 315e represent respective invitations into different chat rooms, otherwise referred to here as chat opportunities. Each invitational icon (e.g. 315a) may have respective internal text, a background color and/or foreground graphics at its center for indicating the topic or domain to which it applies and/or the urgency or importance of the invitation. In one embodiment (although not all shown), the opportunity icons transform from incoming opportunity bubbles (315e) into animated cartoon or other faces which grow in size, agitation and/or opaqueness as they drift towards the banner area representing greatest importance, current relevancy or urgency of the invitation and then the animating faces (e.g., talking heads not shown) drift outwardly again and shrink back into aged bubbles (315z) that finally drift off screen.
If the user hovers a mouse cursor (e.g. 316) over one of the slowly scrolling-by chat opportunities (e.g., 315a) for a predefined length of time (dwell time, challenge time) or clicks on it, then a corresponding and more detailed informational window opens up (e.g., and informational balloon, not shown) which provides the user with more detailed information about the domain and topic of the given chat opportunity (e.g., 315a). In one embodiment, the more detailed informational window appears as a semi-transparent window hovering over one of the already open content windows such as 317. This indicates that the challenged chat opportunity (e.g., 315a) corresponds to content found in window 317. In one embodiment, one or more keywords related to the challenged chat opportunity (e.g., 315a) glow or otherwise become prominent to indicate they are especially related to the currently challenged chat opportunity. In the illustrated examples open window 317 provides a frame of content obtained from a remote or local URL (universal resource locater) denoted as www.URL.com/A4. If the cursor-challenged chat opportunity 315a corresponds to specific content within open window 317, then in an alternate embodiment, the border of the corresponding window 317 glows or changes color or flashes and/or specific content within that window 317 becomes enlarged and/or bolded to thereby indicate the correlation between that specific content and the challenged opportunity. Additionally or alternatively certain keywords or images within open window 317 may become temporarily underlined and/or highlighted in a different color as the user moves his cursor mouse 316 challengingly over the scrolling-by and interrelated chat opportunity (e.g., 315a). In each of these cases, the temporarily highlighted window and/or temporarily highlighted content within one or more of the open windows (e.g., 317, 318, etc.) indicates to the user how the chat opportunity (e.g. 315a) corresponds to those already opened content frames or windows on his display 300 and/or to content within those one or more windows. In one embodiment, the vise versa is also true; namely, if a user right clicks on or otherwise highlights content (and optionally picks a show invitations option), the corresponding invitations in the invitations display area 315 glow or otherwise make their identity known to the user.
If instead of hovering or once clicking, the user double left clicks his mouse 316 over the available chat opportunity (e.g. 315a) then a new chat room window such as 316a opens up along an alternate side edge (e.g., left) of the screen. Of course, in the same or other embodiments, the user can use other pointing devices and/or hand gestures and/or voice commands to effect the opening of a chat room window based on an offered chat opportunity. The newly opened frame 316a may include room identification indicia (e.g., “Room A0”) as well as an interior frame showing a transcript of the latest conversations occurring in substantially real time within that room (A0). For example, it is seen at 316d that Sam and Sally are conversing in essentially real time in room B3 about something in yesterday's newspaper editorial. The local user can then quickly review the content of what is currently occurring in the newly displayed rooms (A0 and/or B3) and decide for himself whether to keep that chat room window open on his screen or to close it down. If the user quickly shuts down the just-opened chat room window (e.g., A0), then this event is reported by the local activities monitor (LAMS 105x) to the remote match-making and invitations-generating system (MM-IGS) and appropriate services within the remote cloud take that event as a negative vote against the offered chat room invitation 315a, this perhaps indicating to the remote matching service that the match-making part of the service guessed wrong as to what topic the user was thinking about and was interested in chatting about. On the other hand, if the user leaves open the just-opened chat room(s) (e.g., A0, B3) for relatively long times and/or begins to actively scroll through the transcript and/or begins to contribute to transcript content (316d) in one or more of them, then these respective local activities are interpreted as affirming to the remote cloud, at respective progressive levels of increased confidence that the remote matching service had guessed correctly as to the user's interest in the topic of this particular chat room and as to the user's co-compatibility with this particular chat room. Room scrolling arrows such as down pointing 316f and the up pointing one below 316e may be used to review newer or older opened rooms. Both negative and affirmative responses to challenged or newly opened chat rooms (or challenged older and re-reviewed rooms) are used by the remote matching service as feedback information for actively learning about the user's preferences and to adaptively adjusting the user's preference records (e.g. DsCCp's) accordingly. Additionally, biometric data collected from the user at the time he challenges or first opens and exams a chat room can be used by the remote matching service as feedback information for actively learning about the user's preferences.
In one embodiment, after a given chat room transcript window (e.g. 316b) has been open for a relatively long predetermined time, a new scrolling side band such as 316c appears adjacent to that transcript window 316b. The icons of scrolling band 316c represent chat opportunity offers made from inside of the already opened chat room 316b. In this case the chat opportunities 316c are those that are more closely related to the content inside of transcript 316b and, as in the case of the main screen scrolling banner 315, the user may mouse over and click challenge (or otherwise challenge) one of the icons in scrolling banner 316c to learn more details about its content. Alternatively, if the user is annoyed by the presence of in-room opportunity banner 316c, the user may click on a menu-provided control which removes scrolling banner 316c from window from 316b. In one embodiment, the in-room opportunity banner 316c is not displayed until the system detects (from biometric data) that the user is showing fading interest in the currently open chat room 316b, at which point the in-chat invites banner 316c automatically opens to show potentially better opportunities. Additionally in one embodiment, the user may explicitly request opening of the in-chat invites banner 316c by activating an appropriate menu option. Each of these various user actions (e.g., close in-chat invites banner 316c, explicitly open same, etc.) may be flagged by the LAMS 105x to the remote matching service 150c to indicate that the scrolling banner was respectively annoying in one case to the user and that user prefers not to have it offered at least in the same context or that the scrolling banner was respectively desired by the user and that user prefers to have it offered at least in the same context. The remote match-making and invitations-generating system (MM-IGS) takes note of this behavior, optionally changes in-system knowledge-base rules stored for the user, and adapts accordingly. One of the adaptations may be to increase the length of time before a chat-room internal banner such as 316c is offered to the user. Another possible adaptive behavior is to ask the user whether he no longer wants to be offered such in chat room invitations to interrelated other chat rooms either for the specific topic area or domain or for all domains. Alternatively, the user may elect to shrink and hide the side banner 316c just along a side edge of chat window 316b and to have it responsively pop out when he mouses over to that extreme side. Just as in-chat room window banners like 316c can be hidden from the user at the user's request, the main on-screen invitation banner 315 can also be temporarily hidden from the user's view when the user no longer wants to see it and it can be brought back when the user is ready to see it again. In one embodiment, when the user hides his banner 315, a message is automatically uploaded to the MM-IGS to temporarily halt the match-making and invitations-generating services for this user. In one embodiment, when main banner 315 is minimized for hiding, it shrinks into a small blinking dot at the top or side edge of the screen 300. The user can double click on this blinking dot to reinstate the full and moving scroll banner 315. At that point, the local client machine automatically signals the MM-IGS to resume the temporarily halt match-making and invitations-generating services for this user. Aside from mouse actions for invoking shrinkage-and-hide or expansion-and-resumption of invitations-representing banners such as 315 and 316c, in one embodiment, the user can use keyboard shortcuts, voice commands and/or hand or other gestures that his local machine has been trained to recognize as commands for the desired banner shrink and expand operations. Accordingly, the user may reclaim his screen space for primary functions at times of the user's choosing and de-collapse the minimized banner at other times. Workload for the remote match-making services may be automatically reduced at times when the user cannot see his invitations-providing banner. However, CFi's may continue to be uploaded to the cloud for purpose of learning about the user's current areas of interest (provided interest_monitoring 312 is left turned on). The software and/or hardware for causing the user's local machine (e.g., 115) and the in-cloud remote services 150 to automatically carry out respective ones of these various actions are of course provided in respective hardware and/or software resources provided in each as appropriate, where this will be understood by skilled artisans in the relevant useful arts after reading this disclosure.
In addition to providing a scrolling-through display of a handful of current chat opportunities 315a-315d, each opportunities offering banner such as 315, 316c may include chronological “more” arrows such as 316e and 315f at one or both of their extreme ends. An old side “more” arrow such as 316e allows the user to recall and enlarge older items (e.g., 315z) that had shrunk and/or passed out of sight beyond the left edge. (In one embodiment, arrow 316e points to the right rather than left.) A newer side “more” arrow such as 315f allows the user to indicate to the opportunity displaying services (local and/or remote) that the user currently wants the banner 315 to advance more rapidly so that the user is provided with a greater number of new invitations (315e) per unit of time. There can also be a “less” arrow such as 315g whereby the user flags that he currently wants the banner 315 to advance less rapidly or for new invitations (315e) to stream in more slowly. In one embodiment, if the user is not subscribed as a premium user, pressing the newer side “more” arrow such as 315f will automatically bring up an advertisement message such as one telling the user that he or she must subscribe to a premium service in order to be able to use the “more newer” invitations feature 315f.
Icons within the scrolling banner 315 may be differently sized (e.g., proportionally sized) to indicate the degree of topic matching and/or chat personality co-compatibility for chat rooms which the remote service has found. Or the degree may be explicitly indicated as an attached number or meter scale. For example, illustrated chat opportunity 315c may be relatively larger sized and/or differently colored on its border to indicate that this is probably a chat opportunity of more intense interest to the given user at this time than others of the chat opportunities 315a-315b, 315d scrolling along the marquee 315. The displayed chat opportunities 315a-315d may apply to a same chat topic or to different chat topics and/or different domains. The respective chat topics may be indicated by bubble-internal text or bubble-internal graphics and/or by color coding of the surrounding border of each one of radar-like blips 315z, 315a-315d, 315e. In one embodiment, each user may specify through a local display control (e.g. 265 of
Meta-tags 317a that are generally hidden form the user's view (but may be seen in most instances by viewing the underlying mark-up code, i.e. HTML, XML) can come in a variety of types. Examples of possible codes or tags include search-engine assisting/attention-getting codes, popularity engine tag or subject-matter categorizing codes, and hierarchy navigation codes. Search-engine assisting/attention-getting meta-codes or meta-tags can be of the type that web content authors embed in their web source code to direct search engine searches or social networking services to the given content (or to draw attention of the same to the given page) based on search words (e.g., keywords) that a lay user is expected to enter into a search engine service (e.g., Google™, Yahoo™, etc.).
Popularity engine tag codes or “tags” appear in separate popularity engine web pages adjacent to an identification of the URL that is being popularity-wise rated by users of the popularity-based rating engine. Authors of source content may sometimes embed in their displayed web page, redirectors (e.g., Digg-It!) that when clicked, link the user to a corresponding user popularity rating engine (e.g., social network reputation rankers such as Delicious™ (a.k.a. Del.icio.us™) Reddit™, Digg™, Stumbleupon™) where at the engine site, popularity engine tag codes (“tags”) or subject-matter categorizing codes (e.g., photos, humor, movies, books, etc.) appear for purpose of categorizing the to-be-rated web page according to categorizing tags. The subject-matter categorizing codes or tags may be used alone or in combination to hint at a corresponding topic. More specifically, if a user of the MM-IGS system (
Hierarchy navigation meta-codes are special ones developed herein for use with domain/topic/etc. hierarchy trees such as shown in
Window 318 shows the local user as watching a web video (having animated images and corresponding audio) relating to topic B. This viewing state of the user may be assumed for example in response to automated detection that the current audio output of the client machine is that generated from window 318. The amount of time spent watching the moving image B and/or fiddling with the volume control may indicate the amount of interest that the user has in that specific topic. Window 319 shows the local user as listening to a podcast. Once again, that state of affairs may be assumed for example in response to automated detection that the current audio output of the client machine is that generated from window 319. The current volume setting and/or fiddling with the volume control may indicate the amount of interest. Additionally, the user's local camera (116) may spot him as tilting his head back and looking away from the screen while concentrating on the audio content. Meta-tag data may be buried in the digitized audio and/or video (e.g., in horizontal or vertical blanking intervals) to indicate the likely topic of interest and this meta-tag data may be uploaded to the cloud as part of a CFi. Biometrically sensed activities may indicate intensity of user interest in the topic being covered at the time by the streaming audio data.
On-screen content may alternatively or additionally include non-web (non-network originated) material such as a locally stored word processing document 320 that the user is working on, where region 320d may be a section of the document that the user has been currently editing (and for which a recent edits history is maintained and optionally uploaded to the match-making and invitations-generating system (MM-IGS)). In the illustrated example, window 320 has a file-name area 320a indicating a file named, Fifth_Grade_Science.doc. In one embodiment, this information is confidentially uploaded to the MM-IGS in combination with other data (e.g., the recent edits history) for analysis and topic determination. Word processing documents such as 320 often have their data structured differently from that of an HTML-coded web page. Nonetheless, they may have sections that are likely to be topic headings or introductory summaries (320b) of the material below them and thus indicative of the topic the writer is thinking about when working on the document as a whole or on a particularly headnoted section. In this case the writer is thinking about doing a fifth grade science project that involves experimenting with different tasting areas of the human tongue. The file name, Fifth_Grade_Science.doc, gives the match-making service (in the MM-IGS) a first clue. Dominant words or phrases 320c repeated throughout the current version of the document may also be uploaded to the MM-IGS to give the match-making service yet more clues. A recent set of repeated edits made in section 320d (as indicated by the edits history) may give the MM-IGS an indication that the user is having difficulty with this particular section 320d. Given the age of the logged-in user and the clues provided by window 320, and her personal preferences (CpCCp and DsCCp('s)), the in-cloud MM-IGS may determine that the user likely wants to chat with other fifth graders (in somewhat remote geographic locations rather than in her local school district where she is competing with schoolmates) who are doing science projects on tongue tasting. Students can exchange useful insights with similarly situated other students and thus they can come to find the school work much more interesting if they have people to share their experiences with. For example, noncompeting students can share in a common chat room, some of the resource materials they used to prepare their science projects. In one embodiment, the science project chat room may be monitored and moderated by a nongrading teacher who has volunteered to help keep the students on track without interfering with their spontaneity or enjoyment of the chat room.
Alternatively, the reason that the local user has been making repeated edits for a relatively long recent time in document area 320d is because she is having trouble with a grammar issue, or with a sentence structure issue, etc. In other words, she is having trouble with the writing process itself rather than with the overlying subject matter (e.g., the science experiment project). There will be cases where the match-making service (e.g., MM-IGS) will not be able to determine to any reasonable level of disambiguaty whether the user is thinking about the writing process or another issue. In such a case the flow of incoming invitations may be in the form of multiple incoming streams (e.g., like the U-shaped flows mentioned above) and the user picks (if at all) the stream that appears closets to what she is currently thinking about. This pick among different probable topics is fed back to the match-making system and the system then begins to send more invitations in line with the picked topic, while in some cases, continuing to offer occasional invitations for the other possible topics. (Because once a problem with writing style is resolved, the user may continue to edit the same area 320d while this time switching the topic of interest—in the user's mind—to the overlying subject matter; e.g., the science project.)
The types of possible local files (e.g., 320) that the local user may be working on are almost endless, and need not be limited to word processing documents. For example, two or more computer programmers in different locations may be working on a similar coding problem (e.g., for example how does a particular public library function behave when given certain esoteric input parameters?) and they may want to share their frustrations or insights with one another. The match-making system can automatically find such otherwise isolated persons and pair them up for chatting with each other in real time. For example, the local client machine of each computer program writer may detect the local coder's frustration or uncertainty over a certain library function based on biometric indicators collected from the writer. In response, the local client machine software may automatically suggest an uploading of some of the content to the match-making service for purpose of linking the local user into a currently ongoing chat room that is discussing this same coding problem or to another user of predefined proficiency who is currently focusing on this same coding issue. (Since part of the code the local writer is working on may be confidential, the local software 105 is configured to automatically detect that the file content is confidential and to responsively request user permission to upload a highlighted portion with a warning that the user should verify the highlighted portion does not contain confidential material. Thus, in the case where some of the focused-on material may be confidential, the local software asks for permission and provides a warning before uploading the presumably non-confidential subsections of the focused-on material to the MM-IGS. (Even if the material is not confidential, in some embodiments the MM-IGS does not show the uploaded, focused-on material to the other users and thus the material is not in danger of being compromised. As mentioned earlier, in some embodiments the content of the uploaded CFi's is covered by an appropriate encryption process so that other people on the public network (e.g., 430) cannot easily snoop and see what system users are working on.)
Students working on similar school projects and computer programmers working on similar coding problems are just a few examples of the kinds of people that may find each other via the match-making service and collaborate. Lawyers working on similar legal problems may use the system to find each other when their focus is on a same legal issue (for example, what is the definition of a “trade secret” in the State of California?) Research scientists who are reviewing the same non-confidential journal articles may use the system to find each other. Ditto for at home cooks who are reviewing the same recipe, book readers who are currently reading the book(s) of a specific author, and so on. The list can be endless while the benefits of match-making between otherwise isolated local users can also be endless. Each kind of focused-on local file may have its own unique style (e.g., defining where the headings are positioned, where the abstract or summary is positioned, where relevant footnotes or endnotes are positioned etc.) and the match-making service may be configured to recognize and work with different kinds of common styles.
Window 330 shows the local user as using a popular search service (e.g., in a prespecified recent stretch of time) for performing an online search for certain keywords and receiving responsive results. The URL address bar 330a may be used to identify the specific engine and thus infer the data structure of the displayed web page including where the search keywords are located (330b) and where the search results are located (330c). The local client machine keeps track of when the user has last used an available search engine and what content was focused upon shortly before and/or after the search. For example, if the user was editing in section 320d of window 320 less than a few minutes ago and now the user has entered the search keywords, “theory of taste” into keywords input area 330b of the search engine 330a, the match-making service can infer from this that the topic of interest is not one involving a writing style issue but rather one narrowed down to a topic concerning theories for how the sensation of taste occurs. Soon after the search engine returns results in area 330c, the user may move his mouse cursor (335) to dwell over and/or highlight and/or hyperlink to specific ones of the results in area 330c, this indicating differing degrees of increased interest in those specific results. This information may be forwarded via the CFI's to the remote matching service 150c for automated analysis and determination of what subtopic under the theory-of-taste node is currently on the user's mind. The amount of time the user spends in dwelling over or inside specific ones of the search engine results 330c may indicate to the match-making service what the user's current level of interest is in that subtopic or whether the user is having trouble with the search results and wants to discuss the difficulty with like situated other users. Biometric data obtained from the user at this time can help the match-making service to automatically decide whether the user is probably feeling frustration over the results or a heightened interest of a positive kind. The match-making service may then make recommendations (by providing corresponding invitations) one way or another based on the inferred emotional states of the user.
With regard to sensing frustrations or other emotionally charged reactions of local user to something happening or that recently happened on his or her local machine (e.g., search results that do not meet the user's expectation, or chat room developments that upset the user), part of the biometric processing software can be specially directed to detecting expressions of exceptional frustration or other exceptional emotionally charged reactions exceeding the user's norm. The user may verbally express profanities or the like while staring at the computer screen generally or at a particular area on the computer screen for a prolonged period (e.g., more than a second) and/or the user may start to engage in “flaming” activities where the user is projecting impolite content to other users in a chat room or other forum, even if not actually transmitting that flaming content to the others. The special software may use voice recognition modules to automatically detect the unusual use of objectionable language by the user and/or change in voice tonality, change in stress levels or in other vocal system parameters (e.g., including changed breathing patterns) to classify this behavior, if it is markedly unusual for this user, as being an indication of exceptional frustration at or other exceptional emotionally charged reaction to something going on in the computer. Without directly reflecting the detected emotionally charged behavior to the user (because generally no one wants to be directly accused of or confronted with having become inflamed), the match-making service begins to responsively provide invitations directed to diagnosing the source of frustration (and/or other emotionally charged reaction), calming the user and alleviating the underlying source of his or her emotionally charged reaction. For example, one of the chat room invitations flashed to the user after a short cooling off period might be entitled, “Maybe it's only me, but I hate it when my search engine doesn't understand me.” Upon seeing this, the local user may think, ‘Yes, I do too; let me commiserate with this other chat room member who appears situated similar to me’. In one embodiment, the other chat room member is actually an automated psychology module that tries to coax the invited user into venting his or her frustrations and explaining in more detail what those frustrations are directed at. This may be done through a series of pre-scripted question and answer dialogs that are routinely varied so users will not readily catch on to the automated nature of the questioning. The answers that the user provides to the automated frustrations vent absorbing module are converted by that module into CFi's on behalf of the user and sent to the match-making service for matching with other users who have had similar frustrations (and/or similar other emotionally charged reactions) and maybe have begun to arrive at solutions. For example, the user may relate to the automated frustrations absorbing module, “I am trying to find a research paper on the theory of taste for my science project and the (expletive deleted) search engine is not getting me to the right resources.” In response, the automated frustrations absorbing module automatically creates CFi's (as if they had instead been created by the user's local machine) that include key terms such as, “frustrated with search engine X results about theory of taste”. In other words, the automated frustrations vent absorbing module has inserted the emotion-defining keywords that the user him or herself would not be willing to openly admit to. In response, the match-making service finds chat rooms filled with other users facing the same or similar frustrations and/or similar other emotionally charged reactions and perhaps some that can offer solutions. A second user on one chat room may instantly reply, “Yes, I had same problems with search engine X but got much better results with search engine Y and these alternate search terms”. Other examples of keywords that the automated emotions detecting/absorbing module might insert on behalf of the emotionally charged first user when auto-creating his CFi's might be: “mad about . . . ”, “sad about . . . ”, “angry with . . . ”, “disappointed with . . . ”, “hurt by . . . ” and so on. These auto inserted, emotion expressing keywords can work to better connect the emotionally charged first user to other users who have or are feeling the same thing about the associated topic. A machine-implemented automated method in accordance with the above may comprise the steps of: (a) detecting biometrically or otherwise, emotionally charged activities by a user that exceed the user's normal level of emotional engagement with his or her local client machine and thus indicate exceptional frustration or other exceptional reaction to machine provided content; (b) in response to the detection of the exceptional emotionally charged activities, inviting the user to a moderated online exchange service that is configured to empathize with the user's exceptional reaction and draw out from the user details about the source of the user's exceptional emotionally charged activities, (c) using the details drawn out from the user by the moderated online exchange service (e.g., the frustrations vent absorbing module) automatically generating content focus identifying records (CFi's) that identify the drawn out details even though the same do not appear as out-of-chat content on the user's machine; and (d) in response to the generated content focus identifying records (CFi's) inviting the user to chat rooms or other online exchanges involving other users who are or were similarly exceptionally emotionally charged about a same or similar topic.
Aside from the system relying on collected biometric data to infer the user's routine and/or exceptional emotional states or other aspects of the user's state of mind, in one embodiment the system allows the user to explicitly indicate his positive or negative interest in, or disposition about a specific item (e.g., out-of-chat room content being focused on or in-chat room content that is being voted upon). In one embodiment, the user invokes a voting menu (e.g., 336) by right clicking while his mouse cursor 335 while it hovers over a specific piece of content, for example one of the search result items in area 330c. The local machine then responsively unfurls a menu such as 336 which indicates some of the possibilities for explicitly indicating interest or voting upon pointed to content or otherwise venting frustrations. The displayed options in exemplary pop out menu 336 allow the user to explicitly vote positively (+Vote) or negatively (−Vote) relating to the pointed to content. The displayed options in exemplary pop out menu 336 allow the user to explicitly indicate positive (+Interest) or negative interest (−Interest) in corresponding content. In one embodiment, the voting options (±Vote) are grayed out if the cursor is not inside a chat room window. Additionally, the displayed options in exemplary pop out menu 336 allow the user to toggle the interest monitoring alert flag 312 on or off for a desired length of time. Although not shown, in one embodiment the right click options menu (e.g., 336) allows the user to explicitly indicate a mood shift with regard to what is being displayed. While the illustrated pop out menu 336 provides some examples, in other embodiments the user may be provided with yet a longer or different range of options of things that may be explicitly communicated to the remote on-line matching service, including pop out submenus for explicitly indicating change of interest, change of vote, change of mood, intensity of interest or of vote, a desire to browse the hierarchy tree (e.g.,
Referring to
A second research recommendation bar 352 is shown under the plural chat opportunities bubble 315c′ where here, the user has mouse clicked on or otherwise activated that second research recommendation bar 352 and the local machine has responsively popped open a corresponding matrix menu 355. The opened matrix menu 355 of this embodiment provides further research recommendations in the form of direct or indirect hyperlinks denoted as Link_11 through Link(s)_43 where these research recommendations are for the topic covered by the chat opportunities of invitation bubble 315c′. In this particular embodiment, three chat opportunities or separate invitations are provided in bubble 315c′, namely, a first invitation C3a deemed appropriate for a user having “Beginner” status or level of sophistication in the relevant topic C; a second invitation C3b deemed appropriate for a user having “Novice” status (more sophisticated than a mere beginner); and a third invitation C3c deemed appropriate for a user having “Advanced” status (more sophisticated than a novice). The denominations as “beginner”, “novice” and “advanced” are merely illustrative. A variety of different denominations and different numbers of them could have been used instead based on the topic being covered. For example, if the topic had been a political one, the listed denominations might have said: “for-the-proposition”, “against-the-proposition”, and “undecided”, where again these are merely examples.
The popped opened matrix menu 355 of this embodiment similarly provides rows with different levels such as the “beginner”, “novice” and “advanced” levels shown in column 355c. A user may click on the up/down arrowheads of column 355c to thereby respectively scroll the displayed matrix section up or down and see more options if available. Heading row 355a segregates the displayed research recommendations into types of resources, for example where the first offered column links to “blogs” on the topic C covered by bubble 315c′, where the second offered column links to “news” websites that report on the topic C, where the third offered column links to “white papers” written about the topic C, and where the fourth offered column may provide further links to same or different other categories of content sources whose content is directed to the topic C covered by bubble 315c′. In one embodiment, each interior box of the matrix (e.g., that containing Link_11) provides a single hypertext link directly to the on-topic material. In another embodiment, each interior box of the matrix provides a single hypertext link to a web page that has further links corresponding to the row 355c and column 355a descriptors of the matrix 355. In the same or yet another embodiment, each interior box (e.g., box 355b that containing Link(s)_43) of the matrix may provides plural hypertext links of the direct or indirect kind. A user may click on the left/right arrowheads of header row 355a to thereby respectively scroll the displayed matrix section left or right and see more columns as options if available.
In the illustrated embodiment, the user has clicked on Link_33 and as a consequence, a new web page frame or window 357 automatically popped open in her screen area 300′. Before clicking bar 352 and then utilizing the offered further research recommendation of Link_33 (a link to corresponding URL33), the user had only a first web article 317′ concerning associated topic C′ (which topic for example might relate to some thesis the user is developing about say, the historical implication of the French Revolution—as seen in the user's opened file window 320′). The first web article 317′ provided a first keyword (keywd1) that was helpful for researching the topic and developing the thesis. However, after activating Link_33, the user is automatically introduced to a better web article 357 on the topic located at URL33 where the introduced web article 357 is better for any of a number of reasons, including for example that it provides additional useful keywords, keywd2 and keywd3 which the user had not run across before or the new article is more in line with the user's thesis 320b′, the new article has a better, more on-topic graphic D embedded in it, etc. The user may now use the additional keywords, keywd2 and keywd3 to conduct yet further searches in line with his thesis 320b′. Without the help of the automatically suggested further research recommendations 355, the user may have been stuck and not making rapid progress developing his thesis 320b′. By accepting the automatically generated offer for the suggestions (by clicking bar 352) and by selecting a suggestion in-line with her needs (e.g., advance white paper) the user has now moved to a new level of collected knowledge for his chosen thesis.
It is to be noted in the hypothetical example of
Of course it is not by magic but rather by deliberate execution of background machine-implemented automated processes that all this occurred. Referring to
For now it is sufficient to understand that, just as Sally's on-screen activities caused a first DLUX 362 associated with Sally 121″ to point 363 to topic node 450′; there are other users of the system (bottom left corner of
Referring back to
In terms of a more specific example, let it be assumed that the user's not-currently-displayed calendar 359 shows that on Monday of this week, the user plans to be at (or has a good probability of being at) the Moscone Convention Center in San Francisco for a 9:00 AM event concerning topic A. When the time period for the event approaches (say at around 8:00 AM on that Monday), his client machine begins to automatically generate CFi upload data indicating increasing focus by the user upon topic A and the event at Moscone Center, and perhaps also with the CFi uploaded data providing some keywords or other subtopic hints extracted form a “Details” section of the calendared event record (e.g., a database record). Other CFi data generated by the user's machine, such a GPS current location, may verify that the user is indeed near the location of the Moscone Convention Center as the time for the event (e.g., 9:00 AM) approaches. Similar CFi data will be automatically generated from, or on behalf of the client machines of other system users who are also planning to be at the same event and/or at the same venue. As a result, chat room invitations may be automatically sent out to those of the event attendees who have sameness or substantial similarity of implied topic(s) of focus and/or chat co-compatibility. In one variation, the uploaded CFi data of the user of the illustrated machine (300′ of
The portable client machine (e.g., 3G-cellphone, PDA, etc.) of many a user will include a GPS (Global Positioning Satellite) or other automated self-locating subsystem. And as mentioned elsewhere herein, detailed location information about the client machine's current location can be at least periodically uploaded to the match-making and invitations-generating system (MM-IGS) alone or in combination with other CFi data. Thus the MM-IGS can (if given permission by the user to do so) keep track of the current locations of all online system users who have their BlackBerry™ or other PDA turned on with the GPS or other automated self-locating subsystem active. Additionally, in the pressing matters files of many a system user there can be a contacts set of database records that identify one or more persons whom the user wants to personally meet with regarding a pressing matter, for example one involving topic A. The not-currently-displayed contacts roller 358 shown in phantom in
In one example, it just so happens that Sam is at the Moscone Convention Center at the same time that machine user Sally (121″) is at that venue and opportunistically they both have a same open time slot to meet in person and discuss topic A. However, the Convention Center is so big and so crowded that neither spots the other. The MM-IGS service though, also knows they are both there at the same time from the GPS or other self-locating information provided in their uploaded CFi data and it also knows that the in-person meeting re topic A is a pressing current focus matter on both their minds because each has allowed their automatically generated CFi upload data to include high priority pressing contact items (e.g., that of roller 358) even though the user is currently not looking at that content. In response to its automated detection that Sam and Sally are in short-travel time proximity of each other and at least one, if not both users, urgently want to set up the in-person meeting regarding topic A, the MM-IGS automatically generates a meeting proposal (similarly to the way that chat room invitations are generated) and sends the meeting proposal to both with an invitation to a private chat room where they can iron out details of the meeting (e.g., exactly where and when). Thus it is seen that automatically uploaded CFi data can be useful for producing not only online meetings in chat rooms and the like (by way of invitations), but also for producing in-person meetings even if the system users do not at the moment have it in their mind that they can meet at the time. Of course, in one embodiment, current user mood is factored into such automated proposal of opportunistic meetings. One of the users may have indicated directly or inferentially that they are currently not in a good mood, and if so, the system may include knowledge-base rules that define when the opportunistic meetings should not be proposed due to a bad mood by at least one user and/or when the opportunistic meeting should be proposed (due to extreme urgency) despite the bad mood of one of the users. Also, although not shown in item 358 of
Sometimes users who are at a meeting, show, etc., will turn off or put away their cellphone, PDA or other CFi uploading device and forget to turn it on or pull it out, perhaps for a number of hours. That means that their last uploaded CFi data will become relatively old and the MM-IGS system may wrongly interpret the event (cessation of CFi uploads) as indicating that they have lost interest in certain topics (due to decay of exhibited interest) when this is not at all the case. Accordingly, in at least one embodiment, one of each user's profiles (typically the CpCCp) includes a last known state and interests record (not shown) that records the last set of content items and intensity of focus on them that were detected for the given user when the device was turned off (or apparently put away in a purse, jacket pocket, or other darkened enclosure). When the user turns his or her device back on (or pulls it back out into the light as detected by an integrated background light detector), the data in the last known state and interests record is treated as if it had just been uploaded into the cloud. In other words, upon boot up of a user's primary client machine (or pull out back into the light), the system assumes that the user is in the same state as they last were even if the user does not immediately begin looking at content that is on a same or similar topic as that which was last looked at. For example, the user may first look at the most recent news stories even though the user has not lost interest in the on-mind topic that was last on his or her mind when they shut off the machine or put it away.
Referring now to
Services provided within the data centers may include the following: an Access (client access) and Accessible-Resources Monitoring Service (AARMS) 411, a User Accounts-management Service (UAS) 412, a Domains/Topics Lookup Service (DLUX) 415, a plurality of Domain-specific Matching-making Services (DsMS) 416, and a Chat Rooms management Service (CRS) 418. The servers (virtual or actual) which provide these services and the corresponding software modules that provide these services may be coupled via a secured data center internal backbone 417 to a variety of center-accessible data stores, including a Global Services Directory Store 431, a User Accounts Data Store 432, a Domain/Topics hierarchy configuration store 435 and a historical Trending data store 437. The services providing modules 411-418 and data stores 431-437 (e.g., hard disk storage banks) couple to an unsecured network (e.g., internet) 430 via a protective firewall 419a and through one or more data routers 419b (collectively shown as 419). A trusted (non-open) high speed dedicated network or virtual private network (VPN) 439 interconnects the backbone 417 of a first of the data centers 410 to that 417′ of a next data center 420 and so on so that resources can be shared and reallocated among data centers depending on resource availability and user demands.
Referring first to the Domains/Topics Lookup Service (DLUX) 415, it is to be understood that a large number of topic domains and topics and subtopics may be defined either by system operators or by the services using public (clients 440). The topic domains, topics, subtopics and so forth are represented by topic-representing data objects or node objects stored in system memory (e.g., 435). Chat rooms may be pre-assigned or dynamically re-assigned (migrated) to specific domains and/or topics, subtopics, etc. or newly created to serve such topic areas depending on user population interest in the respective topics. A same chat room may be pointed to by different topic nodes if the chat room is currently providing transactions related to the topics of the plural topic nodes. See briefly the pointers 469 to corresponding chat rooms (CR's) 469a-469N in hierarchy tree 401 of
In one embodiment, each of the distributed data centers 410, 420, etc. in system 400 of
In one embodiment, system servers scan the catch-all Domain and catch-all topic bins (not specifically shown) in the data centers (410, 420, etc.) and when the servers detect that there is sufficient chat activity related to a set of CFi identifiers (sufficient topic clustering) where the set of CFi identifiers are not already assigned their own Domain and/or Topic identification numbers, the system servers automatically create such new specific domains, topics, etc. and assign unused navigation meta-tag numbers and/or topic space coordinates to them and publish the results to the relevant users via the domains configuration stores 435 in the respective data centers and/or via email advisement messages. The user community will be allowed to collaboratively name Domains and/or topics and assign them to branch and sub-branch (child node) locations in the tree-like Domain hierarchy. In one embodiment, only users subscribed a sufficiently high premium level of service will be allowed to participate in domain/topic naming and node placement within the hierarchy. In an alternate embodiment, participation in domain naming and placement activities will be electable by the user. Some users won't want to be bothered. Others may take pride in being involved in process. Any set of CFi hint values seen often enough to warrant automatic creation of their own Domains will probably be popular enough to have some percentage of the user community interested in the naming and categorization process.
Aside from optional user participation in domain/topic node naming and categorizing (node placement in the hierarchy tree and/or node positioning in topic space), system administrators may: review and revise Domain names and/or their categorizations; and specify that a dynamically created Domain should be included in the nonpremium list of published Domain names which every user can explicitly specify in his or her DsCCp profiles. As catch-all chat rooms are created and users in them gravitate or cluster their interchanges toward specific topics, the chat rooms may be automatically re-associated with a specific Domain ID and/or topic ID based on matching CFi values of new users who are invited into and join those catch-all rooms.
Aside from traditional domain names such as News, Sports, Weather, Traffic, etc., it is within the contemplation of the disclosure to have special activity domain names. A first example is a domain node named: “What is recommended as an activity IF My Current Location is:”. Under this there will be topic nodes including those bearing the names of major geographical areas or population centers such as, for example, “New York City”, “London”, “Paris”, “California”, etc. Under each of these (or over each of these) there will be sub-topic (or super-topic nodes) including those bearing the identities of different time ranges, such as for example: “And IF My Current Time is Weekday Morning”, “And IF My Current Time is Weekend Lunch”, And IF My Current Time is National Holiday”, etc. Under each of these (or over each of these) there will be sub-topic (or super-topic nodes) including those bearing the identities of different situational conditions such as for example: “And IF My Surrounding Weather Condition is Very Hot”, “And IF My Surrounding Weather Condition is Raining”, etc. Under each of these will be subsidiary activity nodes bearing the identities of different activities such as for example: “Restaurants to Eat at”, “Shows to see”, “Movies to see”, “Museums to visit”, “Sight Seeing Tours to take”, “Nature Hikes to take”, etc. Since in one embodiment, each users portable client machine (e.g., cell phone) is periodically uploading the user's GPS location to the match-making system and the time of day, the system can automatically make activity recommendations given that the system also has a copy of the user's current personhood profile (CpCCp) and the latter provides demographic information about the user as well as various likes and dislikes (e.g., favorites insert 154-7a of
As yet another example special activity domain names, it is within the contemplation of the disclosure to have a domain node named: “What is recommended as an inter-organization activity IF an Organization I Currently Belong to is:”. Under this there will be topic nodes including those bearing the names of major corporations, college fraternities, honor societies, political parties, etc. Under each of these (or over each of these) there will be sub-topic (or super-topic nodes) including those bearing the identities of different time ranges, such as for example: “And IF My Current Time is Weekday Morning”, “And IF My Current Time is Weekend Lunch”, And IF My Current Time is National Holiday”, etc. Under each of these (or over each of these) there will be sub-topic (or super-topic nodes) including those bearing the identities of different situational conditions such as for example: “And IF My Surrounding Weather Condition is Very Hot”, “And IF My Surrounding Weather Condition is Raining”, etc. Under each of these will be subsidiary activity nodes bearing the identities of different inter-organization activities such as for example: “Meetings to Attend”, “Open Collaboration Projects to Join” and so forth. Since in one embodiment, each user's CpCCp includes a listing of organizations he or she currently belongs to and since the user's portable client machine (e.g., cell phone) is periodically uploading the user's GPS location to the match-making system and the time of day, the system can automatically make activity recommendations given that the system also has a copy of the user's current personhood profile (CpCCp) and the latter provides demographic information about the user as well as various likes and dislikes (e.g., favorites insert 154-7a of
As yet another example special activity domain names, it is within the contemplation of the disclosure to have a hybrid domain node named for example: “What is recommended as an inter-organization activity AND for my current location where the organization/-location pair is as follows: (e.g., Society of Internal Medicine Physicians and Nebraska)”. One of the activities might be to discuss a current observation of new symptoms among patients (e.g., salmonella poisoning) in a given geographic region. It is within the contemplation of the disclosure to limit invitation into certain chat rooms only to individuals who are licensed in a particular art (e.g., medicine, law) and/or are credentialed in a specified specialty (e.g., infectious diseases) and/or are practicing in a specified geographic region (e.g., Nebraska). This type of nodal categorization allows specialist to spot unusual developments germane to their location and their specialty. In one embodiment, the users may explicitly specify that they want invitations limited to this type of nodal categorization or their CpCCp and/or DsCCp may specify a preference for this type of nodal categorization.
In one embodiment, certain domain nodes are expected to be more permanent fixtures of the hierarchy tree than others, and as such, these more persistent domain nodes are assigned smaller coordinate angles in polar topic space than domain nodes that are expected to be less persistent and more volatile in nature (e.g., fad domains that come and go). Among the certain domain nodes are expected to be more permanent fixtures are: (1) Those dealing with personal health issues, including those having chat rooms dedicated to specific health maintenance topics and/or disease treatment and/or management issues. Topics under the Health domain node may include those where each chat room is always staffed by or periodically visited by a credentialed health care provider (e.g., a licensed doctor or nurse). Further among the certain domain nodes that are expected to be more permanent fixtures are: (2) Those dealing with children, including those having chat rooms dedicated to specific educational needs of children and/or specific behavioral control issues associated with caring for and raising children. Topics under the Children domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed educator or child psychology expert. Further among the certain domain nodes that are expected to be more permanent fixtures are: (3) Those dealing with jobs and career choices. Topics under the Jobs/Career domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed career advisor. Further among the certain domain nodes that are expected to be more permanent fixtures are: (4) Those dealing with domestic pets (e.g., care and training of dogs, cats, etc.) wherein topics under the Pets domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed animal care expert; (5) Those dealing with vacationing and traveling wherein topics under the Travel domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed travel and vacationing consultant; (6) Those dealing with business issues (e.g., investment recommendations, company management etc.) wherein topics under the Business domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed business consultant; (7) Those dealing with information research issues (e.g., best search strategies) wherein topics under the Research domain node may include those where each chat room is always or staffed by or periodically visited by a credentialed research consultant; and (8) Those dealing with current events in general and having current event discussion rooms dedicated to specific newspaper publications. Further among the certain domain nodes that are expected to be more permanent fixtures are: (9) Those dealing with product and shopping advice (e.g., what is/are best computers, cars, etc. to buy in given price range and/or what is/are best stores, vendors, dealerships to use for obtaining desired products and/or services); and (10) Those dealing with sports (e.g., and having topic nodes dedicated to discussing favorite teams, favorite players, favorite games etc.)
As mentioned above, chat rooms operating under the root catch-all node or under the catch-all node of a domain typically have a specific topic assigned to them. However, over time, participants in the catch-all room may begin to cluster around a specific topic.
An example of how this might come to be, may be helpful. Suppose a new and previously unknown celebrity pops into the public consciousness. Let's call him, Harry the Hairdresser (fictitious name here). He became famous overnight because a politician mentioned him and/or because he won a popular talent show (e.g., American Idol™) or for whatever reason. Suddenly everyone is talking about Harry the Hairdresser, about how well he sings or dances, about a new hair style he just introduced, about how he affects an ongoing political debate, etc. Yesterday, there were no nodes in the system hierarchy tree regarding the topic of Harry the Hairdresser. Today, the catch-all domain node is swamped with new chat rooms, all talking about Harry the Hairdresser. It behooves the system to move at least the more populated and more active ones of these rooms whose topic of discussion clusters around Harry the Hairdresser to specific domains and/or topic or subtopic nodes or to create new nodes (with node ID tags) for these rooms so as to better serve the growing numbers of users logging in to talk about Harry the Hairdresser. While the overnight sensationalism of Harry the Hairdresser may be one example, there could be other catch-all discussions about esoteric topics where the popularity of the topic slowly grows, first perhaps at a creepingly increasing slow rate but then approaching an exponential rate. This too should be automatically identified and dealt with before it becomes a bigger problem (e.g., in that it swamps the catch-all domain node and services that focus on serving that node).
Just as Harry the Hairdresser (fictitious name) may explode into notoriety overnight, he may also disappear into obscurity just a as rapidly or ebb away slowly over time. At some point after his rise and peak, the system may become filled with unused nodes (no active chat rooms for a long time under those nodes) or redundant lightly populated nodes (some chat rooms, but hardly used and having substantially similar attributes) dedicated to the Harry the Hairdresser topic. In order to avoid waste of system resources (e.g., storage, etc.) on topics that are no longer as popular as they once may have been, the system may include background garbage collecting or compressing service modules that crawl through the data centers at off hours, locate long unused nodes (or unused chat rooms under those nodes) and delete them and/or locate lightly populated nodes or chat rooms (e.g., those whose usage in terms of number of participants, intensity of participation, etc. are below system defined thresholds) and try to merge the same with other topic-interrelated nodes and/or rooms that are also lightly populated. In one embodiment, a history is kept of each node at least by its unique node ID tag (see 450a of
Step 442 looks at the not-yet migrated room (e.g., catch-all room) with the highest score on the list due to summed and optionally weighted scoring factors such as recent or long term topic clustering within the room, number of participants in the room, level of user activity in the room, intensity of user engagement with the room and trending history of growth for these or other factors. Step 443 tests for whether the score is above a predetermined threshold such that migration is warranted. The higher scoring rooms in the sorted list that was formed by step 441 may warrant migration ahead of lower scoring rooms. A point of diminishing returns may be reached where the system determines it is not worthwhile to move the next room on the sorted list to another place on the hierarchy tree (or to another location in the topic space of
If the result of test 443 is a Yes, then control is passed to step 443Y. In one embodiment, the room is marked as “warrants migration” and a separate migration handling thread picks up the task while the “For each” loop of step 442 process the next room on its sorted list. In step 443Y, the process of attempting to migrate the given room to another place in the hierarchy tree or to create a new domain and/or new non-catch-all topic nodes for it is begun. Because the room has a fairly large user population, the room will have inherited its own averaged CpCCp and/or averaged DsCCp from the profiles of its individual users. In step 444, the room's averaged profile(s) is/are submitted to a Lookup service (e.g., a DLUX module) so that the DLUX can automatically generate a proposed location in topic space (e.g., 600) based on those averaged profiles). Alternatively or additionally, the trended topic clustering within the room is used to automatically generate one or more proposals of where the room should be migrated to next. The trended topic clustering data may show a location in topic space where the room has historically concentrated and a location in topic space where the room's recent activity is trending towards. If the room's averaged topic clustering data and/or averaged CpCCp and/or averaged DsCCp closely correlate with one or more pre-existing and non-catch-all nodes already in the system hierarchy tree, then the Lookup service(s) will find those nodes in step 444 and sort them according to which found node is probably the best match for the room's inhabitants: These found nodes will constitute automatically generated destination proposals which the room's inhabitants can vote on. In one embodiment, users within a relatively large catch-all room are automatically clustered (see
Step 445 tests to see if the automated look up process looking for destination nodes to propose was successful. If No, because there is no pre-existing node in the system hierarchy tree that already closely matches with the room's topic, control passes to step 445N and a new domain and/or new topic name plus its specification (different from those pre-existing in the system hierarchy tree) are automatically proposed based on data found in the room's profile(s) and/or the more dominant terms found in the room's recent transcript. For example, if the room profiles are very wide in scope and everyone in the room is talking about “HH” (where the system searches back to learn that HH is shorthand for Harry the Hairdresser, and the pre-existing nodes in the system hierarchy tree do not include ones directed to HH; then the automatically generated proposal may be one for creating a new domain named “Harry the Hairdresser”. Later, rooms under this new domain will break off into separate topic and sub-topic nodes as groups break off to discuss different aspects of the HH phenomenon and the tree structure further evolves.
On the other hand, if the look up in step 444 produced one or more finds, then step 445 passes control to step 445Y (Yes) and the found nodes are posted as proposed and to-be-voted-on locations to migrate the current room to, with the highest scored find being listed first. In one embodiment, the proposal that is generated by step 445N (No) is appended to the bottom of the list produced by step 445Y so that users of the to-be-migrated room have the 445(N) result as another option to vote on.
In step 446, the automatically generated migration proposals of steps 445Y and/or 445N are submitted to the room's eligible voters or legislators to vote on and optionally debate over before casting final votes. In one embodiment, step 446a allows eligible ones of the room's users to debate, propose amendments, propose new migration targets, etc. The eligible users may be a predetermined subset of the room's user community or all of the then active members. The room may have preexisting quorum requirements. (If the quorum requirement is not met within a predetermined time, the thread jumps to step 447N.) after a predetermined debating time (if any) elapses, control passes to step 446b where the migration proposals are finalized and put out for vote according to the room's predefined voting procedure (e.g., majority wins, revote on the top three, etc.). In one embodiment, the to-be voted on destination locations are displayed to eligible-to-vote users in a topic space format such as the polar coordinates one of
Test step 447 determines whether any proposal won and if so whether with a sufficient number of votes to justify migration. If No, next step 447N determines if there are any further room's on the list generated by step 442, and if Yes, it passes control to step 443 for processing the next room on the sorted list. If No, control is passed to step 443N (described above).
If test step 447 results in a Yes, control passes to step 447Y wherein the current room is migrated to a new node in accordance with the winning proposal. If the proposal was to simply move the room to a pre-existing non-catch-all node in the hierarchy tree, then this is done and information regarding the move is broadcast at least to the data center DLUX modules and also recorded in the data center GSDS (e.g., 431 of
After the given catch-all chat room has been migrated to a newly-created domain or to a newly-created node or to a pre-existing node by step 447Y, control over the room migrating system resources is passed to step 448. Here, a system resources scheduler determines how much bandwidth is available for continuing to perform room migration operations. If resources are currently in short supply (tight), then the scheduler of step 448 may decide to restrict the background rooms migrator to moving catch-all rooms only out of the catch-all domain of the system's hierarchy tree to some other domain and/or a topic node immediately under the domain node but not to a more refined position in the hierarchy tree. Refinement can take place at a later time when more resources are available. In that case control is next transferred to entry point 441a. Step 441 is repeated with the node pointer pointing at the root node.
On the other hand, if bandwidth constraints are mild (medium), the system resources scheduler of step 448 may decide to instead next pass control to step 443N. Under this pathway, one or more catch-all rooms of a pre-existing named domain node will be processed. On the other hand, if bandwidth constraints are substantially nonexistent (large, wide open), the system resources scheduler of step 448 may decide to instead next pass control to step 449. Under this pathway, the node pointer crawls through deeper, lower level nodes of the hierarchy tree below the level of the root's catch-all domain or the catch-all rooms of the highest level named domains. Once the pointer of step 449 is set to point to a lower level node (assigned on round robin or other fair distribution basis), control is passed to entry path 441b and from there into step 441. It is to be noted here that, in one embodiment, catch-all rooms come in different flavors. A catch-all room is one where the room's predominant domain and/or topic are not yet resolved and the room's participants are jumping around many topics without yet having settled their focus on one room-defining topic. However, just because the room's basic topic has not yet been defined, that does not mean that participants in the room necessarily are focused upon entirely different content items. They could be focused upon same or similar content items (e.g., a same URL) and yet be associating different topics in their minds to the same or similar content. By contrast, there can be other catch-all rooms where the participants are not focused upon any content at all or are focused upon substantially dissimilar items of content (e.g., unrelated URL's) and these participants have gotten together in a chat room simply because they like to talk to each other about nothing in particular. More specifically, the match-making system has clustered them into a no-common-focus room simply because their personality co-compatibilities are very strong (e.g., scored above a system predefined threshold). At some later point in time, users in any of these different kinds of chat rooms can vote to define a predominant domain and/or topic for their room and to migrate the room to another node in the data center's hierarchy tree or they can abandon the room and leave it to the system garbage collection services to automatically dissolve the room (and perhaps a temporary node under which it was sponsored). So to summarize, catch-all rooms may be ones whose users are focused upon a same item of content (e.g., same URL) or focused upon substantially similar items of content (e.g., different news reporting sites but directed to same news story) or not focused upon any interrelated content at all. The system may automatically identify these different kinds of catch-all rooms and maintain respective different vote and migration managing rules for managing votes and migration proposals made in the respective the different kinds of catch-all rooms.
Even after a catch-all chat room has been initially named and placed at a non-catch-all node, it's position in the hierarchy tree and/or its characteristics may not remain static and the same. Rooms have a tendency to evolve. As mentioned, users may enter and leave at various time points and by doing so change the averaged attributes of the room, particularly if it is a lightly populated room. While users are participating in a given chat room and voting, the system may automatically put up for a vote by the chat room participants, the Domain and topic names which the users think best describes the current chat. If a sufficiently large vote is received (in accordance with system defined rules for vote taking in that room), the system will reassign the room to the new Domain and topic, for example by a machine-implemented automated process such as that of step 443Y to step 447Y of
The categorization location within a data center hierarchy tree (e.g., 401 of
In one embodiment, users who are displeased with having been invited into the DomainA/TopicB room of the above example and who do not see an alternate acceptable room being automatically published as an in-box invitation (316c of
Referring to the specifics of
Topic nodes and node-to-node interconnect branches in the hierarchical organizing system 401 of
The on-topic information resources (e.g., those pointed to by pointers 459, 459X of node 450) of each given topic node (e.g., 450) are not necessarily fixedly bound to the given topic node and are not necessarily dedicated to the topic node on a one-for-one basis. A chat room may migrate from one topic node to another as the topic currently discussed in the room changes. A chat room (e.g., 469a of node 460) may have more than one topic node pointing to it at the same time, for example because two topics are being simultaneously discussed in the room. (See for example, pointer 499 to room 469a which pointer comes from another node beyond node 460.) Migration of a chat room from one node to the next may occur as a Tarzan™-like swinging from one tree vine to the next with room first logically linking to a new next node before releasing linkage to an older but now less on-topic node (in so far as the room is concerned). Just as chat rooms are not necessarily unique to the topic being discussed in them (in other words, there can be multiple rooms per topic) and rooms can migrate about the hierarchy tree and/or in topic space, the same is roughly true of topic nodes. No one topic node necessarily has a monopoly on a corresponding topic because the respective topics of nodes can drift and two or more nodes may drift from spaced apart positions towards a same spot in topic space. The topic of a node is primarily governed by the topic being focused upon in the majority, mean or median of the node's chat rooms (or other alike real time forums). So if the mainstream discussions in the node's rooms drift toward a deviated topic without the mainstream rooms themselves migrating away, then the node as a whole should migrate to a new spot in topic space and optionally to a new spot in the system hierarchy tree. Stated otherwise, a given topic node (e.g., 460) is not necessarily fixedly bound to a specific position in the hierarchy tree 401 and may migrate to a new position in the hierarchy tree (e.g., under a different parent node and/or over different children) and/or may fuse with one or more other drifting nodes and/or may split apart into two diverging nodes, where such changes in hierarchy tree position may be voted for by eligible voters in the system or such changes in hierarchy tree relationships may be made by system administrators and/or such changes in hierarchy tree position may be performed automatically as an automated trending analysis service realizes that the node's cumulative attributes (as determined by modules 380, 390 of
When a given topic node migrates to a new position in its hierarchy tree, or fuses with another node, or bifurcates into two spaced apart nodes, the on-topic information resources to which that moved node or node part currently links may be viewed as inherently moving with that node to the new position in the hierarchy tree (and/or to the new position in topic space). In one embodiment, all current participants in each room that moved because its node moved are briefly informed that their room has shuttled or warped to a new position in tree space or in topic space. After the node move and/or node bifurcation, some or all of the chat rooms or other resources logically linked to that moved node or node part may migrate away on their own or decay away from the moved node. When the latter happens, in one embodiment, all current participants in each room that moved are briefly informed that their room has shuttled or warped to a new position in tree space or in topic space. Thus from the point of view of users inside a room, there is no apparent difference between their room shuttling to a different node or the node itself migrating to a new place. By way of analogy, each chat room may be viewed as a kind of space ship that orbits its current node planet (or moon) where the space ship can shuttle off on its own to a new position in tree space or topic space or the planet (or moon) about which it orbits can change location. In one embodiment, when rooms are displayed as graphic on-screen icons, they are displayed as space ships orbiting a topic node planet (or moon) so as to give users a graphical sense of where they are in topic space, where nearby space ships are, where nearby planets or moons are, and so forth. (In this rooms-as-space-ships metaphoric world, the central star in the current solar system represents the catch-all domain of a given topic space and space ships can warp over to other solar systems to thereby place themselves in alternate topic spaces.) It is to be observed that just as space ships are not permanent fixtures of the planet they orbit, pointed-to on-topic information resources such as chat rooms (459) and on-topic reference materials (459X) are generally not part of the hierarchy tree node to which they current link. Rather the logical linkage is a temporary gravitational kind and the pointed-to on-topic information resources may be simultaneously pointed-to by multiple nodes and/or may drift in topic space (or tree space) so as to be seen as being under the gravitational influence of different nodes at different times. While knowledge of where in topic space (or tree space) one's current chat room is, may not seem to be of importance to all room users, it may be so to those who wish to take advantage of non-auto-pilot browsing through nearby space and to see and explore manually on their own what is happening inside a nearby other spaceship (a.k.a. a nearby other room; if let in upon requesting) or what is happening in nearby orbits of the current planetary node, and so forth.
Because the on-topic information resources (e.g., chat rooms, like 469a-469N of node 460) are logically linked to, by way of the topic nodes (e.g., 460) of the hierarchy tree, the topic nodes may be viewed not only as orbit-supporting planets but also as airport terminals (or more accurately, spaceport terminals) or as pass-through portals through which users of the system pass (or gravitationally touch upon) when the users are on their way to accessing the on-topic information resources (e.g., inside the chat rooms). The topic nodes may also be viewed as clustering centers around which plural users gravitationally cluster as they access the on-topic information resources that are currently of interest to them and happen to be orbiting around that specific node. In actuality, users themselves do not, of course, pass-through such portals or cluster around them. Rather the resource accessing processes (e.g., topic lookup computer programs) that provide the respective users with access to the on-topic information resources (e.g., to the chat rooms; or offer invitations to the rooms) interact with the topic node data objects (directly or indirectly) in such a way that the interaction can be analogized to having some users passing through, temporarily orbiting around, or clustering around the nodes. One of the interactions that warrant such analogy can be that of bringing personal baggage to the corresponding spaceport (to the specific topic node object). When this happens, spaceport authorities (actually modules servicing the node, such as 380, 390 discussed below) can insist on taking a sampling of the relatively current CFi data that was brought along or used by the user to get the user to that topic node because it was determined (e.g., because a DLUX, e.g., 362 of
Aside from having a hierarchical position in the hierarchy tree 401, one or more of the topic nodes (but not necessarily all) can have data-defined positions in a prespecified topic space 600 such as, for example, sub-topic node ST1.45 (
Still referring to
When uploaded CFi's are received from different client machines and the domain/topic lookup process (DLUX) determines that these CFi's hint at a given topic node such as 450, the system looks for those of the corresponding CFi's that include URLs as their topic hints. Statistical analysis of incoming CFi's may indicate that some URL hints (or other content address identifiers) are currently more popular or common than others for pointing to a given domain node (e.g., 450). Other analysis of incoming CFi's may indicate that credentialed experts in the current topic of the given topic node favor a particular subset of URL's when apparently having the topic of the given topic node currently on their minds. In one embodiment, these more commonly seen URL hints are stored in logically attached, URL hints record 454. The expert-preferred URL's may be similarly copied into another hints record (not shown) like 454. These more commonly seen URL hints (or other address hints) and/or the expert preferred URL hints (or other address hints) may be automatically copied into template DsCCp records and/or into user's DsCCp rules set (see 195 of
While examples given herein have mostly focused on users who are to meet online, it is also within the contemplation of the disclosure to have users meet in person with the aid of the match-making system. Consider a first user who happens to be at a large business convention; say MacWorld™ in San Francisco where hundreds of Apple Macintosh™ devotees meet annually. Let's say that professionally, this first user is an expert in Java scripting algorithms as used on the Macintosh™. However, at the current moment he is not interested in talking more about Macintosh™ Java scripting. He is all talked out about that topic. His uploaded CFi's of the last two hours show that he is currently interested in talking about vacationing in the Bahamas; and more specifically, which hotels there are best. Unbeknownst to the first user, there is a second user also attending the MacWorld™ convention. The fact that both users are concurrently at MacWorld™ is indicated by their recently uploaded CFi data, both showing GPS determined positionings in the Moscone Convention Center in San Francisco. The second user's recently uploaded CFi's of the last few hours show that he too is current interested in the topic of good hotels in the Bahamas. In one embodiment, the system invites the first and second users to a chat room whose current topics of interest are the MacWorld™ convention and hotels in the Bahamas; with emphasis (more weighting) being placed on the latter. In one embodiment, the system also automatically mentions in the invitation that the other user happens to be physically at the MacWorld™ convention and appears to be co-compatible chat wise (and more particularly for in person chats) with the invited user. The two users may then negotiate online to meet in person at the MacWorld™ convention; not for the purpose of talking about Macintosh™ Java scripting, but instead to talk about best vacation hotels in the Bahamas. With their joint agreement, the system may then automatically flash the photograph of the other user, his CV or resume to the portable client machine of each user and use uploaded GPS data (from their cell phones) to indicate how far apart they are and in what direction. In this way, two relative strangers at a large business convention may be brought together to chat about a topic of current interest, even one having little to do with the business convention. If they form a strong friendship bond over the first topic (e.g., Bahamas), they may later move on to other topics of mutual interest. This was an example of how currently uploaded GPS positions in combination with hints about topic of current interest can be used to automatically bring together people who might not have otherwise gotten together despite having many topics of current interest in common.
With regard to invitations (e.g., the Cciv's 118c of
The recommendation information provided by each Cciv may include: (a) Summary data about the chat room or about non-chatroom material that can help the user decide whether to join the chat room at this time and/or open the associated non-chatroom material (e.g., the summary can provide the current name of the topic node, the name of the chat room, a description of the room topic, a summary about moderator or lead contributors, etc.); and (b) The data needed to enter that chat room (i.e. the identity of the CRS resource hosting that room, identity of the hierarchy location of the to-be-joined chat room (i.e., domain/topic/subtopic/etc.)), (c) An indication of whether it is a new room being now created, etc. and if so number of other users expected to join. The cloud may provide this or various other forms of recommending data as may be indicated to be desired by the user population. Automated means for adapting to the informational desires of the user population may be incorporated in the cloud as well as means for delivering the desired information for determining whether or not to join a chat room or other user-to-user real time exchange or to open the associated non-chatroom material (e.g., non real-time interchange such as blog, tweet, list serve, etc.).
When a DsMS takes on new chat rooms as being covered by, for example a new hierarchy node added under the hierarchy tree region managed by the DsMS, the DsMS performs an inventory collection run regarding its newly acquired node and underlying rooms by querying the responsible CRS's (418). This inventory collection run may include querying the CRS's handling the new rooms and obtaining from the CRS's answers to questions such as: (a) Current Status of the chat room, i.e., open and running or empty and not running; (b) List of open chat rooms under the management of the given CRS; (c) Counts of participating members in each of the running (active) chat rooms; (d) Details regarding the members in each chat room; and (e) Average number of transactions per second or other time unit for each of the active chat rooms under the management of the given CRS. The DsMS can use this collected information to manage and redistribute its workload as necessary. For example, if a newly acquired group of chat rooms is very busy and corresponding co-compatibility scoring and sorting for members of the newly acquired group of chat rooms will probably overload the DsMS, the DsMS can contact its supervising DLUX or AARMS and request reassignment of part of the chat rooms covered by the given DsMS to another DsMS. An example of when a DsMS may be forced to take on a newly acquired group of chat rooms is when those chat rooms are initially designated as catch-all rooms but then the system recategorizes them as belonging under a pre-existing or new topic node managed by the given DsMS.
Each domain node in the hierarchy, such as node 450 may have one or more child nodes logically attached thereto as indicated by the immediate child pointers shown at 457. This is mostly conceptual. In one embodiment, there is just one immediate child pointer at 457 pointing to an expandable linked list of pointers which then point to the child nodes. In this way, the number of child nodes can be more easily expanded or contracted as appropriate for current system conditions. In the same or another embodiment, each child node has a pointer (not shown) pointing back to its immediate parent node. This allows each parent node to have a highly variable number of immediate children.
Each of the child pointers (e.g., 457a) in
As seen in
When a match-making service invites a user into given first chat room, the invitation accepting user may discover that the room is not quite to his or her liking. The reasons can be many and varied. For example, the topic of interest in the system suggested room is not exactly what the invited user had in mind. Another possibility is that the personalities of the other users in the room are not quite to the invited user's liking. In one embodiment, an invited or accepting user can invoke a “browse the hierarchy tree” function from his local machine. In response, the match-making system sends back a display of folders and subfolders representing the nodes of the tree with the contents in the folders representing that node's chat rooms. (In one embodiment, some premium nodes may be hidden from nonpremium users.) The displayed hierarchy indicates where the current invitation points to and provides the user with the ability to manually browse (navigate among) the displayed nodes, either horizontally within a given parent folder or vertically up to a higher level parent folder or deeper down into a direct child folder. Additionally the user may navigate (with or without the aid of user-specified filtering constraints e.g., show me only rooms that have an average age above 35 years old) along the indirect connection paths offered by the distant relative pointers (e.g., 458 of
Referring momentarily back to
First of course, a just-turned on client machine should generally log-in into one of the data centers. This function is handled by the User Accounts-management Service (UAS) 412. In general The User Account service (UAS) facilitates and performs the tasks needed to create new user accounts, to save changed user profiles (e.g., CpCCp's, DsCCp's, rPEEP's in the local UAS data store 432) and to manage user passwords and other security measures (e.g., face recognition, voice recognition, etc.). Also, the UAS 412 may manage background synchronization of user records across plural data centers so that when a user account record is altered at one data center, the latest changes are automatically copied into other data centers when system bandwidth permits. In one embodiment, a background running updating service crawls through data centers during their light usage hours and updates old user records with newer ones that may have been created or modified in other data centers. The user's account related information is saved in one embodiment to a set of parallel storage devices (i.e. mirrored databases in different data centers) in order to facilitate fast data access during heavy usage traffic loads. Thus if a client machine tries to log into its primary home center but the local AARMS 411 flags that the center is not ready to accept this additional client, the AARMS 411 will automatically redirect the client machine to another data center which the AARMS 411 knows (from data in the local Directory store 431) has a mirror and/or most recently updated copy of the user's account information. The UAS (e.g., 412′) in that alternate data center processes the user's log-in activities and then mirror copies the latest account activity into the primary home center (into data store 432) when network bandwidths allow for such data mirroring.
Upon logging in through the UAS (412) of a given data center, the AARMS (411) of that center begins collecting CFi (118a) packets from the logged-in client machine. The local AARMS (411) determines what rate of CFi's is being generated by the added on client machine (and/or what volume of CFi contained data is being generated per unit of time) and whether the added on client machine is a premium service user or a user with lesser service rights. The local AARMS (411) then determines whether non-premium users should be redirected to other data centers or have their rate of CFi's servicings curtailed to accommodate the just added on client machine (e.g., 440a). Of course, this process repeats as further client machines (e.g., 440b, 440c, etc.) log in and send in their CFi's. so the AARMS (411) is constantly monitoring usage loads on the services within its own data center and within sister data centers to determine how resources should be allocated and reallocated as traffic conditions change.
Just because a given client machine has been accepted by a local AARMS (e.g., 411) for servicing of that client machine's CFi's (and Cvi's), that does not mean that the work load from the client machine will be handed off to the local DLUX (domain lookup service) 415. Each local AARMS has it within its discretion to channel parts of its traffic to remote DLUX's (e.g., 415′) rather than to the local one. The local and/or remote DLUX's have it within their discretion to channel parts of their respective traffic flows to DsMS's (e.g., 416′) that are remote to them. Accordingly, when a given client machine is accepted for servicing by the AARMS of a first data center, that does not mean that the DLUX (domain lookup service) in the same data center will necessarily provide the domain lookup functions for all or part of the CFi's originated from the given client machine. It also does not mean that one or more of the DsMS (match services) in the same data center will necessarily provide the corresponding chat room co-compatibility matching services. A given client machine that links for servicing by a first AARMS (e.g., 411) may find itself getting invited into chat rooms being managed by the CRS (418′) of a different data center. This will be particularly true if there are no co-compatible chat rooms in the data center of the first AARMS.
The CRS's (e.g., 418, 418′) in each of the data centers provide typical chat room support features found in conventional servers that host chat rooms, such as facilitating real time discussions among groups or individuals and flagging problems out to system administrators. Additionally, the CRS's of the match-making system facilitate user-to-room activities such as allowing users in the room to make recommendations and/or vote on the chat room name, the system-supported description of the room, the position in the domain hierarchy where the controlling node for this chat room will be disposed (node categorization), the cross linked related rooms to which this room will point, the cross linked related nodes to which the node of this room will point, and other such mutually agreed to and shared information concerning characteristics of the given room. In one embodiment, each CRS also receives and processes explicit or implicit votes regarding content within the rooms under its control, such as votes cast in the form of Cvi's. The CRS may control cleaving of the room into plural rooms so as to separate warring factions and/or such as to merge lightly populated and co-compatible rooms so as to attain a predefined critical mass of participants in one room for purpose of keeping the discussions going. Each CRS (e.g., 418) may maintain interoperative interfaces with the other services (e.g., 411-416) in its own data center or even in other data centers for the purpose of support client operations and carrying out workload balancing.
In one embodiment, chat content messages and other chat-related feature messages are passed through the CRS hosting the chat room when moving between the chat room and the clients in that chat room. The CRS can then control discourse between users, by for example, banning offensive language or reporting suspicious activities to proper authorities. The CRS can also thereby detect changes in the primary topics being discussed within the room. As chat room conditions change, the CRS sends notifications to the DsMS that currently owns the chat room. These notifications may include information about: (a) Users entering or leaving the chat room; (b) Names or descriptions assigned to the chat room by its current participants; (c) Changes in the average (or median, etc.) CpCCp and/or DsCCp attributes of the chat room (which may indicate that the character of the room is changing because a new user population is moving in and an earlier is departing); and other such chat room specific information. If the character of a given room changes sufficiently, the supervising DsMS may responsively send a request to the supervising AARMS requesting a recategorizing of the room such that it is perhaps moved automatically or by user-approving vote to a different node in the domains hierarchy and/or pointers for interrelated rooms or nodes are changed to reflect the newly acquired character of the given room.
Incidentally, in one embodiment, users are allowed to present themselves in various chat rooms (per their choosing and if allowed by predefined room policies) under fictitious user names and/or as anonymous and yet their acquired ratings of topic proficiency, user credibility, etc., may be retained. The fictitious user name and/or anonymous feature may be vital for the safety and/or privacy concerns of certain users. For example, one user may be a diamond wholesaler who just received a new shipment of high quality diamonds. He of course does not want to advertise to the whole world his real name or the location of his store. Nonetheless he may want to publicize the event to a trusted user community, where later; trusted members of the community privately contact him for more information about his actual name and store location. Accordingly, in a system where fictitious user names are permitted and yet the system needs to keep trending data on the various users, a secured lookup table is maintained so that system service modules (but nobody else, except perhaps authorized system administrators) can lookup the user's real identity and attribute corresponding trending data to his or her account.
Referring back to
In one embodiment, one or more of the ranking algorithms perform their respective ranking computations only after a newest group of N users (N being a relatively large number such as 100 or more if the node is heavily used) have touched the node with relevant new CFi data. Before the Nth new user touch is detected, the collected CFi data of other touching users are simply stored for future use. The ranking is then done by first filtering the collected data to identify relevant data trends (e.g., major new shift of per-room or per-node common URL's or other topic clustering data) based upon what was stored in the trending data store. The value of N can be varied based on the workload of the system and/or the historical usage load of the given domain or node so that N=1 if the system is under a light load (or the node is not heavily used) and N=(some large number) if the system is under a very heavy load and/or the domain or topic node is a heavily used one. Storing the ranked results only every Nth time can allow for offering of new recommendations to other users to be done faster because fewer real-time calculations will be needed by the ranking engines. In one embodiment, an appropriate sorting algorithm for sorting among the ranked items is chosen for each user based on the user's profiles. After such user-appropriate ranking and sorting, the list of ranked an sorted results is culled by subtracting out any duplicate results that match data supplied by this user so they are not given recommendations of web sites they have just come from. Such an every-Nth-touching technique could automatically provided for culling away of aged or stale older recommendations so that users receive fresh and often newer recommendations each time they accept a further research recommendation, where the recommendation(s) are supplied by the ranking algorithms.
The ranked output(s) of the ranking engine 367 are then fed to a sorting engine 368 which uses a user appropriate sorting algorithm (appropriate for first user 121″) for picking out the best of the ranked remainder data to feedback as recommendations (e.g., 355 of
The above described generation of ranked recommendations for the first user (121″) is repeated for others of the users (e.g., 111″, 131″, 141″, etc.) whose benign spyware resulted in a touching onto node 450′. It is understood that respective instances of engines 365, 367 and 368 are operatively provided for the respective other users. As a result, an accumulation of best ranked recommendations are generated for the community of users who are recently touching upon node 450′. Module 375 automatically collects the best ranked (e.g., highest scored and most often repeated) recommendations produced for the users clustering around node 450′, deletes duplicates among these (after scoring them for popularity) and saves them into accumulated recommendation files (not shown) pointed to by pointers 459X′ of node 450′. Module 375 also keeps track of aging and popularity or recommendations and periodically culls the accumulated recommendation files (not shown) to remove highly aged and not so popular recommendations. As a result, the accumulated recommendation files contain the freshest and most recently highly ranked recommendations for the topic of the given topic node 450′. It is to be recalled that the topic of the given topic node 450′ can dynamically change over time, the chat rooms (e.g., 459N) attached to node 450′ can dynamically change over time, the users actively occupying those rooms can dynamically change over time, and so on. Thus it is valuable to keep the retained recommendations as fresh as possible so that users can find new recommendations they had not seen before when their associated match-making processes re-touch on node 450′. In one embodiment, highly rated ones of aged and to-be-culled recommendations are stored in a permanent collection of old but good recommendations and node 450′ provides a logical link (not shown) to those oldies but goodies. Eligible premium or other users of the system are empowered to reference the permanent collection of oldies but goodies and pull out old recommendations that might be of interest to them.
Another module 380 in embodiment 301 also receives and collects the recent CFi data uploads (371a, 361a) of all users (e.g., 121″, 111″, 131″, 141″, etc.) who have recently touched upon topic node 450′. Same uploaded CFi data such as same URL's are counted so as to determine popularity of each hinting item relative to the touched node 450′. Some of the accumulated hint data (371a, 361a) is given additional weight based on topic credentials of the user who brought the data to node 450′. After counting and weighting, duplicate hint items are deleted and the remainder are stored into appropriate hint storing slots 454′, 455a′, 455b′, etc. (456′) of the node. Among the data items stored in the hint storing slots 454′, etc., overly aged and low weighted items are decayed away over time by action of the hint slots stocking module 380. Accordingly, the hint storing slots 454′, etc., remain filled with the freshest and most up to date hints used by the majority of users (or by the most topic credentialed users) in getting to the node 450′ by action of their respective DLUX instances (363, 372). When a new user has his CFi data uploaded for purpose of finding a matching topic node, the new user's DLUX instance can compare the new user's CFi data against the hint storing slots 454′, etc. of node 450′ and other alike structured nodes so as to produce matching scores and thereby determine which topic nodes have topics that are most likely to currently be on the new user's mind.
There is more. Since every user whose node seeking software (or other automated node-seeking process) comes to touch on node 450′ (and/or touches on another such node) brings his or her current personhood profile (CpCCp) with him or her, and since that personhood profile contains demographic information about and/or credentials information of (e.g., column 154 of
In one embodiment, each heavily used topic node (e.g., 450′, or even selected not-heavily used nodes) has one or more adaptively reprogrammable statistics gathering modules (e.g., 390) associated with it and operatively coupled to the node for collecting statistical information (e.g., demographic information) about the users and/or about their brought-along data (e.g., 371a, 505d″, 506d″) where the automated node seekers of those users brought them to that topic node (figuratively speaking) like bees drawn to the honey. Each statistics gathering module (e.g., 390) operatively couples (e.g., via bidirectional link 391) to one or more analysis controlling and analysis processing servers (e.g., 395). A controlling one of the servers (e.g., 395) sends data gathering instruction signals to the statistics gathering module (e.g., 390) telling it what data to gather and optionally how to initially process that gathered data (e.g., by weighting gathered data with coefficients and/or by averaging data over specified running windows, etc.) Each analysis controlling and/or analysis processing server (e.g., 395) can receive gathered data from plural nodes and/or can control the data gathering activities at each of the plural nodes. Bidirectional link 392 represents the data gathering and gather instructing linkage to the statistics gathering module (like 390) of another node. By collecting appropriate statistical data from selected topic nodes and processing the collected data as may be deemed appropriate for the analysis being conducted, the one or more analysis controlling and/or analysis processing server (e.g., 395) can automatically produce demographic and/or other trending reports indicating how system users are behaving in fairly recent times (especially with regard to joining real time chat rooms covering certain current event topics). The analysis controlling and/or analysis processing server (e.g., 395) can then automatically forward the reports to requesting ones of marketing and/or advertising organizations and thereby enable those organizations to adaptively adjust their behaviors in response to what is happening over a relatively current time period at one or more nodes of the hierarchy tree (e.g., 401 of
While actions of modules 380 and 390 have been described with respect to node-wide CFi data flows and node-wide analyses of the profiles of users whose topic lookup mechanisms substantially touch upon the node, for example when hunting for on-topic chat rooms to preferentially invite each of the users to, it is also within the contemplation of the disclosure to perform a parallel analysis of the same kind on a per-chat-room basis as opposed to on a node-wide basis. In other words, the per-chat-room parallel versions (not separately shown) of module 380 automatically each determine the most often included URL's in the recent CFi data flows of users of each respective chat room running under the node (e.g. 450′) and store these in the parallel per-chat-room versions (not separately shown) of storage area 454′. Similarly, the per-chat-room parallel versions (not separately shown) of module 380 also automatically each determine the most often included keyword hints in the recent CFi data flows of users of each respective chat room running under the node (e.g. 450′) and store these in the parallel per-chat-room versions (not separately shown) of storage area 455a′. The same applies for the parallel per-chat-room versions of storage area 455b′ and of the other such areas 456′. Moreover, parallel per-chat-room versions (not separately shown) of module 390 collect per-chat-room demographic and/or statistics regarding the users whose topic lookup mechanisms substantially touch upon the node and thereafter invite them into (or consider in a significant way to invite them into—but don't due to higher scoring rooms—) the respective chat rooms running under the node (e.g. 450′).
With such information and statistics being collected on a per-chat-room basis, it becomes possible to automatically map the respective chat rooms running under the given node (e.g. 450′) relative to the node's mean and/or median of its chat rooms. Some rooms will have per-chat-room attributes (e.g., most often included URL's, most often included keywords, etc.) that correlate fairly closely to the node-wide mean or median of same attributes of the given node (e.g. 450′). Other rooms will have per-chat-room attributes that correlate more poorly relative to the node-wide mean or median of same attributes of the given node. In one embodiment, attribute correlation scores are automatically generated by analysis servers (similar to 395) and the chat rooms that are most deviant, correlation-wise or otherwise, relative to the node's corresponding mean or median attributes are automatically identified as candidates for automated migration to alternate nodes, where the respective alternate nodes have corresponding mean or median attributes that are more in line with the respective migration candidates' attributes. In one embodiment, the determination to automatically migrate a chat room to a new node is also made on the basis of how clustered the users of the room are in topic space to one another and/or how active the users are or how well populated the room is and what the turnover rate is between users departing the room and new users entering the room. A prioritization arbiter decides which rooms to migrate first on this basis. Accordingly, if resource availability is tight, the more tightly clustered and highly populated ones of deviant rooms will be migrated first and perhaps, less focused and less active rooms, even if they are more deviant may be migrated later or not at all. As mentioned elsewhere herein, room users may alternatively vote on migrating of their room to a new location in the hierarchy tree and/or in topic space. In one embodiment, the more deviant of rooms are migrated automatically without use of user votes while less deviant rooms that are currently populated with a predefined quorum of vote eligible users may require the migration to be approved by the vote eligible users before being migrated.
Referring now to the Global Services Directory Data Store (GSDS) 431 associated with each data center (410, 420, etc.) shown in
Column_1: Service Type—(Rows are: User Account service, Activity Monitoring service, Domain Lookup service, Matching service, Chat Room Management service, and there could be more or specialized variations of these services);
Column_2: Current Network Access path—(URL or IP Address used to access the respective service type from the client machines—this information is downloaded to and stored by the respective client machines, 440a, 440b, etc. when they establish contact with a given data center);
Column_3: Default Home Region—(Defines the geographic area(s) best served by the respective service, based on population demographics and the physical locations of the servers that can provide the respective services);
Column_4: Minimum workload threshold—(If a respective service's current workload (e.g., clients served per second) is less than this predetermined number, it becomes a candidate for being shut down to save power and to have its current workload consolidated into another server of the same type that currently has workload slack sufficient to absorb the to-be-consolidated workload);
Column_5: Maximum workload threshold—(If a respective service's current workload is greater than this predefined number, then the respective service becomes a candidate for having its work split and having one or more of the split apart portions distributed to other services (e.g., remote services) of the same type); and
Column_6: (AMS Assignment—the Activity Monitor Service (AARMS) that is the current owner (supervising Parent) of this service).
As indicated above, for other than the AARMS service; each in-data center service (e.g., 412-418, but there could be more) will have a supervising Parent AARMS watching over its workload. The supervising Parent AARMS need not be a local AARMS. Additionally, although the respective supervising Parent AARMS are/is primarily responsible for assigning jobs to the respective in-data center services, other AARMS (e.g., remote ones) can also assign jobs to the respective in-data center services after getting approval from the respective supervising Parent AARMS. During start up of a data center, the local AARMS (Access and Accessible-Resources Monitoring Services, e.g. 411) will each fetch from its local GSDS (e.g., 431) a list of the services under its assignment (for which the AARMS acts as the supervising Parent) and current settings of those assigned services. GSDS assignment data is continuously mirrored from one data center (e.g., 410) to the next (e.g., 420) so that data centers at least of a given geographic region if not globally across the network are aware of which AARMS is the primary supervisor for which on-line service. GSDS assignment data (in 431) is updated when: (a) one or more new services are added to the corresponding data center; (b) characteristics of an existing services are changed (an example of this may be when workload threshold settings are upgraded because getting the physical or virtual server hosting the respective service is upgraded); (c) one or more on-line services go off line (for maintenance or other reasons) and (d) primary responsibilities for one or more services are transferred from one AARMS to another.
As already indicated via
Referring to the Trending Data Store (TDS) 437 of
Referring to the disposition of the plural data centers (e.g., 410, 420, etc.) of
An in-cloud cooperative group may grow and evolve as the number of users and/or their geographic displacements increase. During periods when usage is expected to be light (e.g., during initial alpha testing or in a region where adoption rates are low), a single physical server within a single data center may suffice to host all of the services for that budding data center. However, as more users in a region discover the advantages of automated invitations to chat rooms that have been pre-screened for topic and personal co-compatibility, the concomitant increased usage expectations will warrant placing multiple physical servers within the single and still nascent datacenter. Each of these physical servers may host one or more of the in-data center services. However as usage increases yet further and a single data center can no longer provide sufficient the robustness and reliability of service to a population users with growing demands, it will become desirable to share work loads among services running in multiple datacenters where the data centers (e.g., 410, 420, etc.) are configured to communicate with each other via a private network 439. More specifically, as mentioned above, it may become advantages to merge services dedicated to esoteric topics and small user populations into relatively slower and smaller servers while splitting services dedicated to highly popular topics and having very large and growing user populations among a plurality of higher speed and larger servers. Thus cost of services is allocated based on the desires of the user population.
Referring again to the AARMS units (411, 411′) in each of the data centers of
When an AARMS instance (e.g., 411) starts up, it accesses its pre-assigned service directory (e.g., 431) to get a list of the resources it is primarily responsible for and also a list of resources at its disposal for off-loading excess work to. While running, the AARMS will keep track of how each of the service resources it owns is being utilized (e.g., what slack in bandwidth is available). Each time a client machine (e.g., 440b) initially tries to connect to its home data center via public network 430, the client machine first tries to connect with its pre-assigned home AARMS. If this fails, the client machine tries an alternate AARMS and works down a list provided for example on a dedicated web page or as on-network list (dedicated for providing a list of alternate AARMS). The AARMS which picks up connection with a signing-in client machine first interacts with a corresponding UAS 412 (that holds a copy of that user's records) to assure that the user password and/or other security measures are properly met for valid sign-in. Once valid sign-in is established, the primary contact AARMS pulls the user's primary CpCCp from the UADS 432 (one that holds a copy of that user's records) and examines the pulled CpCCp in order to determine which other datacenter and other AARMS (with associated DLUX 415) if not the current AARMS, is best suited for servicing the user's general preferences (e.g., favorite topics as listed in area 154-7a of
An overloaded AARMS may automatically request, or an under-loaded AARMS may automatically respond to a request from another AARMS (either in the same data center or in a remote data center), to transfer service assignments between AARMS's. This control process will allow the AARMS's to automatically reallocate services as workloads dynamically change throughout the day. An example of this may be where there is one AARMS per geographic region with each AARMS having a set of default services hosted for that area. There may also be a set of non-default services that are not assigned to each geographic region but are instead maintained only in certain data centers due to lack of popularity. Supervision over any one or more of the default services or nondefault services may get transferred between different AARMS instances as the workloads of each AARMS in each geographic region changes. Services assigned to one geographic region during that region's peak hours of for example the afternoon and evening may not be needed during the slow hours of that region, for example in the early morning. Accordingly, underloaded service providers (e.g., AARMS, UAS, DLUX, DsMS, CRS units) in a currently slow region can be lent out by the data center of that slow region to relieve the burdens on a heavily loaded data center operating in a different time zone. Thus, the distributed data center model with individually distributable service providing resources can dynamically shift workloads to accommodate dynamically changing demands of the regional user population.
One of the primary tasks of an AARMS, when servicing a given client machine (e.g., 440a) is to receive and parse data from CFi's (e.g., 118a) and from Cvi's (e.g., 118b) transmitted form the client machine (e.g., 115 of
The following is an exemplary walk showing a case where a client machine fails to connect to its default primary home AARMS. (Identity of the primary home AARMS and secondary home AARMS and of a web page or other on-network list where further alternated contact AARMS's can be found are stored in one embodiment, in the client machine as part of installation of software package 105.) When the exemplary client machine fails to operatively link with the first AARMS, the next AARMS it contacts then redirects the client to a third AARMS which finally accepts the request and begins to route CFi's received from that client machine to an assigned DLUX service under the third AARMS's supervision:
Step 1. As client software (105) starts in a client machine, it provides user authentication credentials to the primary home AARMS with the expectation that the primary home AARMS (say 411) will pull the user's records from the home UADS 432 and interact with the local UAS 412 to validate the sign-in, after which the primary home AARMS 411 should assign one of its DLUX services (only one, 415, shown in
Option 1a. The first AARMS may not respond because it is in an “offline” status.
Option 1b. Upon the client machine receiving the not-available signal or the timeout counter of the client running out, the client tries to connect to a next AARMS resource in its stored list or web accessed list of known AARMS resources.
Step 2. The second contacted AARMS responds affirmatively to the client machine that contact has been made and the second AARMS (e.g., 411′) accesses the user's account data either from a locally accessible data store (UADS 432′ in center 420), or if the user's records are not there, via the backbone and private network links 417′-439-417 from remote store 432 in another data center (e.g., 410). The fetched user's account data is used to:
Substep 2a. Validate the client's login credentials.
Substep 2b. Obtain the client's current CpCCp (e.g., 105h.1 of
Step 3. The second AARMS then accesses its service directory data store (431′) to determine if, given the client's preferences as indicated in the fetched CpCCp and DsCCp's, whether the client should be redirected to a different AARMS instance that is better suited to handle this particular client. If so, the second AARMS transmits a signal to the client indicating that the client is being redirected and providing the URL or IP address or other link to the third AARMS which the client is now being bounced to. One reason why a different, third AARMS might be more appropriate is because this user's CpCCp and/or DsCCp's indicate the user has highly esoteric needs for which chat rooms that are accessible to the third AARMS might be needed. Such a bounce over may happen if for example:
Option 3a. The third AARMS is geographically closer to the client machine and/or the third AARMS can offer a higher turn-around speed to the client machine (e.g., a roaming cell phone with computing capabilities) and the third AARMS has sufficient load capacity to take on the service needs of the user and/or his currently utilized client machine.
Option 3b. The second AARMS is near its workload capacity and there are other AARMS instances available with spare capacity and with the ability to meet the client's bandwidth requirements (e.g., high ones if the client is a premium service user or lower ones if not subscribed to a premium service).
Step 4. In response, the client machine makes contact with the specified third AARMS (which AARMS will generally accept the contact request because it has been pre-instructed to by the second AARMS, in other words, the second AARMS already made a reservation for this client machine in one of the available time sharing slots of the third AARMS). The third AARMS (not shown) will now access its local UADS (like 432′) to thereby locally gather the user's account information (and if not there, will fetch the data from another UADS) and then the third AARMS will access its local GSDS (like 431′) in order to determine which of its supervised DLUX's is best to route this client's CFi's to:
Option 4a. If only one DLUX is active, the third AMS will route all clients to this single DLUX.
Option 4b. If multiple DLUX's are active and available, the third AARMS will selectively assign the client to a DLUX in a manner that spreads the load among its plural DLUX's as evenly as currently possible.
Step 5. The third AARMS will begin forwarding the CFi's from the signed-in client machine to the selected DLUX instance. In an alternate embodiment, the third AARMS signals to the client which DLUX resource to use and the client machine then responsively begins to forward its CFi's (e.g., 118a of
Step 6. If during all this processing, the third AARMS discovers that it needs to rebalance its loads because a threshold is being approached or has been passed, the third AARMS may elect to redirect selected clients to yet different AARMS instances, especially if the clients are non-premium service ones. When this happens, the process restarts at Step 3 except for a differently numbered, Nth AARMS in this case.
As workloads at specific data centers increase due to increasing numbers of signing-in clients, an automated data center managing service (not shown) may responsively decide to fire up more physical servers where those servers had been kept idle in order to conserve data center energy utilization. As the new servers power up, they will instantiate new AARMS instances. As each instance of an AARMS starts, in one embodiment, it sequences through the following steps:
AMS Step 1. The starting up AARMS instance gets the list of services resources it owns (its supervised child services) from the service directory data store. The assignments in the service directory data store (GSDS) are initially set when new services are added to the data center. Current assignments in the GSDS (431) are updated when services get reassigned during load balancing operations.
AMS Step 2. The starting up AARMS instance initializes each of its child service resources, by sending initialization instructions and getting status reports back, for example in the following order:
AMS SubStep 2a. All online and available CRS Resources (418);
AMS SubStep 2b. All DsMS Resources (416). Part of this process may include:
AMS SubStep 2b(i). Assigning specific CRS resources for each the DsMS's to use.
AMS SubStep 2b(ii). Optionally, assigning specific domain and/or topic nodes listed in the DCDS (435) that the respective DsMS's should be responsible for and thus specialize in making co-compatibility matches for.
AMS SubStep 2b(iii). Optionally, creating default chat room(s) (e.g., empty or populated with an automated moderator) for the assigned domain and/or topic nodes in accordance with the hierarchy definitions provided in the DCDS (see
AMS Step 2c. The starting up AARMS instance initializes all of its owned DLUX Resources (415). Part of this initialization process may include indicating which DsMS resource the DLUX instance should route its match-making requests to after having performed a lookup and identified a probable domain and/or topic for a corresponding one or more processed CFi's. In one embodiment, the initialization process also includes indicating which DsMS resource the DLUX instance should route its match-making requests to if the lookup failed and the CFi(s) is/are instead deemed to be dealing with a default catch-all domain and/or catch-all topic and where the client is thus to be invited to a corresponding catch-all chat room that contains or is to contain personality-wise co-compatible other users. Of course, many variations on which unit asserts control and delegates tasks to the other are possible. In one embodiment each DLUX is made responsible for determining the target number of topic node matches it will look for and the time out of when to stop looking. Thus in such an embodiment, the DLUX, and not the AARMS, is the controlling factor which determines how many invitations if any at all, each user will receive. In an alternate embodiment, the supervising AARMS may have override abilities, such as stopping a DLUX before it reaches its target goal of number of topic nodes found and instructing the DLUX to begin a new lookup, perhaps for a premium subscription client. After a DLUX finds whatever number of matching topic nodes and scores them, either the supervising AARMS, or the DLUX, may forward the scored results to a DsMS instance and initiate the DsMS match making process for that topic node (where the DsMS match making process scores possible chat rooms based on co-compatibility and returns scored links to chat rooms that appear to be most co-compatible with the given user).
AMS Step 2d. The starting up AARMS instance initializes all of its owned UAS resources (432, only one shown). At this point, the starting up AARMS instance can begin to accept client linkage requests and to start servicing those requests. In one embodiment, the availability of the now started up AARMS instance is published into the GSDS (431) of at least the local data center and more typically into the GSDS (e.g., 431′) of sister data centers so that overloaded other AARMS can bounce their excess workload to the now started up AARMS instance. In one embodiment, availability of the now started up AARMS instance is also automatically published into the list of alternate AARMS which client machines can try to connect to when linking to the match-making system.
AMS Step 3. Some aspects of the AARMS initialization process that may be common to all child services are:
AMS Step 3a. Informing each child service how it can connect with and contact with the supervising parent AARMS in order to establish asynchronous two way communications via a local backbone (e.g., 417) or over multiple backbones and private networks (e.g., 439). The asynchronous two way communications may be packet based serial ones in accordance with industry established protocols for the same or they may be proprietary ones.
AMS Step 3b. Requesting current status from each child service.
AMS Step 3c. Updating the local GSDS (431) to indicate current assignments made by the AARMS for its supervised child services and mirroring the assignment information to other GSDS's (e.g., 431′) in other locations.
The DLUX services take on the job of looking through the user's CpCCp and DsCCp's and trying match these with the help of hints in the CFi's to the more probable domain and/or topic nodes to which the DLUX service may be assigned (it could be to all domains). Since the DLUX services have continuous work of sustainably performing lookups for inflowing CFi's it is desirable to prevent each from becoming overwhelmed. Typically an AARMS will simultaneously start all of the DLUX resources it has available so that it can distribute its client jobs to them in a manner that balances the load and assures that all client machines will get relatively rapid response to their CFi submissions. In one embodiment, if the active client population for a given AARMS is more than its current pool of DLUX resources can handle, the AARMS will take the steps listed below.
DLUX overload Step 1. When a parent AARMS detects (through periodic checking of workload levels such as examining backups of requests in buffers or getting pressure push back packets) that one of its child DLUX resources is trending towards reaching its maximum workload threshold or has reached it, the AARMS will start looking for alternate available DLUX resources to reassign some of the workload to:
DLUX overload Step 1a. First the AARMS will begin by checking its own pool of services to see if there is an unused DLUX resource that can be brought online but has not yet been activated, if not;
DLUX overload Step 1b. The AARMS will start making requests for transfer of unused or lightly loaded DLUX resources from other AARMS instances in the same or in remote data centers, where a lightly loaded other DLUX resource will first have to divest itself of current jobs or it will have to partition itself to create a supervisable subpartition controlled by the requesting AARMS (or by another AARMS) before indicating availability to the requesting AARMS.
DLUX overload Step 2. If an available DLUX full resource or subpartition is found, then:
DLUX overload Step 2a. The requesting AARMS will start to redirect new clients to the new DLUX resource either directly or by redirecting the clients to the alternate AARMS which controls the found and available DLUX full resource or subpartition.
DLUX overload Step 2b. The requesting AARMS may also or alternatively instruct the heavily loaded DLUX resources to bounce back some of its current client jobs to the AARMS, at which point the AARMS will forward these to less loaded ones of its directly supervised DLUX resources.
DLUX overload Step 3. If an available DLUX resource is not found, the AARMS having the heavily loaded DLUX will determine if there are other AARMS instances locally or remotely that can take over the excess work and possibly increasing load. If so:
DLUX overload Step 3a. The overloaded AARMS will begin redirecting all new clients to the alternate AARMS, additionally:
DLUX overload Step 3b. The taking over new AARMS may instruct the heavily loaded DLUX to bounce back some part of its still not serviced and current clients over to the alternate AARMS. this can help to clear the backlog in the input buffers (not shown) of the heavily loaded DLUX.
DLUX overload Step 4. If the overloaded AARMS cannot rebalance its DLUX work loads by the above methods, the local DLUX resources and/or the overloaded AARMS will start to implement load throttling techniques wherein they simply drop some of the client sourced job requests (arising out of uploaded CFi's). In one embodiment, load throttling instructions or backpressure flags are downloaded to the clients as part of their next Cciv posts. The client machine may optionally flag an indication to its user apologizing that the chat room invitations service is currently in a throttled down mode. In the same or another embodiment, load reduction may be implemented by the cloud downloading new CFi filtering requirements to one or more of the client machines so as to thereby reduce the amount of uploaded CFi data. For example, a new CFi filtering requirement might indicate to the instructed client machine to temporarily increase your threshold for sufficient biometric intensity for recording the biometric event in the CFi buffer by 10%. In response, where the minimal increase of user heart rate was 5% to warrant recording, now for a predefined amount of time it will be raised to 5.5%. Thus the amount of uploaded CFi data will tend to decrease. The new CFi filtering requirement instructions provide the cloud with a method of fine tuning the rate at which CFi data is uploaded to it and of placing the filtering workload in the laps of the client machines.
After a DLUX resource finds a probable match between received CFi's and a given domain and/or topic node, it falls to one of the DsMS resources to find the appropriate chat room under that looked-up domain and/or topic node that is co-compatible with the corresponding user. The match-making services (DsMS's 416, 416′) can work most efficiently when they can provide chat room matches for the pool of clients assigned to them via the local AARMS without having to do global searches across all possible chat rooms. In order for the co-compatible aspect to work effectively, each DsMS should receive jobs from a sufficiently large population of different clients so as to be able to provide good chat opportunities to co-compatible clients. If the population of different clients is too small, the DsMS may not be able to make a match that fully or partially satisfies the co-compatibility preferences of two or more members of the serviced population. On the other hand, if the to-be-serviced client population is too large, the DsMS may not have the bandwidth to make matches in a timely manner. One of the ways to control the size and diversity of the client population that is to-be-serviced by a given DsMS (e.g., 416′) is by changing the number of domains and/or the number or identities of the topics covered by that DsMS.
In one embodiment, in order to provide an optimal load for each of the DsMS resources, specific domains (and/or specific topics under those specific domains) are assigned to the respective DsMS resources by the supervising AARMS and the assigned specific domains/topics are marked as being serviceable either only locally or globally. What is meant here by “locally” is that chat room matching services are provided only for the local AARMS that owns the local DLUX and the local DsMS and the DLUX was servicing the CFi's of a user for which this data center is a default home center or a default secondary home (backup home). This assures that home town users will not be deprived of minimal bandwidth when a surge of out-of-town CFi servicing requests comes streaming in, due for example outage at a nearby data center. What is meant here (in this paragraph) by “globally” is that chat room matching services are provided for out-of-data center requesters also. DsMS load control may include the following steps:
DsMS load control Step 1. When a parent AARMS sees one of its child DsMS resources reaching its maximum workload threshold, it will look for alternate available DsMS resources to take on some of the workload:
DsMS load control Step 1a. The looking AARMS begins by checking its own pool of DsMS resources to see if there is an unused (e.g., off line) MS resource that can now be brought on line to the share or split the workload.
DsMS load control Step 1b. The looking AARMS next checks its pool of DsMS resources to see if there are any underutilized DsMS resources that can take on some of the overload by taking on responsibility for some of the nodes now handled by the overloaded DsMS.
DsMS load control Step 1c. The looking AARMS next issues requests via the backbone 417 and/or private network 439 for transfer of a Matching Service resource from another AARMS (local or remote) to supervision under the looking AARMS.
DsMS load control Step 1d. If it gets supervision over a less loaded DsMS, the looking AARMS will begin determining how to reassign one or more of the domains and/or topics currently being handled by the overloaded local DsMS resource to one or more of the more lightly loaded other DsMS resources belonging to other AARMS.
DsMS load control Step 2. If an available lightly loaded Matching Service resource has been found
DsMS load control Step 2a. The AARMS looking to relieve one of its own DsMS's will automatically determine how assignment of the specific domains and/or topics of the overloaded DsMS should be split up between the fully loaded and the available DsMS other resources. This determination may be made by:
DsMS load control Step 2a(i). Checking to see if a specific global domain node has enough client traffic to warrant being split into both a global servicing node and a local only servicing node.
DsMS load control Step 2a(ii). Determining which one or more of the lightly used domain and/or topic nodes on the heavily loaded DsMS resource can be transferred to the more lightly loaded DsMS resource so as not to overload the latter.
DsMS load control Step 2b. If the responsibility for a globally serviced domain node is transferred to a matching service in an alternate AARMS (in another data center), the originating AARMS will inform all other AARMS resources of this change via changes to the GSDS 431 and mirroring of the same to other GSDS's (e.g., 431′). Then each AARMS will inform all its DLUX resources of this change.
DsMS load control Step 3. If a given AARMS cannot balance its DsMS loads, the local DsMS and/or DLUX resources will start to implement load throttling techniques described above for the Matching Service Client overload conditions. Portions of the load throttling instructions may be sent to clients as part of their next Cciv posts.
In one embodiment, aside from making matches between chat rooms and CFi's of individual users, DsMS instances with spare capacity can use their spare bandwidth to make co-compatibility matches between one user and the next (background clustering) even if the users are not currently on line. This may be done by crawling through the CpCCp's of users to find cases of extreme personality-based co-compatibility and/or crawling through the DsCCp's of users to find cases of extreme topic-based co-compatibility. These results may be stored in the respective user's account data store records (e.g., 432). In one embodiment, the system may periodically recommend a pen-pal relation or the like to users who have not previously conversed, this being based on a crawl found extreme co-compatibility involving personality-based co-compatibility and/or topic-based co-compatibility.
Referring to
In some instances, a user may have already received more than a targeted number of good invitations in a recent previous round of lookup and matching. In this case, depending on resource availability, step 422 may downgrade the target numbers for this round if local bandwidth availability is currently tight and the user got a sufficient number of good invitations just recently to satisfy the owed quality of service to that user. On the other hand, if current bandwidth availability is relatively wide and the user was short changed in the previous round, the target numbers may be upgraded to thereby attempt to satisfy the owed quality of service to the given user. In some instances, the given DLUX or its whole data center is being overwhelmed with too much work and it needs to throttle down its allocated services for all users. In such a case, the target number may be reduced for all users, perhaps less so for premium service users than for lower priority users.
Referring still to steps 421 and 422, in one embodiment, the initial or adjusted chat opportunity target count goal and matching score minimum thresholds are determined based on:
Presence or absence of redirection instructions from AARMS-initiated load balancing operations and the severity of such pending load balancing requests;
The number of chat opportunities offered to the same client fairly recently (e.g., in the past 10 minutes); and
The number of chat rooms the client is currently participating in and the degree of participation. In other words, if the user of the client machine is busy writing in contributions to a first chat room, it is unlikely that he or she will have time to notice new incoming chat invitations and join in those as well. Thus for a user who is already heavily engaged with a first set of one or more ongoing chat operations—this status being reported to the cloud by the user's client machine—the cloud can respond by temporarily shutting off or substantially throttling down the number of chat room invitations being currently sent to that user, in which case the target number may intentionally be forced down to 0 even though normally it would be a higher value. As a result of the temporarily forced zero count, step 423 passes control to exit step 423x and DLUX resources are not consumed for servicing the user who is already busily engaged with one or more chat rooms.
In one embodiment, the following general rule is followed:
The larger the number of recent chat opportunities presented to the client, the lower the target count will be (in order to keep the user from being overwhelmed with too many chat opportunity invitations) and the higher the matching score requirements will be (in order to ensure high quality matches if invitations are at all sent, where here, the matching score requirement is a minimum or threshold score (e.g., co-compatibility score and/or narrowness of topic score) needed for allowing an invitation to be sent out)—In one embodiment, the DLUX provides the DsMS with a target count and a minimum matching score requirement and a timeout limit so that the DsMS will have guidelines to follow on how much effort it should spend on trying to make a match. If the target count has been reached or the sorted scores begin to fall below the minimum threshold or the timeout limit is reached, the DsMS can stop;
The fewer the number of chat opportunities (Cciv's) offered to a user relative to an adjusted target count, the lower the minimum matching score requirements will be made (by readjustment) so as to thereby find and offer at least some chat opportunities to the otherwise short changed client. In other words, in response to failure to find the desired number of high quality matches, if time has not run out in below described step 426a, a loop back to the top of the algorithm will be made where the degree of closeness of topic co-compatibility and/or personality co-compatibility will be automatically scaled back so that at least some invitations are generated even though these invitations are suboptimal relative to what is indicated to be desirable in the user's DsCCp's and/or CpCCp.
At step 423 the process determines if the resulting target values, after adjustment in step 422, are equal to or less than zero. If yes, there are no invitations to be sent back to the client machine and the job terminates at exit step 423x so that the local DLUX resources can be used to service another client. If test 423 results with a No, then in step 423a the current DLUX fetches the user's PEEP, CpCCp and optionally her root DsCCp and optionally her topic specific DsCCp's from the local UADS (e.g., 432). Step 423b is the head of domain identifying loop. If the AARMS and/or the user's client machine have not already done so, the DLUX may use the user's PEEP to parse and group the data found in one or more CFi's so that parsed and grouped data is likely to indicate probable topic of interest on the user's mind and also the degree emotional engagement with the topic. Parsed and grouped hint data is sorted so that the hints with the greater degree of emotional engagement will be processed first by the DLUX. In one embodiment, at least a majority of the CFi data parsing and/or grouping functions are performed in the user's local client machine using a downloaded copy of the situation appropriate PEEP or a situation selected copy of a locally stored LPeep file (if the client machine has sufficient computational resources for doing so, that is, the local machine is not for example a minimal function cell phone or the like). This localized parsing and grouping of the CFi data can improve the chances that the right biometric data will be correctly logically linked to its causative and focused-upon content while at the same time reducing the workload placed on the in-cloud server(s). In some cases, the local client machine can perform all of the needed parsing and grouping of data in a CFi data stream and then the in-cloud AARMS may not be needed for this process at all and can simply pass the already parsed and grouped CFi data stream to a selected DLUX for further processing (for identifying the one or more topic nodes that score highest relative to the topic hints provided by the CFi data stream). For each pulled CFi (or parsed and grouped data obtained from a plurality of CFi's) of the current processing round, the topic hints or clues in the CFi's are correlated against hint-to-domain probability factors provided in the user's profiles (e.g., in the user's CpCCp and/or DsCCp and/or knowledge-base rules sets provided therein) in step 423c. Probability-of-match scores are computed and assigned for each CFi's hint group relative to the likely domains that associate with it. After all recently pulled CFi's are looped through for purpose of identifying the most likely current domain, the formed list of domains is ordered in step 423c so as to list the most likely domain at the top of the list. Scoring may be performed with aid of knowledge-base rules sets as will be detailed below.
At step 424a, the formed list of likely domains is processed and again for each of the recently parsed and grouped hint data sets (from the recently pulled CFi's), a machine-implemented determination is made as to which topics under each of the more likely domains is a more likely topic (or subtopic, etc.). Depending on the targeted degree of topic sameness that was established in steps 421-422, the amount of work done in the topic loop (whose head is step 424b) will vary. For each pulled CFi(s) data group of the current processing round, the topic hints or clues in the CFi's are correlated against the hint-to-topic probability or scoring factors provided in the user's profiles (e.g., DsCCp's including knowledge-base rules set in each such DsCCp) in step 424c. Probability of match scores are computed and assigned for each CFi data group versus its more likely topics (e.g., the top 3 or 5 most likely topics). After all recently pulled CFi data groups are looped through for purpose of identifying the most likely current topics for each, the formed list of topics under the current, likely domain is ordered according to score or probability in step 424c so as to list the most likely topic (or subtopic, etc.) at the top of the list.
At step 425a, the formed list of likely topics is processed from the top by handing off (step 425b) to corresponding local DsMS instances in the data center (e.g., 410) the job of finding a co-compatible one or more chat rooms (or other online forums) that closely correlate to preferences in the user's CpCCp and/or DsCCp for the kind of chat rooms the user prefers to be invited into based for example on personality and/or topic proficiency. Step 426a determines if the earlier established target goals (of steps 421-422) for number of chat opportunities have been met or if a predefined time out has been reached. If yes, control is passed to step 427 where the found matches are scored for co-compatibility with the user's preferences (e.g., as expressed in CpCCp and/or DsCCp) and sorted accordingly with highest scoring ones to be sent to the user's local machine first. Then in step 428, all or a highest scoring subset of the corresponding invitations for the found chat rooms are downloaded to the client machine as pushed Cciv's (e.g., 118c of
One machine-implemented process that may be used for scoring domains (e.g., 423c) or topics (e.g., 424c) or other potentially matchable nodes (see
Domain Scoring Step 1: It is possible for a user to be looking at content that provides essentially no useful hints as to the domain most probably on the user's mind. For example, in
Table 1 roughly parallels major row 191 of
The amount that the trending update service modules increase or decrease each initial score is a function of a system stored initial score adjustment algorithm, where the latter may take into account various trending factors including how active the user has recently been in that domain and how far back in time the user's preference for that domain goes. In one embodiment, the system may hold in storage a plurality of standardized or template adjustment algorithms for adjusting initial domain scores where the respective different algorithms are respectively used at different times of day, week or for other predetermined circumstance. For example, one or more of the conditionally selectable template adjustment algorithms may include a subroutine that accounts for the condition that, just because Sam has in the last 6 months become intensely interested in Politics_(national), that factor does not totally erase the effects of his continued and persistent interest over the previous last 10 years in the Finance.002 domain (row 2). While the trending update service modules may have rapidly elevated the Politics_(national) domain (row 1) from a score close to zero (or even a negative initial score) to one being the highest current score (e.g., +100), the adjustment algorithm(s) did not as rapidly demote the initial score of the Finance.002 domain in view of the inertia of its long history of frequent past usage even though Sam may have been neglecting that domain as of late. After the current political election cycle ends, it is likely that Sam will return to having Finance.002 as his most favorite domain. The algorithm(s) model that likely behavior and adjust initial scores accordingly. The specific adjustment algorithm(s) used for initial score adjustments may vary from system to system, data center to other center, over different time periods and/or from user to user so as to account for short-lived fads in certain topics and the like that may temporarily sweep a system-served region. In one embodiment, premium subscription users may have personal knowledge-base rules sets that control how the trending update service modules increase or decrease their initial scores and the premium users may be allowed to fine tune these update controlling rules.
As may be appreciated from above Table 1, Sam's list of favorite domains is longer than the initial 5 domains his template DsCCp (not shown) listed when he first joined. Since then, the trending update service modules have not only automatically figured out what specific domains are Sam's top N (e.g., N=10, not all shown), but the trending update service modules have automatically adjusted the initial scores for those domains, removed some initial domain names, added some new ones all in view of Sam's recent trending histories for the domains now listed in Table 1, which histories are respectively pointed to by tPointers 1 through N of the fourth column of Table 1. A word is in order here about what the word “domain” means in the context of Sam's Table 1. It should be apparent from
Incidentally, it may be appreciated from the above that processing of a lookup assisting, relational database table, like above Table 1, can consume significant system resources. On the other hand, there may be certain circumstances under which resort to the lookup assisting table (e.g., Table 1) is a complete waste of time. For example, a given user (e.g., Sam) may have a respective habit of behavior where, it is 9:30 AM (EST) and it is a day on which the New York Stock Market is open, the only topic he has on his mind is the Finance.002 topic. It would be a waste of system resources and energies to lookup Table 1 and start competitively scoring all the possible domains and/or topics, subtopics, etc., that Sam may be thinking about. Instead, an overriding and earlier executed rule in the given user's DsCCp knowledge-base rules set 195 might read as follows: 0. IF Time_of_Day is in range 9:25 AM (EST) to 10:05 AM (EST) AND Day_of_Week=Market_Open_Day, THEN Ignore Scoring Table 1 and Return Matching Domain Set as Finance.002. Special and earlier executed rules for overriding the entire lookup assisting table (e.g., Table 1) or excluding from consideration certain parts of it (certain rows and/or columns) may use a variety of triggering conditionals including for example, time of day, week, month or year; current surroundings of the user (e.g., work versus home, alone versus accompanied by others); the type of primary client machine being used (e.g., small screen PDA as opposed to wide or multiple screens home desktop computer), and so on. System resources can be significantly conserved by use of such selective override or exclusion rules.
Still referring to Table 1, it may be may be appreciated that the automated trending update service modules have also automatically determined what Sam's top M web page URL's were under each domain and their order of preferential visitation to such URL's by Sam. These table-recorded URL's are the ones that Sam most often referred to during his PEEP-defined normal time-stretches when accepting invitations to the corresponding domains (where M is a system specified number such as 3, 5, etc. and PEEP-defined normal time-stretch can vary from domain-to-domain). Note that the entry in row 8 of column 5 includes not only the name of a URL called More.com (a fictitious alias) but also a pointer (ptr2rules.4_more.com) which points to one or more knowledge-base rules associated with that URL and the domain of its row in Table 1. In fact each URL listed down column 5 of Table 1 can have a respective “pointer to rules for” (ptr2rules.4_) it recorded in Table 1 or otherwise logically linked to that URL's listing in Table 1. The reason for having such pointers will explained shortly.
Still referring to Table 1, it may be may be further appreciated that the automated trending update service modules have also automatically determined for each listed domain what the top Q search keywords were (and their order of preference by Sam as shown in the sixth column) where these table-recorded search keywords are the ones that Sam most often used to during his PEEP-defined normal time-stretches when accepting invitations to the corresponding domain (where Q is a system specified number such as 3, 5, etc.). The trending update service modules have also automatically determined for each listed domain what the top P meta-tags were that were present (and their relative frequencies of presence as shown in the seventh column) where these table-recorded meta-tags that were most frequently present (embedded) ones in the focused upon content that Sam was browsing during his PEEP-defined normal time-stretches when accepting invitations to the corresponding domain (where P is a system specified number such as 3, 5, etc.) Table 1 may of course have more columns that list yet other attributes which are most frequently associated with the respective domains and optionally pointers to knowledge-base rules sets associated with those attributes.
Domain Scoring Optional Step 2: The initial scores listed in column 3 of Table 1 are not necessarily the final scores allocated to the listed domains when performing a domain lookup. They will be final if there is no other useful hinting information available for improving the guess as to what topic the user has in mind. Assuming however, that there is some form of usable hint data in the CFi's recently pulled from Sam's local machine(s), the domain lookup process will use the initial scores merely as a starting point for generating running scores that modulate up or down relative to the initial scores (or don't change) based on additional hinting information provided by CFi's uploaded over stretches of time corresponding to Sam's PEEP-defined normal time-stretches for the respective domains (the time-stretches may different, for example only 2 minutes to look at today's comic strip, but 10 minutes to study today's stock market results). In one embodiment, time for re-scoring is limited to a predefined number (can vary if user is a premium user). In other words, whatever the running scores are when the time limit runs out, those scores are taken as good enough competitive indicators of what is likely on the given user's mind. In such a system, the score changing computations with potential for larger score changes should be run first and those with finer refinements of score run later. In one embodiment, the initial list of N domains provided by Table 1 and under consideration (if not selectively excluded out) by the domain lookup process may increase or decrease as a result of execution of various knowledge-base rules including rules that can exclude from consideration some of the domains listed in the user's Table 1. In other words, although Politics_(national) is listed in Table 1 as having the highest initial probability of being on Sam's mind, certain hints collected from recent CFi's may cause that domain to be excluded from further consideration and when this happens, the system can stop keeping a running score for such an already excluded domain. In forming the running scores for non-excluded domains, the domain lookup process combines the initial scores assigned to Sam's top N domains (if not excluded, and also to scores of additional domains which may be brought into consideration by knowledge-base rules) with score increasing and/or score decreasing factors to thus form current running scores (which scores can dynamically change due to new CFi's being further uploaded into the cloud in, say, the next 30 seconds).
More specifically, suppose for example that Sam visited the WSJ.com web page in the last 2 minutes. His initial score of +95 for the Finance.002 domain may be automatically increased to +105 as a result. But suppose that Sam also visited the NYTimes.com web page in the last 3 minutes. His initial score of +100 for the Politics_(national) domain (row 1) may be automatically increased to +108 as a result. Similarly if any of the table-listed favorite search keywords are found to have been used in the last X minutes (X being variable on a domain by domain basis), then the respective running scores may be automatically increased or decreased for each occurrence by appropriately weighted amounts in response. Similarly if any of the table-listed frequent meta-tags are found to have been present in the last Y minutes in content Sam was intently focusing upon (Y being variable on a domain by domain basis) then the respective scores may be automatically increased or decreased for each occurrence by appropriately weighted amounts in response. The amounts of change of each running score may be a function of a system stored running score adjustment algorithm, where the latter may take into account various trending factors including those operating on a user-by-user basis, on a data center-by-data center basis and/or on the basis of time of day, of week, of month, etc. As such the preliminary running score adjustment algorithm used for such first round adjustments (there may be further re-scoring rounds as discussed below) can vary from system-to-system and there is no specific embodiment discloseable here for better empowering artisans to carry out the same. Note that weighting of score adjustments can take into account the intensity of focus (e.g., emotional engagement) that Sam exhibits in conjunction with each CFi provided data point (e.g., URL, keyword, meta-tag) and thus weights need not be purely linear but can instead be products of an intensity of focus score multiplied by an occurrence-of-hint score and multiplied by a factor representing preference position in an ordered list of table-specified hints. More specifically, because the keyword hint, “soccer” appears first in the list of favorite keywords of row 3 (Sports) and “game” appears third, detection of “soccer” will generally tend to increase the running score for the row 3 domain (Sports) more than detection of “game” as a recent keyword. Moreover, note that the keyword, “game” appears also in row 4 of Table 1 (for Poker). So if the only useful hint data pulled from recent CFi's is the search word, “game”, the running scores of the row 3 and row 4 domains would both be increased by roughly the same amount and the relative competitive scoring positions of the two domains, if both are not excluded from consideration, would generally not change.
Domain Scoring Optional Step 3: As mentioned above, there is only so much improvement attainable in guessing at a user's current domain of interest and the user's current topic of interest under that domain by using the 2 dimensional table approach of above Table 1. Firstly, there is a practical limit as to how large the number N can be for the number of most favorite domains tracked for every user by a table such as Table 1. Secondly, no matter how large N is, there can still be an obscure domain that the user (e.g., Sam) currently has on his mind and is not yet listed in his top N domains in Table 1. So if the domain lookup process relied only on scoring the top N domains of Table 1, the system may more often than desirable, invite Sam to an incorrect chat room because the system did not take into account the possibility that Sam is thinking about a domain not yet listed as the top N domains that Sam frequents. Thirdly, the system may waste time, energy and resources in conducting unnecessary scoring activities under various circumstances. Suppose for example, it is determinable that 99% of the time during business days (e.g., Monday to Friday) and between the hours of 9 AM and 5 PM, a given user such as Sam does not think about the domains of above Table 1, rows 3-5 and rows 8-N. In such as case it would be wasteful to compute scores for those domains during the stated time periods. A simple database having only a structure like Table 1 cannot conventionally account for all such possible variations. On the other hand, a knowledge-base rules set such as 195 of
As seen from the above pseudo code, the DsCCp knowledge-base rules set 195 of one embodiment can control how scoring is performed under various conditions including time of day and location from which the user is operating. Additionally it should be mentioned that the initial list of domains or topics considered can be expanded beyond that provided for by Table 1 through use of consideration-expanding rules, such as for example: IF Time_of_day:=After Work AND Surroundings:=Home, THEN ADD to list of nodes to be scored: <begin list>My_Hobby with an initial score of 88<end list>. This has the effect of dynamically expanding Table 1. Accordingly, entirely different initial domains and corresponding different scoring algorithms may be selectively executed in response to varying conditions so as to more flexibly determine what domain a given user is probably thinking about in view of uploaded CFi data including CFi data that indicates where the user is located and what the time was for respective ones of the collected pieces of topic hint data and emotional state indicating data.
Moreover, if certain combinations of external events take place, the knowledge-base rules set 195 may include one or more conditional rules that cause esoteric domains to be added to the list of domains under consideration and thus being scored competitively against other domains under consideration. For example, set 195 may include the rule: IF Time_of_Year=International World Soccer Cup Semifinals or Finals THEN Add Sports.100 domain to Domains_scoring_List AND Set Initial_Score of Sports.100 domain to +200 AND Set End_of_Range of Business_Day to 3 PM (rather than usual 5 PM). Accordingly, it is seen that a soccer enthusiast may command the system to accommodate his esoteric preferences on an individualized basis, cut the definition of his routine work day short and add a special domain into the competitive pool when the International World Soccer Cup Semifinal or Final games are taking place. Additionally, as mentioned above, automated trending services may automatically readjust a user's knowledge-base rules set to more accurately reflect his actual behavior as opposed to his declared behavior. For example, although Sam said he would work until 3 PM during soccer season, in fact for the last 3 years he had run home at 2 PM to watch the games. In one embodiment, the trending services would spot that and automatically modify the above soccer cup handling rule to end the business day at 2 PM rather than 3 PM as Sam had said. This way the system will be serving Sam according to his actual behavior rather than his declared behavior.
To summarize part of what is taught by the above, in accordance with one embodiment, the knowledge-base rules set 195 in the user's currently active DsCCp (106h.1) has a first set of one or more rules that control which of a limited number of N′ domains will be actively considered and scored (as opposed to being excluded under current circumstances, where the limited number N′ can be greater than N as well as less than the N of Table 1, e.g., N=10) and which scoring algorithms will be used for performing such first round or later round re-scorings. These one or more scoring algorithm control rules are executed before any of the actual first round or later round domain re-scoring algorithms are executed. (The later round domain re-scoring algorithms will take into account synergisms of occurrence such as, IF Snapshot_of_content being_focused_upon includes WORD1 Within_5_words_of WORD2, THEN Increase_Score_of (Domain 6) by +70.)
Parsing, grouping, cross-linking and further weighting of CFi-supplied data samples prior to domain lookup: Referring briefly back to
However, the user's PEEP record usually does not indicate how he behaves with respect specific domains. In one embodiment, parsing, grouping and weighting of CFi-supplied data samples is a task that is split between the AARMS module that initially receives the CFi streams of user X and the DLUX module(s) to which the AARMS forwards the job for completion. The AARMS will handle the processing of the emotional state portion of the parsing task so that it can then prioritize domain lookup tasks according to how emotionally involved the user appears to be with that certain content. However, some of the parsing and grouping task calls for knowledge about the user's Domain-specific behaviors and this information is generally stored in the user's DsCCp records, where the latter are generally processed by the DLUX service module to which the AARMS hands off completion of the domain determination task (and also the topic lookup task). So in the example given immediately above, the AARMS would know to create a data grouping or cross-referencing link between the content identifier in the CFI that was time stamped 2 minutes earlier and the emotional reaction data supplied in the current CFi. However, the AARMS would not know how to properly parse and group the new keyword data that just came in and happens to be part of an unrelated search because information for parsing of such domain specific data is typically contained in the DsCCp rules 195 rather than in the PEEP rules 199. So the AARMS hands off partially resolved streams of CFi data (partially cross-linked CFi sample point data) to the DLUX module and the latter completes the parsing and grouping task based on the user's current DsCCp record 106h.1. Scanning down column 6 of above Table 1 for example, the DLUX can determine what search keywords most probably correlate with what domains. The DLUX can also determine what the more probable domains are that the content from 2 minutes ago belongs to. If the two lists of domains do not overlap, the DLUX can conclude that the keywords of the current CFi are not to be grouped with (cross linked with) the content of the CFi from 2 minutes ago. While this is an all or nothing example, it can be appreciated that for gray zone situations, the DLUX assigns grouping weights or probability of grouping factors to different pieces of incoming sample data. The agitated emotional state of the current CFi and the 2 minute old content of the previous CFi may have a strong cross-grouping factor linking the two data items while the less certain plurality of recent keywords may acquire a weaker cross-grouping factor between itself and the 2 minute old previous content. Since the agitated emotional state reported in the most recent CFi cannot possibly be a delayed outcome of the currently received search terms, the cross-grouping factor between the recent keywords and the agitated emotional state will generally be set to zero. In this way a historical record of events and underlying cross-grouping factors is built up by the DLUX. The cross-grouping factors function as weights that emphasize cross effects between more clearly linked together data samples and deemphasize cross effects between less clearly linked together data samples as they are parsed out from the streams of CFi's uploaded into the cloud 150. One way of thinking about this process is by analogy to a double sided data recording tape where observed data is recorded in chronological sequence on one side of the double sided tape and hypotheses about interrelations between the observed data points are recorded on the other face of the data recording tape.
With parse dand cross-linked sample data points in place, the DLUX is in a position to further weight content-identifying data points as a function of the strongly cross linked topic hints that go with them and as a function of the more strongly cross linked biometric data items that also go with them. More specifically, for each “known” URL or alike content identifier that appears in the fifth column of above Table 1 and for the N′ domains that are under consideration and being scored there should be a corresponding cross-correlation rule in area 195 of the DsCCp that increases or decreases the running scores of the N′ domains under consideration according to cross-correlation of data items. For example, IF URL:=NYTimes.com AND Cross_link_to emotional data:=Strong, THEN Increase_score_of (Domain of row 1, if not excluded) by +20, Increase_score_of (Domain of row 2, if not excluded) by +5, Decrease_score_of (Domain of row 3, if not excluded) by −10, Decrease_score_of (row 4 (Poker), if not excluded) by −20, etc. In other words, for each CFi data sample or Value uploaded from the user's reporting device(s), first it will be determined what the type is of the data sample (e.g., URL or alike content location identifier, keyword, meta-tag etc.) and also whether the uploaded data point sample is a table-known one already stored in Table 1 (or an equivalent thereof). If yes, then in a pointer layer (not fully shown, see ptr2rules4_) that shadows the contents of Table 1 there will be pointers to corresponding scoring rules. For example, logically linked with the “NYTimes.com” entry in column 5, row 1 of above Table 1 there will be a pointer to one or more scoring rules like the immediately above, IF URL:=NYTimes.com AND . . . rule. The associated rule for the known Table-included sample point will be applied and the N′ domain scores under consideration will be adjusted accordingly.
-
- Treatment of Nondescript Common Words: If one or more CFi-supplied sample point data items is not in Table 1 but is instead stored in another table of predefined common nondescript words like “the”, “of”, etc., a separate rule for handling such common nondescript words will be executed where typically the scoring action is to ignore the nondescript words and not change the scores of the N′ domains under consideration in response. Of course, there can be esoteric exceptions to this general rule and such exceptions will be expressed within the rule that handles the listed and generally common nondescript words.
- Treatment of routinely opened Known Locations. Typically, when a user first launches his browser (e.g., FireFox™, Internet Explorer™, etc.) the browser may have an initialization script that it automatically executes upon launching where it downloads one or more default start pages (i.e. Yahoo™ MyYahoo™, MSN™, GoogleNews™, iGoogle™, etc.). In such a case, because user activity did not directly and intentionally cause the loading of these routine pages, the URL's and other topic hints found on these pages will generally not be indicative of the user's current topics (or domains) of substantial interest. The knowledge-base rules set 195 of the current DsCCp 106h.1 (e.g., the user's root DsCCp) may accordingly include a special processing rule for web pages that are initially or routinely downloaded shortly after launch of the browser. For example, IF Time_after_browser_launch <2 minutes multiply uploaded sample data points thus far by an importance de-weighting factor of 0.1. In an alternate embodiment, the de-weighting factor assigned to such launch associated data points (e.g., URL, Meta tags and snapshot content) can be a weight of 0. The point here is that some web pages should be automatically ignored so that time and machine resources are not wasted attempting to do domain lookups for them.
- Treatment of different types of CFi-supplied data points (Treatment by CFi Value Category): Some CFi-supplied data points can be of greater importance in determining likely domain of interest than others. For example, if the user entered a set of keywords into his or her search engine 5 minutes ago and then spent the last three minutes intently studying content in a URL found by the search engine, that can be taken as highly supportive of the hypothesis that the keywords of 5 minutes ago strongly cross-correlate with the topic of interest currently on the user's mind. A corresponding treatment rule in knowledge-base 195 may read as follows: IF URL_of_strong_interest follows within 7 minutes after keyword search THEN apply importance weighting increasing factor of 1.8 to the keywords. Thus, Search Term Values submitted by the user as part of an explicit search request are taken as highly indicative of what is on the user's mind because these are values that the user has explicitly expressed an interest in. The specific knowledge-base rule(s) used to more heavily weight such user expressed keywords can vary from user-to-user and from one surrounding environment or time to the next.
- Treatment of extremely unique file, page or other content addressing information—Some URL addresses are relatively non-informative of what is on the user's mind because they connect to a broad topic portal, say Google.com™. As such, when a CFi provides such a broad topic hint (be it to a widely used internet page or to a file directory that contains files directed at a sundry of random topics or another form of content addressing information whose covered topics are non-unique) there is not much that the domain lookup process can do with this information. On the other hand, some URL addresses or other content addressing information may be extremely unique and thus tightly coupled to one specific or to a fairly limited group of domains or topics. Accordingly, in one embodiment, a list is stored for each user of such corresponding and tightly coupled URL's or other content addressing information and the one or more small number of topics or domains that they tightly couple to when the given user is involved. An importance-increasing factor is then applied to such listed addresses when they show up in the CFi stream and the list of unique URL or other addresses is consulted by the domain lookup process when one of these addresses is present. Such unique addresses may be collected from the user's web browser, his FTP client, pod-catcher, etc. These addresses may be in the form of a URL for a web page, an FTP site address and/or the name of a file being downloaded or in the form of a podcast's URI, or any other type of unique combination of data that points to the content the user is interacting with (viewing, downloading, listening to, etc) where the corresponding set of associated topics or domains is relatively narrow (e.g., 5 or less)
- Treatment of extremely informative Meta Tags: As mentioned above, meta-tags are typically hidden codes embedded in web page content (e.g., HTML or XML content) or in podcast content (or in the source page or home page from where the podcast stream or other stream, i.e. RSS was obtained) and these often indicate what the author of the content believed to be significant descriptors of the corresponding content. Some meta-tags can be rather broad in nature and thus not informative enough regarding what is likely on the user's mind (e.g., Sam's) when they connect to content having such meta-tags embedded in it. On the other hand, other meta-tags can be extremely unique and thus tightly coupled to one specific or to a fairly limited group of domains or topics. Accordingly, in one embodiment, a list is stored for each user of such corresponding and tightly coupled meta-tags (the more often seen ones) and the one or more small number of topics or domains that they tightly couple to when the given user is involved. An importance-increasing factor is then applied to such listed meta-tags when they show up in the CFi stream and the list of unique meta-tags is consulted by the domain lookup process when one of these meta-tags is present.
- Treatment of potentially informative Web Page heading fields and the like. As known to those skilled in HTML or other web page defining languages (including XML, CSS etc.), certain content may be embraced between <<Hn>> and <</Hn>> tags, where n is a heading level number. Other page defining languages may use stylesheet references where the referenced style sheets may include emphasis commands for style like Title, Big, Bold, etc., and these are often used to indicate important parts of the to-be-displayed web page. In one embodiment, an importance-increasing factor is automatically applied to such content that is emphasized by heading braces or the like where the importance increasing factors may vary as a function of heading level (n) and/or as a function of how many style modifiers are applied to the content.
- Treatment of probably uninformative Web Page content formatting codes: As known to those skilled in HTML or other web page defining languages, certain content may be embraced between formatting codes calling for rudimentary bolding or in italicizing of such content. This does not routinely mean the content is important. As such, in one embodiment, no adjustments are made to the weight of such routinely formatted content.
- Adaptive Learning: As users interact with the match-making and invitations-generating system (MM-IGS), automated trend tracking services of the MM-IGS will keep track of the invitations which the users accept and of the CFi data streams and weights attached thereto that led to successfully accepted invitations as well as perhaps to positive interaction with the respective chat room. Positive feedback scores will be generated for successfully accepted invitations and the respective ways in which their CFi data streams were processed by the system. Negative feedback scores will be generated for declined invitations and the respective ways in which their CFi data streams were processed by the system; particularly if the CFi processing had resulted in giving a relatively high match score to the target chat room. (It is more understandable why a user may have declined a lower scored match and thus no negative feedback will be generated for such.) Over time, success and failure patterns will emerge. These feedback patterns can be used to automatically adjust how the stream of CFi values uploaded from the client machines are later processed (e.g., what importance enhancing weights are attached to certain kinds, how CFi data spread over time is grouped together, which re-scoring algorithms are applied, and so forth). Here is an example regarding a user who is interested in soccer:
The CFi stream received from the user's client machine contains the headlined or otherwise emphasized content words: “Football”, “Referee”, and “Gialloblu” (where the latter is a nickname of an Italian soccer team in Parma). In response the match-making and invitations-generating system (MM-IGS) produces a plurality of chat opportunities which are returned to the user's client machine in the form of several highly-scored invitations. The user accepts a particular one of the offerings. The accepted invitation is to a chat room that not only strongly correlates with “Football”, “Referee”, and “Gialloblu”, but also with additional keywords, “Soccer” and “Parma”. (These associated keywords may be stored in region 465a for example of the node (e.g., 460 of
Football submit count=1
Soccer hit count=1
Parma hit count=1
Referee submit count=1
Soccer hit count=1
Parma hit count=1
Gialloblu submit count=1
Soccer hit count=1
Parma hit count=1
Later the same user's client machine submits a CFi stream containing the headlined or otherwise emphasized content words: “Football”, “Contract”, and “Cagni” (where the latter is a manager of an Italian soccer team in Empoli). Once again, the match-making and invitations-generating system (MM-IGS) produces a plurality of chat opportunities which are returned to the user's client machine in the form of several highly-scored invitations. The user accepts a particular one of the offerings. The accepted invitation is to a chat room that not only strongly correlates with “Football”, “Contract”, and “Cagni” but also with additional node-supplied keywords, “Soccer” and “Empoli”. The system will now update its database entries so they appear as follows:
Football submit count=2
Soccer hit count=2
Empoli hit count=1
Contract submit count=1
Soccer hit count=1
Empoli hit count=1
Cagni submit count=1
Soccer hit count=1
Empoli hit count=1
As can be seen, the correlation for this user between the Football submit count and the Soccer hit count has strengthened (2 for 2). Assume that as this same user continues to interact with MM-IGS, the submit counts for “Football” keep going up and corresponding hit counts for “Soccer” continue to increase in pace. The higher the number of submits is and the closer the Hits/Submits ratio is to one, the greater is the associated correlation between the content word Football and the keyword Soccer for this user. Note: in this section that submit counts are referring to CFi content values submitted by user which also resulted in acceptance by the user of a corresponding chat invitation. CFi values submitted by clients that do not result in invitation acceptance, or even in a sending out of a chat invitation may still be tracked elsewhere as part of the trending data tracking process but they are not relevant to this Hits/Submits correlation feature.
By automatically keeping track of the Hits/Submits numerators and denominators for each user (or premium user), the match-making system will be able to implement the following additional rules:
Low hit count numbers below a predefined threshold are deemed to be irrelevant and thus meaningless. For example the 1/1 association between “Contract” and “Empoli” is weak for this user and therefore it will be ignored.
Hit counts are deemed to become more significant once they pass beyond one or more successive threshold settings. When this happens the correlation between the hit term (e.g., Soccer) and the submitted data point (e.g., Football) will be automatically added to a corresponding strong correlations list maintained for the respective user.
After a sufficiently strong Hits/Submits correlation is added to a correlations list of same strength correlations maintained for the user, each time the Submit word appears in a CFi input stream from the client's machine, the not-submitted but cross-correlated Hit word (e.g., Soccer) will be automatically added to the search terms that the domain lookup process uses. Since the domain lookup process now has a larger list of different match terms, the likelihood is increased that a found chat room will more accurately reflect what the user has in mind. In other words, by tracking Hits/Submits for this user, the system over time learns to map the user's preferred terminology of “Football” for what the broader system node mappings refer to as “Soccer”. Thus even if this particular user tends to employ less common words or phrases for the topics he has in mind, the system over time automatically learns about the user's word choice preferences and adapts.
In one embodiment, an importance enhancing weight applied to the added Hit term is a function of its Hits/Submits ratio. For example, if the user has 5 hits on “Soccer” in response to submitting “Football” 10 times, the added hit term “Soccer” would have its importance weight factored as: (“football weight”*5/10). This type of weighting will ensure that more significant Hit terms are given greater weighting than less well correlated Hit terms.
Note that within this process, the client submitted match word (e.g., “Football”) will not be removed from the list of to-be-matched words. In other words, the client submitted data value (“Football”) will not be translated into its cross-correlated system-common term (e.g., “Soccer’). Rather, the list of to-be-matched words is being expanded in accordance with the trend-produced cross-correlations. By using this non-translative technique, it is ensured that the original user-submitted hint values continue to get through and generate directly associated chat opportunities. For example if this same user became interested in the American football team, the Dallas Cowboys™ and submitted CFi hint values “Football” and “Cowboys” the to-be-matched words list would be automatically expanded to “Football”, “Cowboys” and “Soccer”. This submission would likely result in chat opportunities regarding soccer teams associated with the name “Cowboys” but it will also likely produce chat opportunities regarding the Dallas Cowboys™ as well and the user may then pick from this expanded set of results the chat opportunity that best reflects his current topic of interest.
In summary, by expanding the list of to-be-matched terms in this non-translative way and weighting expansion terms according to observed Hits/Submits usage patterns, the system is able to dynamically adapt to each individual user's style of interacting with the system. The user will not have to learn to type “soccer” when they are thinking about English “football”. Instead, the system will adaptively learn that this user is often referring to “soccer” when they submit “football”.
Different scoring techniques for rating domains and/or topics: Referring to step 424a of
Here is one possible score generation and score assessment technique:
Scoring Technique Step 1: Add or multiply the computed importance enhancing or importance lowering weight for each term in the list of to-be-matched terms (e.g., including “Football” and “Soccer”), process the weighted list against each of the N′ domain nodes under consideration and normalize the returned match value by dividing by the number of total terms in the compiled to-be-matched list so that to-be-matched lists with more terms in them do not get an unfair advantage over competing to-be-matched lists which happen to have fewer terms in them. In one embodiment, the returned match value is a function of a sum of match subtotals found for each term alone where the subtotals are multiplied by their respective importance enhancing or importance lowering weights and then added together, thus giving long-winded to-be-matched lists a competitive advantage over shorter lists.
Example: If the compiled list of to-be-matched terms (e.g., including “Football” and “Soccer”) contains 10 values, each with an importance weight of 1, out of which 5 of the list's values match 5 out of the total of 15 of the domain node's matchable terms, then the matched to number-in-list ratio is 5 out of 10, or 50%. Another list of to-be-matched terms may have 4 terms and all four terms match a prospective domain node, in which case the matched to number-in-list ratio is 4 out of 4, or 100%. However this need not be the only score comparing factor. The second node may have had a total of 20 domain node matchable terms, in which case the matched to matchable ratio is 4/20 or 20%. On the other hand, for the first node, the matched to matchable ratio was 5/15 or 33%, which is higher. How these different ratios are treated in the final analysis can vary from system to system. In one embodiment, the respective matched to matchable and matched to number-in-list ratios are added to thereby give the first node a score of 50%+33% or 83 (not a percentage) and to give the second node a score of 100%+20% or 120 (not a percentage). In this case the match between the second list and the second node is rated higher than the match between the first list and the first node.
MORE HYPOTHETICAL EXAMPLES Example 1A grouped set of CFi-contained content samples consists of 10 data samples (to continue with the rating example immediately above) is submitted to the match-making and invitations-generating system (MM-IGS) because the corresponding user (Sam) just interacted with a popular web portal home page (e.g., MSN.com™ or Yahoo.com™). The 10 data samples include the web page's URL and meta-tags extracted from the web page's HTML source code. Because such portal web pages have been determined by the MM-IGS to be commonly accessed as a user's default home page by large populations of users, the MM-IGS lists the URL's and/or attributes of such portal web pages in a to-be-ignored list stored within the MM-IGS. In one embodiment, the MM-IGS automatically assigns a 0 importance weight to URL's listed in the to-be-ignored list and a 0 importance weight to the CFi-contained content samples that are grouped to such URL's. In general users will not be paying any particular attention to content on their default home page even if they stare at them for a long time, and since 0 importance weights are automatically assigned to the correspondingly uploaded CFi's, no domain lookup or rating resources will be wasted and therefore no attempt at creating chat opportunity matches will occur. Of course, there can be exceptions where specific users do want match-making to occur for their default home pages. These exceptions can be handled by specialized DsCCp knowledge-base rules that, for example, translate a to-be-ignored URL string into a not-to-be-ignored alias which the system recognizes as such.
Example 2The same user as in above hypothetical Example 1 opens and stares at another web page whose URL is not listed on the to-be-ignored list. Once again this user activity produces a grouped set of CFi-contained content samples consists of 10 data samples including the new URL value. Since the URL is not on the to-be-ignored list, the MM-IGS does not automatically assign zero importance weights to the associated 9 other data samples, they retain their original weights (e.g., a default weighting of 1) or are upgraded or downgraded in importance by appropriate weight adjustment rules (e.g., if content was braced inside heading tags) and the non-zero-weighted CFi-provided data samples are forwarded to the domain lookup process for further processing.
Example 3After opening the non-portal second web page, this same user initiates a web search about 3 minutes later by entering 3 search terms. The user's PEEP record indicates that such follow up activity within 5 minutes of having opened a non-portal page normally indicates strong topic cross-correlation between the earlier opening of the web non-portal page and the current search keywords. In other words, the earlier grouped set of CFi-contained content samples consisting of 10 data samples including the second URL value are to now be cross-correlated with the 3 new search keywords when performing domain lookup. Because the user explicitly entered the 3 new search keywords (as opposed to other hint data which was obtained by benign spyware without the user's direct participation), the match-making system automatically assigns higher weights to the 3 new search keywords and then concatenates them to the earlier weighted 10 data samples. The concatenated combination is them passed to the domain lookup process for further processing. In summary, these examples show how domain lookups are differently handled based on whether reference was made to a common or default home page URL whose associated sample points are scored low because the user is inferred to be not paying actual attention to them even if it seems he is and based on whether the user explicitly participated in generation of some of the content samples, in which case the explicitly generated sample points are given comparatively higher weights than sample points that are automatically gathered by the benign spyware. Note therefore that some types of CFi-provided sample values (e.g., keyword terms entered explicitly by the user as search criteria) may be automatically assigned more of an importance for scoring likely sameness of topic than other types of CFi values (e.g., those that were inferred from the URL and/or content the user is interacting with). In one embodiment, a neural network type of weighting or statistical classifying method is used for adaptively learning through experience with the user (e.g., from getting survey feedback from the user as to how well the system is providing appropriately matching invitations) what weighting factors should be applied to different kinds of CF-provided sample points. In one embodiment, a knowledge-base rules set may be stored for each user containing respective rules for handling that user's CFi-provided sample values, including what importance weight is to be attributed to each type of CFi parameter for the specific user or for general user population which the specific user belongs to.
In one alternate embodiment, certain URL's are predefined in the user's client machine to be blind spots (to-be-ignored URL's) for which matching is to be temporarily turned off without disconnecting from the AARMS service. In an alternative or supplemental version certain URL's are predefined in the user's client machine to be automatically weighted down (damped down) focus areas so that matches are not found and invitations are not sent unless something of unusually high interest appears on such damped down, prespecified web pages. Weighting down can be performed in the client machine before the CFi is sent out or at the cloud end after the CFi is received, or in both places. In other words, although parts of this disclosure may seem to imply that most of the data processing should be conducted in the cloud 150, it is within the contemplation of the disclosure to offload some of the work on the local client machine if that client machine has the bandwidth to handle the work. In one embodiment, the machine-implemented task of performing trending data analysis for respective users is offloaded from the cloud to the client machines of the respective users (software and data is typically downloaded in encrypted form to protect user privacy) when it is determined that the user machine is basically idle. Users who agree to letting their local machines be used for such distributed offloading of the cloud's processing chores may be rewarded with reduced subscription rates and/or special privileges. As already mentioned above, parsing and grouping of CFi data stream items may also be partially or fully handled locally by the user's client machine(s).
After the domain lookup process scores competing domain nodes for topic matching and/or scores competing topic nodes under the higher scoring domains for topic matching and so on; the higher scoring ones of the matched topic nodes (or domain nodes) are assigned with the task of finding the most co-compatible chat rooms under those nodes for the given user. (To be more precise, after the DLUX service identifies the better matching topic nodes, it sends requests to the corresponding DsMS modules in charge of the corresponding matched nodes to find the chat rooms under those nodes that are most co-compatible for the given user.) When it searches for an appropriate chat room, a DsMS may conclude that no currently occupied room qualifies and yet, on the other hand, there are a number of floating users who currently are co-compatible and should be clustered into their own room. In such a case the DsMS automatically requests creation of such a room and sends out invitations to that room for the co-compatible floating users.
Just because a DsMS finds a matching chat room, that does not automatically mean however, that an invitation will be issued for that chat room. The controlling DLUX may send instructions regarding minimum scoring requirements for issuing a corresponding invitation. The minimum matching score requirement(s) passed in from the DLUX to its supervised DsMS resource(s) may be adjusted up or down based on:
The current number of clients already participating in the chat rooms hosted under the specified domain or other node. If the number of clients is low then the minimum score requirement may be reduced in order to increase the likelihood of issuing more invitations. Conversely, if all the rooms are crowded, the minimum score requirement may be automatically increased in order to thereby reduce the likelihood of issuing more invitations unless it is a really good match for the respective user.
The total number of clients that have recently submitted CFi's directed to the specified domain or other node. If the number of such clients is relatively low (e.g., as compared to historical norms) then the minimum score requirement may be reduced in order to increase the likelihood of issuing more invitations and thus pulling in more participants into those chat rooms. Conversely, if the total number of clients that have recently submitted CFi's directed to the specified domain or other node is large (e.g., as compared to historical norms) then it is likely that many will be determined to be good matches. In such a case, the minimum score requirement may be responsively increased on an automatic basis in order to decrease the likelihood of issuing more invitations and thus throttle back on the number of new participants that will be pulled into those chat rooms.
The current workload of the DsMS resources associated with the specified domain or other node. If the load is heavy then the score may be responsively increased on an automatic basis in order to decrease the likelihood of issuing more invitations and thus throttling back on the number of new participants that will be pulled into the chat rooms whose DsMS resources are currently overburdened.
The workload on the CRS resources assigned to this DsMS. If the CRS work load is heavy, meaning that many users are not just watching but also participating in the chat room in a more burdensome way, the minimum score requirement may be responsively increased on an automatic basis in order to decrease the likelihood of issuing more invitations and thus throttle back on the number of new participants that will be pulled into those chat rooms whose CRS resources are overburdened at the moment.
In one embodiment, scores for automatically deciding whether or not to issue an invitation are determined based on:
The degree of matching or correlation between the CFi, CpCCp, and DsCCp attributes of the incoming user versus those of other clients already in the chat room that has been created for the domain or other node specified by the controlling DLUX;
The degree of matching or correlation between the CFi, CpCCp, and DsCCp attributes of the incoming user versus those of other clients who have been already blocked from receiving invitations for specific chat room. In other words, if the incoming user (the one with the now being processed CFi's) better matches with others who are outside the chat room rather than in it, then an automated decision can be made to create a new node with its own chat rooms and to invite the outsiders (the outsiders who closely correlate to one another but not to the insiders) into the chat rooms of that newly created node.
The degree of matching or correlation between the CFi, CpCCp, and DsCCp attributes of the incoming user versus those of other clients who have been already assigned to a preexisting “catch all” node. In other words, if the incoming user (the one with the now being processed CFi's) better matches with others who are inside a catch all room rather than inside the rooms of the currently specified DsMS, then an automated decision can be made to invite the incoming user into the catch all room rather than inside the rooms of the currently specified DsMS. If the participant population of the catch all room grows beyond a predefined threshold, then the system automatically creates a specific node in the hierarchy for that room. Whether a catch all room evolves into being a special interest room depends on the population of users currently using that room and the historical growth trends of that room. In one embodiment, the system cleaves a catch all or general purpose room into two, retaining some participants as general purpose ones and moving others into the special interest room based on historical trends seen for similar rooms in other data centers. In other words, if a new conversation is taking root across a geographical area and spreading geographically like wildfire, the system can automatically detect this as the new conversation takes root in the general purpose rooms (because a special interest topic did not previously exist for that new conversation) and the system can begin to proactively create the corresponding special interest nodes in data centers of other geographic areas even before users there begin to flood the general purpose rooms in those other data centers;
The degree of matching or correlation between only the CFi and CpCCp, but not the DsCCp attributes of the incoming user versus the same profiles of other clients who have recently submitted non-domain specific CFi's and are not yet in any chat room because there is no topic specific chat room that matches for them, in which case the system automatically creates a new general room for these personality co-compatibility new users.
In one embodiment, the invitation issuance scores are determined using a method similar to the one the DLUX's use when rating domains or other nodes for co-compatibility with an incoming CFi. In this method, goodness values for different aspects (i.e. CFi data types and the percentage of matches, or CpCCp/DsCCp attributes) may have different compatibility percentages calculated for them for determining if an invitation should issue. Each percentage is weighted, based on importance level, and then a total rating is derived based on the individual percentages and their associated weights. Note: in a variation on the scoring mentioned above, the invitation scores are automatically relayed to the client machine and displayed to the user as basis for determining whether to join. Note: in a variation on the scoring mentioned above, the invitation scores are automatically cross linked with other chat room invitations having same or similar scores and these are displayed to the user as “related chat opportunities” after the user has joined one of the so-interrelated chat rooms. In this case:
Instead of identifying “related chat opportunities” based only on the domain or topic node of the invitation issuing DsMS and its position in the domain/topic hierarchy, the offered other matches will be based on the closeness of invitation scores. In one embodiment, a first set of chat opportunities that meet the chat opportunity minimum matching score requirement and don't result in exceeding the chat opportunity target count are returned to the client machine as chat room opportunity recommendations. The degree of recommendation may be included in the Cciv's returned to the client.
As indicated in step 425b of
Per Node step 1: Identify the DsMS resource or resources best suited to find matching chat rooms for this client's CFi values and based on this client's CpCCp and DsCCp's. The chosen DsMS resource may be in the local data center or it may be a remote one in one of the other data centers. When choosing the DsMS, the DLUX controller may: (a) Give priority to DsMS resources assigned to local instances of the matched node (e.g., matched domain) and thus to local chat rooms running under that node; (b) If there are no local DsMS resources available and assigned to the specified node, the DLUX controller (or its supervising AARMS) may look for available remote DsMS resources assigned to the same hierarchy point (e.g., domain/topic/subtopic/etc.) but located in other data centers and thus controlled by other AARMS's; (c) If there are no local or remote DsMS resources available and assigned to the specified node, then the DLUX controller (or its supervising AARMS) may request creation of a local or remote DsMS resource for servicing the not-covered node and thereafter pass the room finding job to that new DsMS instance.
Per Node step 2: After identifying the one or more corresponding DsMS resources, the DLUX controller forwards the client's CFi values to the identified DsMS resources for processing together with the client's CpCCp and DsCCp profiles.
Per Node step 3: Upon sending the task(s) out to the identified DsMS resource(s), the DLUX controller establishes a return thread which will receive the chat opportunity matches if any found by the DsMS resources. Upon receiving the chat opportunity matches (step 426a), the DLUX controller keeps count of the total number of chat opportunities found thus far from the DsMS resources contacted thus far and tests to see if the target number has been reached (and/or if target quality numbers have been reached). The DLUX controller also keeps count of the time consumed in looking for matches and/or the number of resources consumed.
Per Node step 4: The DLUX controller stops looking for more matched chat opportunities once the chat opportunity target count has been reached or once a predefined resource consumption limit has been reached in terms of time and/or bandwidth times time. By starting with the highest rated nodes and stopping once the target count is met, the DLUX will usually present the CFi sourcing client with the best quality chat opportunities that could be found given the allotted resources. Of course, other techniques for increasing likelihood of finding good matches may be used and there can be a point where match scores are good enough and do not have to be refined to being more accurate. Moreover the same concept of good enough applies to the room matching tasks of the DsMS's. They do not have to find the best matching (e.g., in terms of personality co-compatibility) room for every user. There is a point where good enough is good enough. More specifically, assume that there are 100 chat rooms under the node picked by the DLUX service. The DsMS assigned to the task of finding the best matching room might try and survey all 100 rooms. However in many cases; especially those where room characteristics of the 100 rooms substantially conforms to a Poisson distribution, the DsMS surveys only the first 37% of the large number (e.g., 100) of potential rooms. The DsMS identifies the highest scoring room among the initially surveyed 37%. Then the DsMS starts scoring through the remaining 63%. However, on the first instance where the DsMS encounters a room whose scores beats the highest score in the initial 37%, the DsMS stops and picks that next higher scoring room as the winner. It does not always have to (if time permits) step through all 100% of the available samples. On average this method generally locates good enough matches. In other words, various statistical functions may be used to increase the chances of locating good enough matches for the client from among a set of matches without necessarily sending back invitations for all found matches. The statistics used for sampling from among all found matches may be a distribution that is adaptively learned for different user populations based on geography, education, etc.
Per Node step 5: During its searching for hierarchy nodes having characteristics matching those sought by a given one or more CFi's, it is possible that the DLUX will not find any hierarchy node correlating well to the CFi values or that DLUX will not find a sufficient number of hierarchy nodes correlating well to the CFi values so as to achieve the chat opportunity target count. When this happens, the DLUX defaults to a catch-all node either under a best guess domain or to a catch-all domain node (not explicitly shown in
Send the client CFi values to a local DsMS resource hosting a “catch all” node (e.g., catch-all domain) and the catch-all DsMS will make a best guess match for a co-compatible chat room based on personality (CpCCp) and on commonality or similarity of focused-upon content. The DsCCp's cannot be used because there is no topic co-compatibility to match for. The catch-all DsMS will respond with any chat opportunity matches found to have personality based co-compatibility (CpCCp) and optionally sameness or similarity of focused-upon content.
If this still fails to produce the chat opportunity target count, the local DLUX will send the client CFi values to one or more remote DsMS resources belonging to other AARMS instances that are hosting a “catch all” node. The remote DsMS resources may then respond with any chat opportunity matches found.
Referring again to
Chat Room Step 1. Each AARMS monitors the activity levels of the Chat Room Services (CRS) assigned to it. If an AARMS determines that a chat room is becoming overloaded due to too many users and/or to many contributions, it may take the below steps to ease the load on the CRS.
Chat Room Step 2. The AARMS will identify the CRS resources to which its DsMS's have been sending out invitations for and those that have not been directed to by sent out invitations. This done by:
Chat Room Step 2a. Looking for any Chat Room Services the AARMS's supervised pool of CRS's (e.g., 418) which have not been assigned to a corresponding DsMS. If one is found, it will be assigned to the DsMS whose current CRS resources are being overtaxed. The DsMS will then begin sending out invitations for chat rooms in the underloaded new CRS resource(s) rather than for chat rooms in the overloaded CRS resource(s) and overloading trends for the overloaded CRS resource(s) will thus be alleviated.
Chat Room Step 2b. The AARMS also tries to alleviate overloaded CRS resource(s) by looking for one or more DsMS resources that are not currently sending out a full load of invitations and thus probably have underused CRS resources. If such lightly loaded DsMS resources is/are found, the CRS resource(s) of those lightly loaded DsMS's will be reassigned to the heavily loaded DsMS which is in need of additional CRS resources and the heavily loaded DsMS will be instructed to start sending out invitations for chat rooms in the newly added CRS resource.
Chat Room Step 2c. The AARMS also tries to alleviate overloaded CRS resource(s) by looking for one or more DsMS resources that currently have multiple CRS resources each operating beneath its maximum workload thresholds. If this is found, workload form the CRS with the lightest workload will be reassigned to others of the multiple CRS resources and the thus freed CRS resource is then reassigned to the heavily loaded DsMS.
Chat Room Step 2d. The AARMS also tries to alleviate overloaded CRS resource(s) by looking for other AARMS instances that have CRS resources available for transfer to this AARMS and requesting transfer of the free resources to itself.
Chat Room Step 3. If the AARMS that supervises the overloaded CRS resources cannot find additional CRS resources to offload the work to, the DsMS using the heavily loaded CRS will be instructed to decrease the load on its CRS resources (to throttle down) by reducing the target number of offered new chat invitations (see steps 421-422 of
Referring to the UAS resource 412 of
Further aspects of the UAS may include: (e) Automated collecting of fees for charges like access to premium features and/or enhancement of profile credentials. Such automated collections may be done via credit card or other online collection means: (a) When the account is being created; (b) When a user-requested upgrade to an existing account is made; and (c) On a recurring basis for a corresponding automatically renewed account subscription. Further aspects of the UAS may include: (f) Validating a user's login credentials (e.g., including for example by using biometric data to validate identity biometrically) and determining the user's subscription level (i.e. free guest, normal, and premium) for each login session.
Access to User Account Data Store data can be made available via the data center backbone and through the communications firewall 419 so that: (a) Client software can interact with the UADS (e.g., 432) in order to support account creation, maintenance, and upgrades through actions taken by the client software (105) running on the user's computer; (b) A web-based application can interact with the UADS (e.g., 432) in order to support online account creation and maintenance—This would let a person create and purchase an account without having physical access to the user's computer, for example, a relative may buy a subscription as a birthday gift for the new user; (c) Besides the UAS, other data center services (e.g., 411, 415-418) may access the UADS (e.g., 432) for the purpose of: (c1) Validating a user's login credentials and determining the user's current subscription level; (c2) Saving changes to a user's CpCCp and/or DsCCp settings. In one embodiment, all access to the UADS (e.g., 432) is via the corresponding UAS 412 in accordance with a service-orientated architecture (SOA). In one embodiment, UADSs data changes are replicated to other data centers on a more or less real-time basis. This way, if as a user's activity is passed from center to center, or a center goes off line, users will have access to all the services to which they are entitled. In an alternate embodiment, the system may implement a Home center signature process which allows one center to query another for a user's credentials. the latter approach might be subject to failure however if a user's home center is off line.
Intermixed with the various interactions between client machines and services provided from the distributed data centers, the system may include further controls for managing communications between the various client machines (e.g., 440) and the cloud 150. These communications managing modules may be connected to the public network 430 and may provide secured or unsecured instructions or recommendations as appropriate. Such instructions or recommendations may be responded to by the client machine upon client start up if the client is not currently turned on and connected to the system. Some of the various types of communication instructions that may be sent are:
(a) Informing a client machine of the identity of an AARMS which the client should access in order to have that AARMS determine which DLUX will be receiving CFi's from that client machine (either directly or through the AARMS). This informational communication may occur when a first AARMS has instructed an overloaded DLUX or one trending towards overload to transfer some of its clients to a different AARMS for purposes of load balancing. In this case the transferred client machines need to be told of the transfer.
(b) Informing a client machine that it needs to reestablish connection with its default AARMS in order to have a new DLUX assigned for that client. This may occur if the client does not have CpCCp or DsCCp file values that match well with a current DLUX assigned for that client and thus the corresponding DsMS resources are having a difficult time finding co-compatible chat rooms for the client. In such a case, the current DLUX or DsMS resources communicate the problem to the communications managing modules via the backbone and the latter then send the “return to your default AARMS” message to the client machine.
(c) Providing rules for generating the next one or more CFi submissions from the client machine to its associated AARMS or to its assigned DLUX. By defining these rules, the associated AARMS and/or assigned DLUX can control the client CFi submission rates and/or submitted CFi content. This may be used to help achieve a balance between server load levels and performance. For example:
(c.1) If the assigned DLUX has lots of bandwidth and is nonetheless finding few well-matching nodes per unit of time for the incoming CFi's, the assigned DLUX may instruct the client to send more CFi's in at shorter intervals so as to increase the richness of matching information and increase the chance of finding good matches.
(c.2) If the assigned DLUX is running within its normal bandwidth range, it can instruct the client to not submit CFi's whose priorities fall below a minimum specified importance rating at least for a prespecified time interval. This can work to help filter out noise from low priority CFi's and allow the well loaded DLUX to focus its efforts on higher priority CFi's.
(c.3) If the assigned DLUX is heavily loaded, it can further throttle the number of CFi's it is getting from its assigned clients by:
-
- (c.3a) Communicating a maximum number of CFi's to submit per client machine per specified unit of time;
- (c.3b) Communicating an extended interval between CFi submissions so as to thereby reduce number of CFi's received per unit of time.
- (c.3c) Communicating a set of limited types of CFi's that are to be submitted in an upcoming time period. For example the assigned DLUX or AARMS may instruct one or more of its clients to submit only explicit CFi's (i.e. ones containing user entered search request key words) and to not submit inferred CFi's (i.e. ones based only on biometrics) during an upcoming time period. This may help to throttle down the number of CFi's the AARMS and/or its supervised DLUX's need to process in the specified time period. The AARMS and/or its supervised DLUX's may use these forms of submission throttling to help mitigate DsMS or CRS overloads within a datacenter whose performance is being monitored by the AARMS.
- (c.3d) Additionally, if CFI submission throttling is needed, the DLUX or AARMS that receives them, may choose to interspersingly or periodically ignore one or more CFi submissions per unit of time from one or more identified clients. For example, certain nonpremium clients may be identified as stressing the system more than other nonpremium clients and these identified clients may be targeted for occasional interspersed ignoring of their CFi's. In some instances it may be necessary to cut back of CFi recognition even for premium clients. When this occurs, the detected fact that a client (premium or standard service) has not been issued any recent Cciv's may result in giving that client elevated priority the next time its CFi's are processed. See for example step 422 of
FIG. 4C .
Hypothetical walkthrough of a transaction between client machine 115 and cloud 150 (
User 111 launches a web search engine in another area of his screen and types the search terms: “Beckham respects referee” shortly after having focused on the news article about soccer. In response, client machine 115 generates a CFi (215a-215i of
Also in this hypothetical example, the local matching service resources (e.g., in data center 410) are operating well within their load handling capabilities so that there will not be a need to re-adjust the match threshold for purposes of load management. The CFi having the Sports/Soccer hint and the related URL and the keywords is posted onto client buffer 215 (
Since the root domain (Sports) and child topic node (Soccer) are already firmly established, the AARMS will not forward the pulled CFi to a catch-all DLUX that handles ambiguous catch-all CFi's. Instead the job goes to a DLUX that specializes in further categorizing CFi's that are directed to the Sports/Soccer node so as to narrow the choice among invitations to specialized ones under the Sports/Soccer topic node. The Sports/Soccer DLUX locates in the user's fetched CpCCp file and fetched DsCCp files an indication that 75% of the time when this user uses the keyword, “referee”, the user is implicitly also interested in the subtopic of “fairness” of different referees. Therefore, the combination of the CFi and the user's preference profiles is used to automatically expand on the probable topic that the user has in his head, for example, [Does famous player] “Beckham” [believe that] “referee” named X [is fair} and therefore deserves “respect”?. The DLUX scores this expanded and more focused topic as having a 60% chance of being correct based on user 111's current mood (inferred mood, i.e., from current surroundings) and the corresponding current CpCCp and DsCCp files. Incidentally, in one embodiment, when CpCCp data conflicts with. DsCCp data and topic is firmly established, the more topic specific DsCCp data is automatically taken as overriding the more general (not topic specific) data. For example user 111 may have a CpCCp file that indicates he generally likes peaceful discussions with small groups of middle aged people. However, his Sports/Soccer DsCCp file indicates that when it comes to this topic, user 111 welcomes heated debates with large audiences of young people because user 111 believes that on-field behavior by players and referees is important for teaching young people how to behave correctly in other aspects of life. From this Sports/Soccer DsCCp file, the DLUX (or DsMS) pulls co-compatibility information indicating that user 111 would most welcome an invitation to chat room filled with young soccer fans who believe that players should play rough and cheat whereas user 111 wishes to heatedly argue the counterpoint. Armed with all this information, the DLUX (or DsMS) can look for a matching chat room whose detailed aspects are substantially more refined than what could have been inferred from just the CFi taken alone. Accordingly, there is a good chance that user 111 will be pleasantly surprised when the match-making system invites him into a chat room filled with young people who have been reading the same article in the same newspaper and are of a belief that the referee (named X) deserves no respect. Now user 111 has a real time interaction of precisely the kind he has been aching for. The just-read newspaper article is no longer a dead inscription on a gray tombstone; it comes to life as a hot headed mob of youngsters to whom user 111 can argue his position (assuming they too are in a mood for heated debate, which is what their CpCCp's or DsCCp's indicate).
Of course during processing of any latent CFi data stream (e.g., the one above where child topic node of Soccer was established), it is possible that the user; while in the middle of thinking about one topic (e.g., Soccer), suddenly switches topics in his mind (e.g., because the sports site reminded him of something else) and then the subsequent web search may have not have been sports related at all. The user might just as easily gone from reading about sports to thinking about uniforms, his dirty laundry, the price of starch, and doing a Google™ search on a company that makes starch he is considering investing in. In that case the assumption made by DLUX specializing in sports, that the user is continuing under this topic, is not helpful. In one embodiment, alternate possibilities are routinely considered in parallel. One DLUX assumes the old topic is being continued and one or more other DLUX's are tasked with assuming that completely different domains or topics are being considered based on recent CFi input. If the client, or AARMS, explicitly specifies that only a single domain tree or region in topic space should be used then lots of potentially better matches will not be found then if the DLUX's start from an assumption that a totally new domain is possible for recent CFi input.
More generally, given the expanded information that the DLUX derives for a first user (e.g., 111) based on his CFi combined with his CpCCp and/or DsCCp, the DLUX automatically searches for potential chat partners and/or potential chat rooms whose similarly expanded topic definitions correlate well with those of the first user. As each new client enters a given chat room, the CFi values that prompted the match will get added to the set of CFi values more generically associated with the chat room. Thus chat room profiles evolve according to the clients that enter or leave that chat room. Additionally, in one embodiment, chat room contents are automatically monitored to detect what words or phrases are most often repeated. If CFi values associated with the majority population in the room are used repeatedly in the associated CFi's then they can be deemed to be on-topic common words or phrases and recorded as such for the associated room and/or for the associated topic node. In other words, since they are common to the users of that chat room) they are automatically added to the list of CFi values associated with this specific chat room. These actions allow the “personality” of a chat room to build and change over time; as different people enter or leave the room the topic under discussion evolves from one major issue to another. For example, there may be many simultaneous chats occurring under the major domain/topic of Sports/Soccer. However, one might be about the best equipment for amateur players to use while another may be about organizing little league teams. Yet another may have been started based on two people reading the same review of a player's (David Beckham) performance in a recent game and a third about statements David Beckham made off the field about referee fairness. As other people joined this chat it turned into an argument about the incompetence of some referees and whether they nonetheless deserve “respect”. This evolved chat room would be categorized under the major domain/topic nodes of Sports/Soccer and furthermore under a more specific node such as Sports/Soccer/referee/fairness. A well operating DLUX would logically connect user 111's CFi of the above example with this latter node rather than the other nodes.
In one embodiment, for each chat room that is being categorized by a domain specializing DLUX unit, the CpCCp and DsCCp values for each of the chat room participants that enters that watched chat room will be: (a) Combined following the same rules that were used when the DLUX combined a single user's CpCCp and DsCCp values to form an expanded topic definition; and (b) Averaged so that there are overall averaged values for the rules-wise combined CpCCp and DsCCp attribute values for the given chat room. For each incoming new user and a potentially matching chat room, the DLUX computes a match score based on the averaged chat room characteristics versus the new user's preferences and expanded topic definition. In one embodiment, a score of 0 indicates a bad match and a score of 100 indicates a great match. In the given hypothetical example the chat room discussing whether referees acted fairly receives a good match score because there were strong keyword matches to the terms: “Beckham”, “respect “referee” as well as to the expansion derived keyword, “fairness”. The Chat room discussing the best equipment to use did not score as well because there were lacks of matching on the primary keywords.
More generally, a chat room match score is calculated by the responsible DLUX for each of the possible chat rooms under consideration by assigning match value to various aspects of the chat room topic based on the clients' topic preference profile. Thereafter, the assigned DsMS narrows the list of potential chat rooms to which the first user (e.g., 111) might be invited based on personality considerations. Aspects that may be considered include: (a) The number of people already in the chat room; (b) The conversation tone (i.e. peaceful versus heated debate) where the latter may be determined based on participant supplied votes (supplied via their Cvi's 118b where the votes are either explicitly stated or inferred from the biometric feedback data). The conversation tone may also be determined based on detection of keywords or phrases within the chat conversations that indicate tone. Each topic and personality co-compatibility aspect will be given a value based on comparing the client's preference to the chat room's state. The values from each of the evaluated aspects are then combined to produce a chat room match score. A score of say, 50 may represent a neutral outcome while a score of 0 may indicate a bad match and a score of 100 may indicate a great match for the user who is potentially to be invited into the given room.
In one embodiment, chat room match scores are calculated as follows: (a) A neutral starting score of say, 50 is (assumed; (b) The DsMS will compare each of the DLUX supplied client's CpCCp or DsCCp preference's (i.e. level of topic proficiency or expertise) to a corresponding average of the chat room's current participants. Favorable comparisons (i.e. the average age of the participants in the chat room matches, or is close to, the age preference stated by the DLUX supplied data) will increase the sequentially adjusted score. Unfavorable comparisons will decrease the score; (c) The calculated match score may also be adjusted up or down based on individuals in the chat room, for example, if the client has indicated that they never want to chat with a specific individual who happens to be inside the chat room then the chat room match score is forced to 0. As another example, if the client has indicated a preference for chatting with a specific second individual who happens to already be inside the chat room, then the chat room match score will be increased. In one embodiment, the final score will be between 0 and 100.In this example the chat room discussing referees scored well because: (a) The DLUX specified client did not indicate a preferred domain expertise level so that aspect of the chat room profile was ignored; (b) The chat room had attracted many other participants of young age in accordance with the first user's desires as expressed in his DsCCp, so there was a positive affect on the computed match score; (c) one specific person whom the first user likes to chat with, was already inside this room resulting in the neutral score being further adjusted in a positive direction.
In some cases, numerous chat rooms may score for a positive match. In that case, the DsMS will evaluate the well matched chat rooms in the order of their scores. The chat rooms with the highest scores will be evaluated first. In this example: (a) The chat room discussing referee fairness is evaluated first, because it scored the highest. It meets the minimum threshold for the match score and so it is added to the list of potential chat opportunities to be handed back to the DLUX or sent back as an invitation directly from the DsMS; (b) If the chat opportunity target count has not yet been met, a next chat room on the list is evaluated; (c) In a case where the chat opportunity target count is not yet reached by evaluating preexisting rooms, the DsMS will look for opportunities to create matching new chat rooms by inviting in other users with similar preferences into the newly created rooms. This may be done by:
New Room Step 1: Find the list of potential chat partner clients that have recently submitted CFi's directed to the same hierarchy regions (e.g., same current domain) where the submitted CFi's are in common with some of the CFi values submitted by the DLUX expanded topic identification of the first user (e.g., 111);
New Room Step 2: For each client in the potential chat partner list, retrieve their profile settings: (a) CpCCp values will always be retrieved; (b) If the DLUX indicated a specific domain, and not the “catch all” domain, then DsCCp values will also be retrieved if any exist for that node;
New Room Step 3: For each client in the potential chat partner list, rules-based combination of CpCCp and DsCCp values will be used as the client's preferences relating to this set of CFi values; for example, when topic specific DsCCp values are found they will override generic CpCCp values.
In this following hypothetical example two potential chat partner clients have been identified. Both were selected because they had submitted the CFi value “referee” in reference to the domain/topic of Sports/Soccer.
New Room Step 4: The DsMS calculates a cross matching score for each potential chat partner client in the list against the first user. For example, a potential chat partner client CFi score will be calculated by comparing the DLUX expanded client's CFi values to the CFi values associated with the potential chat partner client from the list. In one embodiment, this will be done by using the same algorithm used to calculate domain matching scores when comparing the client's CFi's to the domain node's average CFi's. A score of 0 indicates a bad match and a score of 100 indicates an excellent match.
In this hypothetical example, one of the potential chat partner clients (Bob) CFi's consisted of only “soccer” and “referee”. This resulted in a fairly high score. On the other hand, the other potential chat partner client (Bill) CFi's consisted of “soccer, Referee” and ten other terms that did not well match the DLUX expanded topic values for the first user (111, e.g. Sam). Although the number of positive hits between the two potential chat partner clients was the same, the ten terms that did not match caused the score for this second potential chat partner to be lower.
In one embodiment, a potential chat partner client profile score is calculated as follows: (a) A starting score of 50 (neutral) is assumed; (b) The DsMS compares each of the chat room preferences (i.e. number of participants, conversation tone, etc.) declared in the CpCCp or DsCCp values for both the first user and the potential chat partner client; (c) The DsMS compares each first user's CpCCp or DsCCp preference file attributes for a chat partner (i.e. age range, level of domain expertise, etc.) to the corresponding demographic settings (i.e. Actual age, declared or verified level of domain expertise, etc.) from the potential chat partner and vise versa; (c) Favorable comparisons (e.g., declared level of expertise matches requested level of expertise) will increase the score. Unfavorable comparisons will decrease the score; (d) The calculated scores may be adjusted up or down based on dislike or like for specific individuals involved, for example, if the one user has indicated he never wants to chat with the other person then the score will be set to 0; (e) On the other hand, if either client has indicated a preference for chatting with the other person then the new chat room match score will be increased. The final score will be between 0 and 100.
In this hypothetical example the potential chat partner, Bob was on the list of individuals the first user (Sam) indicated he never wanted to chat with so their resulting cross compatibility score was 0 for the two. The other potential chat partner client Bill had no CpCCp or DsCCp values in common with the profile values supplied for the first user (Sam) so the score was left at a neutral value of 50. The CFI and profile scores will be combined to create a matching score for each potential chat partner client. In our example potential chat partner clients Bob and Bill each scored poorly in one section so neither of the matching scores was very high. The potential chat partner clients will be evaluated in the order of their scores. The potential chat partner clients with the highest scores will be evaluated first. In this example neither of the potential chat partner clients met the minimum matching score so neither was added to the list of potential chat opportunities to be handed back to the DLUX for forming a new room. Therefore the chat opportunity target count is never reached before the time out clock runs empty.
Users of the match-making system do not have to be passive receivers who merely wait around for new invitations. They can actively change the way the system is organized (e.g., how the domains hierarchy tree of
In one embodiment, any member of a first in-system chat room can request that a new second chat room be created or that a current room be cleaved or that a third room be merged in with the first room by sending a corresponding request for new room creation, cleaving or merger to the room supervising CRS. (By in-system room, what is meant here is that this room is logically linked to by at least one corresponding on-topic node of the system's hierarchy tree and also that the system has control rights over the room. It is possible to have out-of-system rooms for which the MM-IGS does not have control rights.) Part of this request may include recommending a name and description for the new or altered chat room(s). The user requesting reformation of the first room or creation of the new second chat room can also specify if the modified room is to be a public room or a private room. The supervising AARMS may be asked to get involved in grant of request process because load balancing issues may arise. Upon grant, the DsMS that is the CRS resource's parent will be notified that the new chat room has been created or one or more previous rooms have been modified (e.g., merged). If the new/modified room is a public room, the DsMS may start using that room when looking for chat room opportunity matches. If the new/modified chat room is instead designated as a private room, it can only be entered via invitations authorized by the user who initiated formation of the private room or via invitations authorized by another user who is delegated the task of controlling entry into the private room. An example of an invitation authorization might be for example, invite only outside users who have a PhD degree in advanced biophysics and who also attended an Ivy League school. The DsMS would inherit this authorization criteria into its match-making criteria when performing its match-making tasks.
In one embodiment, users of a given chat room may invite specific outsiders to join that chat room. Such invitations to join the chat room will be initiated by a request sent from the inside client to the Chat Room Service hosting the chat room. The CRS or its supervising DsMS will then pass the invitation directly to the specific outsider as a Cciv record or packet without its DLUX having received a corresponding CFi from that specific outsider. In an alternate embodiment, the CRS receiving the request will determine which AARMS is being used by the outsider client who is being invited to join the given chat room. The CRS will then pass the invitation on through the default AARMS used by the client who is being invited in. If that invited outsider is off line at the moment, the next time that client contacts his default AARMS, the AARMS will respond with the stored and awaiting invitation in the form of a Cciv.
When a newly created or user-modified chat room is a public room it: (a) May temporarily appear in the domain hierarchy tree under a node that is a child of the node pointing to original room from which the requesting user initiated the new room creation or old room(s) modification (e.g., bifurcation or merger); (b) May be used by the DsMS when looking for chat opportunities for users who have not been specifically invited into the new/modified public room; (c) May get included as a “related” chat room recommendation provided at other nodes or in other rooms.
Users within all or a system specified subset of chat rooms may perform collaborative actions. An example of this may be to set or change system stored data representing chat room settings. Some chat room settings can be defined or modified based on recommendations of the chat room users. Here are some examples: (a) A new chat room created from a user's request can have set properties such as being private or public, having a specific room name and description set by the creating user and/or can have a specific node position in the domains hierarchy tree and interrelated nodes or rooms pointing to it or it pointing to them; (b) Preexisting public chat rooms that were not locked down (i.e., not designated as unalterable because they were created to support dynamic creation of new domains and topic node or because they are part of a predefined domains hierarchy tree backbone) may be specially allocated for allowing users to meet there and collaborate on chat room names or descriptions or descriptions for other rooms. In other words, the structure of a large set of branches within the domains hierarchy tree may be debated about and agreed to in these collaboration rooms. The process might occur as follows:
A user submits a suggestion to the CRS.
This suggestion is automatically broadcast to the other users in the chat room who have agreed to weigh in on restructuring suggestions.
One or more of the other users may make alternate or supplemental suggestions.
These additional suggestions are also automatically broadcast to the other users in the chat room.
Each of the plural suggestions is voted on to reach a group consensus. The votes may be submitted in the form of Cvi's cast by users participating within the collaboration room.
As the votes are collected and a collaborative decision is reached, the AARMS, DLUX and DsMS responsible for the chat room will be automatically notified of any changes that might affect future match-making tasks.
Cvi Processing: Like the CFi's, Current Vote Indicators (Cvi's) are records or packets or other data conveying objects that are formulated and generated in one or more of the local client machines at the location where the user is interacting with one or more open chat rooms (e.g., 316a, 316b of
Implicitly or explicitly produced votes (as conveyed by the Cvi's) can be used to smooth interaction and/or collaborating with other users in various chat rooms. As mentioned above, if a majority or super majority of participants in a given chat room implicitly or explicitly express persistent negative votes on the in-chat behavior of one user (e.g., because that user is behaving like a troll), the chat room supervising service (CRS) may responsively bifurcate the room and thus separate the unwanted user from the others Also as mentioned above, voting may be used to migrate a room to being situated under a new or different node in the hierarchy tree and/or towards renaming the room or its node. Here is an example of steps that would be followed in one embodiment:
A room user proposes a name, or a name change, for the current chat room.
This proposal is automatically presented to all or a preselected subset of the other chat room participants.
Each authorized participant is enabled to cast an explicit or implicit vote (via a Cvi) regarding the proposal.
The votes are automatically counted over a predetermined time limit and the proposal is approved or denied according to room specific voting rules. Rules relating to approving the proposal may require one of the following:
A simple majority of the votes submitted or of all the participants in the chat room where that number may have to exceed a predefined quorum.
A specified percentage (i.e. 60%) of all submitted votes or of all the participants in the chat room.
The voting will end and the results will be displayed after:
Enough of the chat room participants have submitted votes to determine the outcome, or
A predefined voting time limit has elapsed.
Implicitly or explicitly produced votes (as conveyed by the Cvi's) can also be used to adaptively adjust a given user's CpCCp and/or DsCCp values and/or knowledge-base rules. Examples of this include:
Reducing a first user's verified proficiency level within a given topic, if the user receives negative feedback from other chat room users having verified higher proficiency levels in that same topic (in other words, subordinates are graded by validated ones of their superiors in the same topic).
Setting or altering a first user's preference or dislike for certain other people or chat rooms if the first user shows a history of consistently voting contrastingly for or against such other people or chat rooms.
Using the above techniques, a user can participate in a domain specific chat room without having a personalized DsCCp (e.g., he or she as a new corner has only a template DsCCp). As the user interacts with chat rooms in the domain, the user's reputation values and/or credential values in the corresponding DsCCp can be developed automatically based on implicitly or explicit votes cast by others in the room.
Implicitly or explicitly produced votes (as conveyed by the Cvi's) can be used to adjust profiles in real time. They also may be stored for later evaluation by trending analysis services. For example it may be noted that a user who is usually fairly balanced in their voting has voted extremely negatively over an usually large percentage of the time during one evening. From that it may be automatically inferred that this person is simply in a bad mood or ill on that one unusual occasion therefore those negative votes will not be counted or they will be weighed less than what how they are normally weighed (based on the user's reputation, credentials, proficiency level, etc.).
The present disclosure is to be taken as illustrative rather than as limiting the scope, nature, or spirit of the subject matter claimed below. Numerous modifications and variations will become apparent to those skilled in the art after studying the disclosure, including use of equivalent functional and/or structural substitutes for elements described herein, use of equivalent functional couplings for couplings described herein, and/or use of equivalent functional steps for steps described herein. Such insubstantial variations are to be considered within the scope of what is contemplated here. Moreover, if plural examples are given for specific means, or steps, and extrapolation between and/or beyond such given examples is obvious in view of the present disclosure, then the disclosure is to be deemed as effectively disclosing and thus covering at least such extrapolations.
By way of a further example, it is understood that the configuring of client computer machines and cloud servers in accordance with the disclosure constitutes transformation of instructable machines (and instructing articles therein) and cannot be deemed as a purely abstract exercise. Signals processed by such client computer machines and/or cloud servers are physical things and not abstract concepts. At least in some instances, processed signals represent physical things such biochemical and/or biomechanical and/or biometrically measured states of physical bodies (e.g., users) as detected and/or measured by biometric sensors. At least in some instances, processed signals represent physical things such the location of focus on a physical display of a user's eyes. It is further to be understood that the configuring of client computer machines and/or cloud servers in accordance with the disclosure can include use of local and/or remote software installation computers or computer programs to carry out physical installation of physical signals representing the software and/or to carry out activation of various functional parts of the described software modules. A computer-readable medium or another form of a software product transfer means or machine-instructing means (including but not limited to, a hard disk, a compact disk, a flash memory stick, a downloading of manufactured instructing signals over a network) may be used for instructing an instructable machine (client machine and/or in-cloud servers) to carry out their respective activities, where the activities can include selective activation of different functions including premium service and non-premium service in accordance with the disclosure. As such, it is within the scope of the disclosure to have an instructable machine carry out, and/to provide a software product adapted for causing an instructable machine to carry out the machine-implemented methods described herein.
Reservation of Extra-Patent Rights, Resolution of Conflicts, and Interpretation of TermsAfter this disclosure is lawfully published, the owner of the present patent application has no objection to the reproduction by others of textual and graphic materials contained herein provided such reproduction is for the limited purpose of understanding the present disclosure of invention and of thereby promoting the useful arts and sciences. The owner does not however disclaim any other rights that may be lawfully associated with the disclosed materials, including but not limited to, copyrights in any computer program listings or art works or other works provided herein, and to trademark or trade dress rights that may be associated with coined terms or art works provided herein and to other otherwise-protectable subject matter included herein or otherwise derivable herefrom.
If any disclosures are incorporated herein by reference and such incorporated disclosures conflict in part or whole with the present disclosure, then to the extent of conflict, and/or broader disclosure, and/or broader definition of terms, the present disclosure controls. If such incorporated disclosures conflict in part or whole with one another, then to the extent of conflict, the later-dated disclosure controls.
Unless expressly stated otherwise herein, ordinary terms have their corresponding ordinary meanings within the respective contexts of their presentations, and ordinary terms of art have their corresponding regular meanings within the relevant technical arts and within the respective contexts of their presentations herein. Descriptions above regarding related technologies are not admissions that the technologies or possible relations between them were appreciated by artisans of ordinary skill in the areas of endeavor to which the present disclosure most closely pertains.
Given the above disclosure of general concepts and specific embodiments, the scope of protection sought is to be defined by the claims appended hereto. The issued claims are not to be taken as limiting Applicant's right to claim disclosed, but not yet literally claimed subject matter by way of one or more further applications including those filed pursuant to 35 U.S.C. § 120 and/or 35 U.S.C. § 251.
Claims
1-25: (canceled)
26. A method implemented by a digital machine and further comprising:
- (a) maintaining in computer readable storage a plurality of first data objects each representing a respective topic node in a hierarchical tree of logically interconnected nodes; and
- (b) maintaining as an integrated part of each given one of the first data objects, one or more logical links to respective data resources that provide on-topic data corresponding to a given topic associated with the topic node of the given first data object.
27. The method of claim 26 wherein the data resources include an online real time communications exchange forum having recent exchanges directed to the topic of the topic node or expected to soon have exchanges directed to the topic of the topic node, where the recentness of the recent exchanges and the sooness of the soon to-be expected exchange are defined by prespecified time durations.
28. The method of claim 26 wherein the data resources include an online web page that provides content corresponding to the topic of the first data object.
29. The method of claim 26 wherein the data resources include an online proposal for a meeting between two or more users where the proposed meeting is defined as covering the topic of the first data object.
30. The method of claim 29 wherein the proposed meeting results from buried content that could have but was not displayed to one or more of the users.
31. The method of claim 29 wherein the buried content includes a scheduling calendar of the one of the users.
32. The method of claim 29 wherein the buried content includes a pressing contacts list of the one of the users.
33. The method of claim 26 wherein said maintaining of the one or more logical links to respective data resources includes for each of at least some of the given first data objects, repeatedly pruning from the linked-to data resources those resources that no longer provide on-topic data corresponding to the given topic associated with the topic node of the given first data object.
34. The method of claim 26 wherein said maintaining of the one or more logical links to respective data resources includes for each of at least some of the given first data objects, repeatedly adding to the linked-to data resources, additional data resources that provide on-topic data corresponding to the given topic associated with the topic node of the given first data object.
35-37: (canceled)
38. The method of claim 26 wherein said maintaining of the first data objects includes maintaining respectively stored collections of one or more topic hints respectively used for each of at least some of the given first data objects where the topic hints are derived from current focus information records (CFi's) of users whose topic lookup mechanisms touch upon the respective first data objects when seeking out on-topic communication exchange forums for their respective users.
39: (canceled)
40. The method of claim 38 wherein the respectively stored collections of one or more topic hints include credential-supported URL hints that are popularly provided in the CFi's of topic-credentialed ones of the users whose topic lookup mechanisms touch upon the respective first data objects, the topic-credentialed users being those who have validated or unvalidated credentials in the current topic or topics covered by the respective first data objects.
41-42: (canceled)
43. The method of claim 38 wherein the respectively stored collections of one or more topic hints include credential-supported keyword hints that are popularly provided in the CFi's of topic-credentialed ones of the users whose topic lookup mechanisms touch upon the respective first data objects, the topic-credentialed users being those who have validated or unvalidated credentials in the current topic or topics covered by the respective first data objects.
44. The method of claim 38 wherein the respectively stored collections of one or more topic hints include common meta-tag hints that are popularly provided in the CFi's of average ones of the users whose topic lookup mechanisms touch upon the respective first data objects.
45. The method of claim 38 wherein the respectively stored collections of one or more topic hints include common dominant word hints that are popularly provided in the CFi's of average ones of the users whose topic lookup mechanisms touch upon the respective first data objects.
46. The method of claim 26 wherein said maintaining of the first data objects includes maintaining respectively stored and system modifiable logical links between parent and respective child node representing ones of the given first data objects.
47. The method of claim 26 wherein said maintaining of the first data objects includes maintaining respectively stored and system modifiable logical links between parent and respective distant progeny node representing ones of the given first data objects.
48: (canceled)
49. The method of claim 26 wherein said maintaining of the first data objects includes maintaining respectively stored and topic space wise unique ones of positioning coordinates in a given topic space for substantially all of the first data objects.
50-80: (canceled)
81. A content worthwhileness scoring method that automatically scores shareable content according to how worthwhile it may be for respective users of a machine system to give attention to the shareable content, the method comprising:
- (a) automatically repeatedly determining one or more demographic attributes of respective, information contributing users of the machine system whose respective visitations to a respective cognition representing node maintained by the machine system and/or to a respective information exchange forum maintained by the machine system brings contributable data to the respectively visited node and/or forum as part of informational content automatically brought with the visitation due to node and forum maintaining operations of the machine system; and
- (b) automatically associating with a given item of contributable data, the determined demographic attributes of the respective, one or more information contributing users whose visitations automatically brought the respective item of contributable data to the respectively visited node and/or forum;
82. An automated method for creating a community of users who are currently or recently focusing on a common cognition, the method comprising:
- (a) automatically repeatedly determining likely cognitions of current or recent focus of respective online users of a machine system, the cognitions being respectively represented by respective cognition-representing data objects stored by the machine system, the determining of likely cognitions of current or recent focus including automatically repeatedly determining that respective clues gathered about current or recent states of the respective users correspond to respective ones of the cognition-representing data objects; and
- (b) automatically recommending to two or more of the online users whose likely cognitions are determined to currently or recently correspond to a same one of the cognition-representing data objects that they join with one another and/or into an ongoing forum where the forum has other users who have been determined to be likely currently or recently focusing on a same cognition represented by the same one of the cognition-representing data objects.
83. The method of claim 367 wherein the cognition-representing data objects include topic-representing data objects organized hierarchically and/or spatially within a cognitions representing space.
Type: Application
Filed: Mar 9, 2020
Publication Date: Aug 20, 2020
Inventors: Jeffrey A. Rapaport (Angeles City), Seymour Rapaport (Los Altos, CA), Kenneth Allen Smith (Fremont, CA), James Beattie (San Ramon, CA), Gideon Gimlan (Los Gatos, CA)
Application Number: 16/812,680
