Online dating service providing response status tracking for a service subscriber

A system and method are directed towards enabling a user to track the status of communication with other users in an online dating environment. Each user in the online dating environment can predefine a current status of availability and/or interest in receiving communications from other users in the online dating environment. When a communication is received, a predefined message is returned indicating the predefined status, such as “currently dating someone.” In addition or alternatively, each user can provide an interim response to received communications, giving the requesters some indication of a level of interest in further communication. An interim response can include a request for additional information about potential suitor, an indication that more time is required to think about a dating request, an indication that a user is definitely, or definitely not, interested in further communication. Requests and responses can be communicated via email, IM, SMS, or other forms.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser. No. 60/610,125 filed on Sep. 15, 2004, the benefit of the earlier filing date of which is hereby claimed under 35 U.S.C. § 119 (e) and the contents of which are further hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates generally to online dating services, and more particularly, but not exclusively, to a method and system for tracking the status of responses to communication for an online dating service.

BACKGROUND OF THE INVENTION

Dating services are now so popular that by at least one study, over twenty-six percent of all Internet users in America have visited a personals website. Part of the reason may be that online dating may appear to be a natural extension of where people are at this point in time. That is, many people today, have personal computers, or at least access to a personal computer. Moreover, virtually everyone wants to fall in love. Thus, it is natural to merge these two things. As such, online dating services may appear as the world's biggest singles bar. Except that it can be done in the privacy of one's own home where time may be taken to read about another person and get to know them through email, phone, and the like, before ever going on an actual date.

Thus, there has been a flurry of companies launching services that help people to meet and develop a personal relationship. Many of these companies, however, are struggling with developing additional services that will build customer loyalty. Without the ability to extend the value of the online dating experience, online dating may lose its appeal. Therefore, it is with respect to these considerations and others that the present invention has been made.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following drawings. In the drawings, like reference numerals refer to like parts throughout the various figures unless otherwise specified.

For a better understanding of the present invention, reference will be made to the following Detailed Description of the Invention, which is to be read in association with the accompanying drawings, wherein:

FIG. 1 shows a functional block diagram illustrating one embodiment of an environment for practicing the invention;

FIG. 2 shows one embodiment of a server device that may be included in a system implementing the invention;

FIG. 3 illustrates a logical flow diagram generally showing one embodiment of a process for tracking the status of responses to communication for an online dating service; and

FIG. 4 illustrates a logical flow diagram generally showing one embodiment of a process for providing additional communication after a date or other evaluation in the online dating serve.

DETAILED DESCRIPTION OF THE INVENTION

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

Briefly stated, the present invention is directed towards providing a method and system for tracking the status of communication with other users in an online dating environment. Each user in the online dating environment can predefine a current status of availability and/or interest in communicating with other users in the online dating environment. A predefined message can automatically inform an inquiring user of a target user's status. The target user can also provide an interim response without having to provide a full, hand-written response. Other predefined messages can be exchanged to indicate interest between users before and after a date or other evaluations of each other.

The invention further provides, as part of a mailbox feature, a diary/notes ability to allow a subscriber to write personal notes on each candidate and/or on each message between the subscriber and a candidate. Moreover, a tracking response feature is directed towards providing status information regarding a message sent to by one subscriber to another, even if the other subscriber has not fully responded to the message.

Moreover, the present invention further provides a threading feature that enables a subscriber to organize email messages into threads, with each thread corresponding to email messages to or from one other subscriber. Thus, instead of seeing potentially hundreds of emails, the subscriber may see a list of candidates' profiles who have communicated with the subscriber. Each thread may further show a thumbnail photo of the candidate, profile information about the candidate, and a flag indicating whether there is a new incoming message from the candidate. This feature then is directed towards reducing message clutter and enables the subscriber to readily keep track of relationships with candidates and the related messages. Furthermore, an integrated email provides each subscriber with a separate onsite mailbox, which may be different from their regular mailbox.

Additionally, the subscriber may include recommendations and other testimonies for themselves, from friends, family members, and others. In addition, the present invention also allows the subscriber to tell a date, for example, how they feel about another in a non-email format, such as by choosing from a list of predefined messages, or the like. Moreover, where two subscribers both indicate an interest in the other, a match may be established simply through a click, or similar, indication. When both so indicate a match, the system may further notify the two parties of the mutual interest. Some or all of the features of the present invention can be implemented as described below and in the attached appendices, and can be provided as part of a general user service and/or as part of a premium subscriber service.

Illustrative Operating Environment

FIG. 1 illustrates one embodiment of an environment in which the present invention may operate. However, not all of these components may be required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention.

As shown in the figure, system 100 includes client devices 102-104, network 105, and online dating server (ODS) 106. Network 105 is in communication with and enables communication between each of client devices 102-104, and ODS 106.

Client devices 102-104 may include virtually any computing device capable of receiving and sending a message over a network, such as network 105, to and from another computing device, such as ODS 106, each other, and the like. The set of such devices may include devices that typically connect using a wired communications medium such as personal computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, and the like. The set of such devices may also include devices that typically connect using a wireless communications medium such as cell phones, smart phones, pagers, walkie talkies, radio frequency (RF) devices, infrared (IR) devices, CBs, integrated devices combining one or more of the preceding devices, or virtually any mobile device, and the like. Similarly, client devices 102-104 may be any device that is capable of connecting using a wired or wireless communication medium such as a PDA, POCKET PC, wearable computer, and any other device that is equipped to communicate over a wired and/or wireless communication medium.

Each client device within client devices 102-104 may include a browser application that is configured to receive and to send web pages, web-based messages, and the like. The browser application may be configured to receive and display graphics, text, multimedia, and the like, employing virtually any web based language, including, but not limited to Standard Generalized Markup Language (SMGL), such as HyperText Markup Language (HTML), a wireless application protocol (WAP), a Handheld Device Markup Language (HDML), such as Wireless Markup Language (WML), WMLScript, JavaScript, and the like.

Client devices 102-104 may be further configured to receive a message from the another computing device employing another mechanism, including, but not limited to email, Short Message Service (SMS), Multimedia Message Service (MMS), instant messaging (IM), internet relay chat (IRC), mIRC, Jabber, and the like.

Client devices 102-104 may be further configured to enable a user to participate in an online dating service, manage personal user information associated with the online dating service, and the like, which may in turn be saved at a location, such as ODS 106, and the like. As such, client devices 102-104 may further include a client application that is configured to manage various actions on behalf of the client device. For example, the client application may enable a user to interact with the browser application, email application, and the like, to manage their online dating information. For example, the user may employ the client application, in part, to create a user profile, participate in an online dating personality compatibility analysis, relationship compatibility, and the like, such as a personality type and love styles test, a relationship test, and the like. The client application may further enable the user of the client device to perform searches based on a variety of criteria, manage their mailbox, including adding notes, diaries, and the like to a message, manage threaded messages, provide response statuses to other subscribers, manage testimonies, and the like. The client application thus may interact with various other components of the system as described in more detail below.

Network 105 is configured to couple one computing device to another computing device to enable them to communicate. Network 105 is enabled to employ any form of computer readable media for communicating information from one electronic device to another. Also, network 105 may include a wireless interface, and/or a wired interface, such as the Internet, in addition to local area networks (LANs), wide area networks (WANs), direct connections, such as through a universal serial bus (USB) port, other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. Also, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Furthermore, remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link. In essence, network 105 includes any communication method by which information may travel between client devices 102-104, and ODS 106.

The media used to transmit information in communication links as described above illustrates one type of computer-readable media, namely communication media. Generally, computer-readable media includes any media that can be accessed by a computing device. Computer-readable media may include computer storage media, communication media, or any combination thereof.

Additionally, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism and includes any information delivery media. The terms “modulated data signal,” and “carrier-wave signal” includes a signal that has one or more of its characteristics set or changed in such a manner as to encode information, instructions, data, and the like, in the signal. By way of example, communication media includes wired media such as twisted pair, coaxial cable, fiber optics, wave guides, and other wired media and wireless media such as acoustic, RF, infrared, and other wireless media.

One embodiment of ODS 106 is described in more detail below in conjunction with FIG. 2. Briefly, however, ODS 106 may include any computing device capable of connecting to network 105 to enable a user of at least one of client devices 102-104 to manage their online dating activities and related information. Devices that may operate as ODS 106 include personal computers desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, servers, and the like.

Illustrative Server Environment

FIG. 2 shows one embodiment of a server device, according to one embodiment of the invention. Server device 200 may include many more components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention.

Server device 200 includes processing unit 212, video display adapter 214, and a mass memory, all in communication with each other via bus 222. The mass memory generally includes RAM 216, ROM 232, and one or more permanent mass storage devices, such as hard disk drive 228, tape drive, optical drive, and/or floppy disk drive. The mass memory stores operating system 220 for controlling the operation of server 102. Any general-purpose operating system may be employed. Basic input/output system (“BIOS”) 218 is also provided for controlling the low-level operation of server 102. As illustrated in FIG. 2, server device 200 also can communicate with the Internet, or some other communications network, such as network 105 in FIG. 1, via network interface unit 210, which is constructed for use with various communication protocols including the TCP/IP protocol. Network interface unit 210 is sometimes known as a transceiver, transceiving device, network interface card (NIC), and the like.

Server device 200 may also include an SMTP handler application for transmitting and receiving email. Server device 200 may also include an HTTP handler application for receiving and handing HTTP requests, and an HTTPS handler application for handling secure connections. The HTTPS handler application may initiate communication with an external application in a secure fashion.

Server device 200 also includes input/output interface 224 for communicating with external devices, such as a mouse, keyboard, scanner, or other input devices not shown in FIG. 2. Likewise, server device 200 may further include additional mass storage facilities such as CD-ROM/DVD-ROM drive 226 and hard disk drive 228. Hard disk drive 228 is utilized by server 102 to store, among other things, application programs, databases, and the like.

The mass memory as described above illustrates another type of computer-readable media, namely computer storage media. Computer storage media may include volatile, nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computing device.

The mass memory also stores program code and data. One or more applications 250 are loaded into mass memory and run on operating system 220. Examples of application programs include email programs, schedulers, calendars, web services, transcoders, database programs, word processing programs, spreadsheet programs, and so forth. Mass storage may further include applications such as online dating manager (ODM) 252.

ODM 252 is configured to provide online dating services as described in more detail below. Briefly, however, ODM 252 enables a subscriber of various services to manage their user information, communicate with other subscribers, and non-subscribers, and to generally pursue an online dating relationship. ODM 252 provides a variety of features to enable a user of a client device to participate in the online dating experience.

For example, ODM 252 enables a subscriber to search for another person in the online dating service based on compatibility feedback. After identifying candidates for a subscriber based on personality and relationship compatibility and optionally other components, ODM 252 analyzes the subscriber's evaluation of the candidates for possible adjustments. For example, whether the subscriber has contacted a candidate, the frequency of the subscriber's contacts with the candidate, and the order in which the subscriber contacted the candidates may serve as indicators of the subscriber's opinion of the candidate. ODM 252 may further prompt the subscriber to rank or evaluate candidates. Based on the subscriber's feedback, ODM 252 may automatically adjust the search criteria, such as changing weights associated with a search variable, adding and/or deleting search variables, and the like. ODM 252 may then conduct an additional search for the subscriber. Subscriber feedback data may also be employed to adjust the search algorithm for each subscriber.

ODM 252 may further enable a subscriber to perform a combination search for various components including components of personality and relationship compatibility, and affinity. Other search components include: one-way scores, which indicates how much the candidate found by the search matches the subscriber's criteria; reverse scores, which indicate how much the subscriber matches the criteria of the candidate found by the search; location, which indicates a distance between the two persons' residence; activity level, which indicate whether the candidate has logged into the online dating service recently; affinity, which indicates whether the candidate has an affinity with another candidate found by the search, such as whether people who liked this person may also like that person; previous levels of interest, which indicates whether the subscriber has viewed the same candidate before and did not contact the candidate. ODM 252 also enables the subscribed to include the compatibility feedback, as described above, in the combination search. By providing the combination search capability, ODM 252 is directed at giving a subscriber more control by allowing the subscriber to identify a variety of search criteria, including, searching for candidates who are introverts, extroverts, assertive, submissive, and the like. However, ODM 252 is not constrained to these examples, and virtually any search criteria and combination of search criteria may be employed, without departing from the scope or spirit of the invention.

ODM 252 further enables a subscriber to write personal notes on each candidate and/or on each message between the subscriber and a candidate. This diary capability enables the subscriber to record impressions of a candidate and the progress of a relationship at various points in time.

ODM 252 is further configured to provide status information to a subscriber regarding a message the subscriber sent to another subscriber, even if the other subscriber has not fully responded to the message. For example, the other subscriber may select from a list of predefined status messages to indicate their current status, such as ‘on vacation,’ ‘busy at the office,’ ‘currently dating,’ and the like, which is intended to explain why the subscriber has not responded to the message. ODM 252 may be further configured to allow the other subscriber to select from the predefined status messages for a quick indication of their level of interest in responding to the message or when initiating a conversation. Such responses may, for example, include, ‘why don't you post a profile,’ ‘maybe,’ ‘give me some more time,’ ‘I'm currently taking a break from dating,’ ‘definitely,’ and the like. In this manner, the first subscriber may receive feedback and have a sense of closure, even though the other subscriber has not fully responded.

ODM 252 may further provide a variety of features, including those described above. These include, for example, threading of messages, integrated mailboxes wherein the subscriber is provided a different mailbox from their regular mailbox. The second mailbox may further employ the threading of messages. ODM 252 may also provide inline editing wherein search criteria is displayed to the subscriber on a side bar, and the search results are on the rest of the subscriber's screen. ODM 252 may also enable testimonies to allow the subscriber to include recommendations, compliments, and the like, on their web page profile, within a message, and the like. Moreover, the integrated mailbox may enable a subscriber to see a thumbnail picture of another person with which they may be communicating with, or similar relevant information. Clicking on the thumbnail picture may provide additional information about the person.

ODM 252 may further operate to provide a variety of other services, features, and the like, as described in more detail in the Appendices below. Moreover, it should be clear that while the described services, features, and functionality are ascribed to ODM 252, such services, features, and functionality may be distributed across one or more components, sub-components, and the like. Furthermore, such services, features, and functionality may be further distributed across one or more servers, without departing from the scope or spirit of the invention.

The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Status Operation

The operation of certain aspects of the invention will now be described with respect to FIG. 3. FIG. 3 illustrates a logical flow diagram generally showing one embodiment of a process for tracking the status of responses to communication for an online dating service.

As shown in the figure, process 350 begins, after a start block, at block 352, when a first user (e.g., user1) optionally selects a predefined status in the online dating service environment. For example, user1 can use a drop-down box to select a predefined status of availability and/or interest such as “On Vacation,” “Busy At The Office,” Currently Dating,” and the like. Processing next flows to block 354, where a second user (e.g., user2) discovers user1, or otherwise identifies user1 in the dating service environment. User2 can employ a number of techniques to identify user1 in the dating environment. In a simple online dating service environment, user2 can browse a list of other users of the online dating service and select one of the other users. User2 may make a selection based on physical characteristics, profession, proximity to user1, and/or other information provided by the other users. More sophisticated techniques include employing personality profiling and automated compatibility matching systems of the online dating service.

At an optional block 356, user2 can enter a note related to user1. The note can include any data such as user2's first impression of profile information about user1. At a block 358, user2 sends a message to user1. The message can be an email message, an instant message, an SMS message, and the like. The message can be stored, or otherwise tracked, at a block 360a with an entry in a message thread that corresponds to messages to or from user1.

Processing proceeds next to decision block 362, where a determination is made whether user1 previously selected a predefined status. If user1 previously selected a predefined status, processing continues to block 364; otherwise, processing branches to decision block 368. At block 364, the ODM sends a predefined status message to user2. In one embodiment, ODM sends the status message in the same format as user2 sent the initial message to user1. For instance, if user2 sent an SMS message to user1, the ODM returns an SMS status message back to user2. The ODM also adds an entry to the message thread at a block 360b.

Process 350 flows next to decision block 368, where user1 can optionally select a predefined interim response. For example, if user1 is uncertain about whether to accept an invitation from user2 to correspond, user1 can choose to send an interim response requesting more information about user2 or requesting more time before providing a definite response. Some possible predefined interim responses can include “why don't you post a profile,” “give me some more time,” “maybe,” “I'm currently taking a break from dating,” and the like. An interim response enables user1 to practice good etiquette and gives user2 some indication of user1's interest level, rather than leaving user2 with no indication at all. Similarly, user1 can select a more definite predefined response, such as “definitely,” or “no thank you.” If user1 selects a predefined interim response, processing continues to block 370; otherwise, processing branches to block 372. At block 370, the ODM sends the predefined interim response to user2. The ODM also adds an entry to the message thread at a block 360c. Whether or not, use1 elects to send an interim response, user1 can enter a note regarding user2, at a block 372.

At block 374, the ODM notifies user2 of the status message and/or interim response from user1. The ODM also stores an indication of the status message and/or interim response, so that user2 can track the status and/or response from user1 and/or other users. This indication may be associated with the thread entry and/or can be a separate indication. Processing then returns to an ODM control module.

FIG. 4 illustrates a logical flow diagram generally showing one embodiment of a process for providing evaluation feedback in the online dating service. As shown in the figure, process 400 begins, after a start block, at block 402, when user1 optionally evaluates user2. For example, user1 can evaluate the online profile of user2, have a conversation with user2, have a date with user2, and the like. User1 can optionally enter notes relating to user2 at a block 404.

At a block 406, user1 can send a custom message to user2 or select and send a predefined message to user2. The message can thank user2, compliment user2, or otherwise give an indication of user1's perception of user2. The message can be stored, or otherwise tracked, at a block 360d with an entry in the message thread that corresponds to messages to or from user1.

The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

APPENDIX A

Honeymoon Feature:

The Honeymoon feature is directed towards a Relationship Seeker segment of an online dating market. Relationship Seekers includes singles that desire—and are willing to openly communicate their desire—a long-term serious relationship, and prefer to use deeper personality and values-based tools and information to make dating choices.

Honeymoon provides enhancements to the information and functionality of Y!Personals targeting the Relationship Seeker.

To satisfy the Relationship Seekers' desire for a quick gauge of compatibility the invention includes a Personality and Relationship Test.

The Relationship Seekers' desire for quality inventory may be addressed by having customers subscribe to the premium Honeymoon service if they want to make full use of their additional profile information: The ability to search among other Honeymoon subscribers only, have Relationship Test Results be factored in by the search engine and thus return more compatible matches, share their Relationship Test results with other subscribers, see a Relationship Compatibility Index and explanation of how they are compatible with other Honeymoon subscribers, and gain access to other subscribers' Relationship Test Results.

By allowing Honeymoon subscribers to use both Honeymoon functionality and Y!Personals functionality the desire of Relationship Seekers for flexibility and control may be addressed. This has the product benefit of being able to design for expandability of key components of the service (e.g., profile, search, and mailbox). The invention may use one master formula to identify and rank the most relevant matches and simply incorporate more information into determining Honeymoon search results than for Y!Personals. Mailbox functionality may be the same for Y!Personals and Honeymoon users/subscribers, but Honeymoon subscribers may get access to some additional information and sorting options.

The invention may use the Personality Type & Love Styles Test and the Relationship Test as acquisition tools (by promoting them on- and off-network) thereby adding users to the database that otherwise might not even consider visiting Y!Personals. The invention may also employ an application, which may provide a short personality test to users, to gain access to their psychometric expertise and reduce time-to-market.

Subscribers can communicate with anyone whom they see in their search results (e.g., a Y!Personals subscriber does not have to upgrade to a Honeymoon subscription to reply to a Honeymoon subscriber who shows up in her search results).

APPENDIX B Y! Personals: Premier Search

The present invention further includes a robust personality and relationship profiling on Y!Personals (Y!P) and Y!Personals Premier (Y!PP) with the incorporation of various personality and relationship elements into Y!Personals' search functionality. These include the following:

Search Criteria:

    • Derived from various sources, various personality types and love styles may be incorporated into the “nice-to-have” search criteria that are available for searching, both in Search Criteria as well as in the inline editing search criteria box in the Search Results. Searchers may be able to designate personality type and/or love style as “must have” criteria, like other search criteria.
    • “Pickiness” Sliders for Premier Subscribers: An interface to allow users to temporarily adjust their permanent relationship compatibility settings (as returned by compatibility vectors based on the Y!P's Personality Test (GP) and Relationship Test (REL)) with regard to 1) how compatible they would like candidates in their search results set to be or 2) how compatible candidates in their search results set would like them to be.
    • Personality & Relationship Sliders for Premier Subscribers: An interface to enable users to adjust the minimum and maximum values desired for a given personality or relationship dimension, such that all candidates that are either below the minimum or above the maximum may be excluded from the search results set.

Scores & Rank Order: Weighted scores from Y!P's Personality Test (GP) and Relationship Test (REL) may be incorporated into a Unified Search Score (USS) formula. The USS is a foundation algorithm for Y!Personals' search functionality, as described in more detail in the Search Backend Weighting. The invention may also include various matching calculations on the Y!P back-end to interpret data and vectors, specifically with regard to 1) filtering extreme mismatches and 2) comparing the “candidate fit” (e.g., how a candidate's attributes match my seek preferences) and “seek fit” (e.g., how my attributes match a candidate's seek preferences) information. Finally, the invention may include an interface that allows searchers to decide whether or not their GP and REL information is included in the USS algorithm for a given search.

Search Results: The following information may be displayed to users in Search Results:

    • For Premier subscribers, whether or not a given candidate in search results is a Premier subscriber.
    • For all Y!P users, a given candidate's Personality Type and Love Style, if applicable.
    • Bucketed scores for Personality Fit (for all Y!P users, from the GP) and Relationship Compatibility (for Premier subscribers, from the GP and the REL).

Sorting: sort options may be added to allow all Y!P searchers to sort their search results by 1) Personality Type, 2) Love Style, and 3) Personality Fit Index (PFI), where applicable. Premier subscribers may also be able to sort their search results by 1) Relationship Compatibility Index and 2) User Type (Premier subscribers vs. non-Premier subscribers).

Search Pool Selector: An interface to allow Y!PP subscribers to choose whether to search among 1) Y!PP subscribers or 2) the combined Y!PP and Y!P inventory.

Compatibility Feedback: An interface with a 5-point scale that allows Y!PP subscribers to provide subjective feedback on how compatible they feel they are with a given profile. This feedback may be stored, analyzed, and incorporated into the USS formula to adjust later search results. This feature may be built on a store of feedback events that is sufficiently large enough to minimize the effect of occasional junk input based solely on candidates' photos or demographic data.

USS Weight Recalibration: In addition to the Premier-driven UI and feature enhancements above, the invention may recalibrate the back-end weights that are applied to each subscore in the USS. This recalibration may be performed because of:

    • 1. The desire to assign weights to the subscores for Relationship Compatibility Index and Personality Fit Index (as values for those weights were not assigned during the initial launch of USS).
    • 2. The inclusion of a Compatibility Feedback Subscore (as described below).
    • 3. The inclusion of an “exclude user” score for when a user selects to have a specific profile not shown again in their search results.

The draft weights are as follows:

Sample Subscore Weight Rationale Relationship Compatibility 25 Most important factor in Premier- Index (RCI) level matching Personality Fit Index (PFI) 21 Less important than RCI but more important than demog data 1-Way Search Criteria 12 Core search input, implicitly 60% Subscore of 20% of demog weighting Reverse Search Criteria 8 Core search target input, implicitly Subscore 40% of 20% of demog weighting Activity 8 Integral matching component but less significant than inputs above Distance 8 Integral matching component but less significant than inputs above Affinity Intersection 8 Useful tiebreaker but may not dominate matching Compatibility Feedback 5 Adjustment based on compatibility Score feedback input by searchers Frequency Capping 5 Useful tiebreaker but may not dominate matching Reply Count 0 Negative conversion effect. Could be used for subs MVP Subscore 0 Positive conversion effect. Could be used for temporary, ad hoc lifts

1-way Seek Fit Score: Based on any of a variety of algorithms and vectors, a seek fit score is calculated by how well a searcher's seek preferences match a candidate's self attributes.

1-way Candidate Fit Score: Based on any of a variety of algorithms and vectors, a candidate fit score is calculated by how well a searcher's self attributes match a candidate's seek preferences.

Personality Fit Index (PFI): A calculated score that combines the seek fit and candidate fit scores returned from General Personality (GP) Test vectors.

Relationship Compatibility Index (RCI): A calculated score that combines the seek fit and candidate fit scores returned from Relationship (REL) Test vectors.

“Expert” RCI or PFI: The “Expert” RCI or PFI returned from vectors.

“Temporary” RCI or PFI: An RCI or PFI that is temporarily adjusted by user input for searching purposes. (See “pickiness” below)

GP (Sub-)Score: Same as PFI above.

REL (Sub-)Score: Same as RCI above.

Personality Type: One of 12 general personality profiles as determined by the GP Test.

Love Style: One of 6 general love profiles as determined by the GP Test.

Relationship Dimensions: One of a variety of different relationship attributes as determined by the REL Test.

Compatibility Feedback Subscore: A subscore in the USS formula that may be based on the Compatibility Feedback described below and serves to either increase or decrease the overall USS score.

Search Criteria: Description GP A Search Criteria page allows searchers to choose Elements among the, for example, 12 Personality Types and, for in Search example, 6 Love Styles as nice-to-have search criteria. Criteria Searchers may also be able to designate Personality Type and Love Style as “must have” categories, just as they can with the current demographic data. This is available whether or not you have taken the Personality Test. User can select whether or not to have their Personality Fit/Relationship Compatibility included in their search (regardless of visibility setting of their GP report). The invention may also show to the user that their recommended Personality Type and Love Style are. Link all Personality Type and Love Styles to a pop-up describing each option GP Inline editing functionality to include Personality Type Elements and Love Style as criteria that searchers may edit to refine in Inline their search results. This is available whether or not you Editing from have taken the Personality Test. Search Results Search For Premier subscribers, provides an interface to allow Pool searchers to choose whether to search among 1) Y!PP Selector subscribers or 2) the combined Y!PP and Y!P candidate inventory. The default setting for this interface may be “Y!PP subscribers”.

Scores & Rank Order Description Personality Fit and Incorporates separate weighted subscores to the Unified Relationship Search Score formula (USS, as described in the Search Compatibility Backend Weighting) for Personality Fit (based on the GP Subscores in USS Score) and Relationship Compatibility (based on the REL Score). Note: If a user makes their tests invisible, they may still appear in search results but the invention may not use their PFI in the USS calculation. * The specific calculations to be used for various searcher/candidate combinations are detailed in Table 1 below. Adjusted USS Recalibrates the weighting for current USS subscores Subscore (e.g., Distance, Activity, 1-Way Demographic Search Weighting Score, etc.) so that a Personality Fit Subscore and a Relationship Compatibility Subscore can be included. Default GP & REL For users who have not taken either the GP or the REL, Scores (aka set a default score to the median value for each test (so “Neutral”) that there is a 50/50 chance that the default test score is in the middle). NOTE: As shown in Table 1 below, these scores may be used to create valid Personality Fit and Relationship Compatibility subscores when a search candidate has not yet taken the GP or REL test respectively. This default scoring may avoid penalizing profiles without GP or REL results. GP Fit Calculation Generate estimated Seek Preferences based on the observed attribute values for each GP test taker. This estimate is an approximation of which type of person someone with a particular Personality Type and Love Style combination is looking for in general. These estimated Seek Preferences are then used to compute the Personality Fit Score. (For details please see below) Filtering for Create back-end search functionality that automatically Extreme excludes any candidates who are extremely incompatible Mismatches (Step with the searcher. 1 in REL Compatibility Calculation) Weighting for REL Refer to below. Mutual Fit Scores (Step 2 in REL Compatibility Calc.) Mutual Quality Fit - Normalize REL Mutual Fit to take into account how Normalization “picky” both the searcher and the candidate are (e.g., a (Step 3 in REL Mutual Fit Score of 90/100 might be an “excellent” fit for Compatibility profile A but “very good” for profile B). The Calculation) normalization allows bucketing search results into the 5- point scale described in Search Results below. User Control Over For Y!P users/subscribers as well as Premier subscribers, Inclusion of GP & provide users with an interface to allow searchers to REL in USS decide whether or not their GP and REL information may be included in the USS algorithm for a given search. This may be two separate checkboxes based which tests they've taken. Visibility setting of If a user marks his or her PER/REL test as invisible, the PER/REL test invention may not include them in search results Mutual Match for Prior to implementation, a 10% test may be run with demographic data mutual match enabled with pre SR4 mutual match code (where must haves act as filters in both directions). With this test, the invention may be able to see what kind of effect mutual match has on conversion.

TABLE 1 Searcher/Candidate Scenarios for GP and REL Test Information Candidates Search No test Formulas REL GP available Me REL (REL weight + (GP weight + (REL weight) * GP weight) * (.33 * (Default (REL score) (REL weight − REL Score) GP weight))) * (GP score) GP (GP weight + (GP weight) * (GP weight) * (.33 * (GP score) (Default (REL weight − GP Score) GP weight))) * (GP score) No test 0 0 0 available
NOTE:

The 0.33 weighting used if there is a REL test results/GP test results combination is directed towards ensuring that a great GP-based fit may propel the profile above a profile with a bad REL compatibility in a REL/REL test results case.

Search Results Description GP & REL Display the following GP & REL information in Search Information in Results, if applicable: Search Results Personality Type for each candidate (links to explanatory pop-up) Love Style for each candidate (links to explanatory pop-up) Either (links to external view of profile): Personality Fit Index (PFI) for each candidate, bucketed into, for example, a 3- point scale (good fit, neutral fit, not a good fit) Relationship Compatibility Index (RCI) for each candidate, bucketed into, for example, a 5-point scale (Very High, High, Neutral, Low, Very Low) Note: Relationship Compatibility replaces Personality Fit if the user has taken the relationship test. To further clarify, when a user does a search and is viewing search results, what appears under the GP/REL test section of each search results is the highest common denominator of the two tests between the two users. To further clarify: For Y!P subs, the invention may just show PFI (don't have access to REL test). For Y!PP subs searching on Y!PP subs, show RCI For Y!PP subs searching on both user pools (Y!P and Y!PP), show highest available test between two candidates. As a result, when Y!PP subs are viewing other Y!PP subs in the search results, the invention may make sure to call out that they are Y!PP subs via a Y!PP icon/highlight. Gallery/Slideshow Add visual indicator if user is a Premier subscriber. View Premier Indicator For searchers who are Premier subscribers, display candidates who are also Premier subscribers with a visual differentiation that is distinct from candidates who are regular Y!P posters/subscribers. “Pickiness” Create an interface that allows searchers to temporarily Interface adjust the mutual match weight (w1 and w2) associated in their RCI. This may be a 3 point scale. The mutual match fit score = w1(1 way seek fit) + w2(1 way candidate seek fit) where w1 and w2 are percentages and sum to 100%. Since this is a 3 pt scale, the combinations of weights are: Combination 1: W1 = 100, W2 = 0 Combination 2: W1 = 50, W2 = 50 Combination 3: W1 = 0, W2 = 100 Compatibility In one embodiment, the invention may not surface the Feedback Rating rating a user has given a profile via compatibility feedback. This may be available through the external view of the profile. Personality and Create an interface that allows searchers to adjust the Relationship minimum and maximum values desired for a specific Dimension personality or relationship dimension, such that all Adjustments (aka candidates that are either below the minimum or above “sliders”) the maximum may be excluded from the search results set. Searchers may be able to easily enable/disable the settings for a given relationship dimension when setting Search Criteria. Don't Show Profile Functionality that allows a user to select a profile to never Again be shown again in their search results. The invention may also include an interface to allow them to uncheck users they removed.

Sorting Description Sorting Based Allows searchers to sort their Search Results by the on GP & REL following GP & REL information (in addition to existing Elements SR4 sorting options): Personality Fit Index (PFI) (sorted highest to lowest) Relationship Compatibility Index (RCI) (sorted highest to lowest, available to Premier subscribers) User Type, broken down into Premier subscribers first, followed by non-Premier subscribers (available to Premier subscribers)

Compatibility Feedback Description Single- Includes an interface with a five-point scale (−1, −0.5, 0, Input +0.5, +1) that allows Premier subscribers to provide Compati- subjective feedback on how compatible they feel they are bility with a given candidate's profile (and by association, that Feedback candidate's specific Personality Type and Love Style combination, such as “Passionate Architect”): For each individual user, the invention may store a set of “x” feedback events for the possible combinations of the Personality Types (PT) and the Love Styles (LS), from which the USS adjustment described below, may be made. From this store of feedback events, the invention may calculate an average feedback score for each of the PT-LS combinations that may be used as an input to the USS subscore for compatibility feedback (see below). Retrieve and display a user's compatibility feedback rating for the unique profiles. Once the maximum number of feedback events has been reached, a mechanism needs to be in place to drop the earliest ratings available (ratings may be time stamped). Personality Type and Love Styles combinations that have not been rated may be given an initial value of 0 (zero). The compatibility feedback subscore of USS may take affect after a user has rated, for example, 3 profiles within a specific Personality Type/Love Style combination. USS Increase/Decrease the USS via the inclusion of a weighted Subscore Compatibility Feedback subscore for candidates who for Com- compare favorably/unfavorably with a given searcher's patibility combination of Personality Type and Love Style. Feedback Multiple- Instead of allowing Premier subscribers to provide a Input single rating of compatibility feedback for each given Compati- candidate, extend the interface to allow Premier bility subscribers to provide more granular input on specific Feedback compatibility elements such as individual relationship dimensions. The invention may have to create a formula that may take into account these multiple ratings, identify patterns, and adjust relevant the vectors and the USS accordingly.

APPENDIX C Search Back-End Weighting Feature

The present invention further includes a Personals search results that is configured to employ a new “weighted” approach. This is directed towards:

    • Providing users with more relevant results
    • Incorporating new criteria and data for Honeymoon subscribers into the search formula
    • Preparing the search infrastructure for additional, searchable inputs

CURRENT SITUATION: First, generate a set of relevant search results by filtering out any profiles that do not meet the searcher's selected “must have” criteria. Then, the current back-end search formulas use a “smart” rank order of various keys to sort relevant search results. As defined by the Affinities 2.0 specification (aka “Adaptive Personalization”), this rank order may be as follows:

When “sufficient relevant history” exists for a given user:

    • 1. Frequency Capping
    • 2. Reply Count
    • 3. Affinity Intersection
    • 4. Search Criteria Subscore
    • 5. Distance
    • 6. Activity

When no “sufficient relevant history” exists:

    • 1. Reply Count
    • 2. MVP Score
    • 3. Search Criteria Subscore
    • 4. Distance
    • 5. Activity

These orders function according to a fixed sorting mechanism, much like the way that a spreadsheet program sorts a list with multiple columns first by one criterion, then ranks any ties by a second criterion, and then ranks any remaining ties by a third criterion, etc.

The current approach has the following observed, undesirable behaviors:

    • 1. Cliff Effect: The current formula typically results in arbitrary demotions of otherwise valid search results. For example, a current search might return a profile with a score of 11 out of 12 nice-to-haves and a distance of 50 miles before a profile with score of 10 out of 12 nice-to-haves and a distance of 0 miles, even though most users would probably sacrifice one nice-to-have criterion if their prospective date were 50 miles closer.
    • 2. Ignored Subscores: Some of the subscores, like distance, have so many different values that the number of ties is minimal. Any subscores after these large branching keys have little or no effect. For example, sorting by score, distance and activity typically results in the same order as sorting by score and distance. Similarly, a mutual match search that sorts by score returns an order that is somewhat similar to sorting by score, distance, and activity, such that the first batch of results in either case are the same.

PROPOSED APPROACH: Rather than this fixed order, the invention proposes to assign appropriate weights to each of the relevant subscores (e.g., search criteria subscore, distance, activity, etc.) and calculate an aggregate score (aka “Uberscore”).

First, the new approach changes the way the Search Criteria Subscore is calculated. Instead of calculating 1-way and reverse (aka “2-way”) search scores from equally-weighted nice-to-have search criteria, the invention implements at least a two-tier, system-defined weighting system for nice-to-have search criteria and creates separate 1-way and reverse search criteria subscores as follows:

    • 1. Assigns a higher weight to those nice-to-have search criteria that are most important to users (e.g., body type, smoking, ethnicity, marital status, employment, drinking, education, more kids), as defined by existing data on saved searches by Y!Personals users.
    • 2. Assigns a lower weight to all other nice-to-have search criteria.
    • 3. Calculates a 1-way Search Criteria Subscore from the normalized percentage of nice-to-have criteria that a given search target fulfills.
    • 4. Calculates a Reverse Search Criteria Subscore from the normalized percentage of each search target's nice-to-have criteria that the searcher's profile fulfills.

In addition to these two Search Criteria Subscores, other subscores may be normalized so that they can be incorporated into a new aggregate score (see Glossary below for definitions and various embodiments of formulas):

    • Relationship Compatibility Index
    • Personality Compatibility Index
    • Distance
    • Activity
    • Affinity Intersection*
    • Frequency Capping*
    • Reply Count
    • MVP
      *=Subscores that are not in the SQL database and which may include some post-processing after an initial calculation of the other weighted subscores.

Given this set of subscores, the proposed process is as follows:

    • 1. Filter out any profiles that do not meet the searcher's selected “must have” criteria.
    • 2. For the remaining profiles, normalize the values for each subscore to ensure a valid “apples-to-apples” scale for all subscore values. The current plan is to normalize all subscores to a value range of 0 to 1 such that higher values signify higher desirability.

3. Assign an appropriate weighting to each subscore. A sample weighting of all relevant subscores for initial testing purposes is shown in the chart below:

Subscore Sample Weight Rationale Relationship Compatibility Index 25% Most important factor in Honeymoon matching Personality Compatibility Index 22% Less important than RCI, but more important than demog data 1-Way Search Criteria Subscore 12% Core searcher input, implicitly 60% of 20% demog weighting Reverse Search Criteria Subscore 8% Core search target input, implicitly 40% of 20% demog weighting Distance 10% Integral matching component, but less significant than inputs above Activity 10% Integral matching component, but less significant than inputs above Affinity Intersection 8% Useful tiebreaker, but should not dominate matching Frequency Capping 5% Useful tiebreaker, but should not dominate matching Reply Count 0% Negative conversion effect; Could be used for subs only (TBD) MVP Subscore 0% Positive conversion effect; Could be used for temporary, ad hoc lifts
    • 4. Calculate an “Uberscore” from the weighted subscores.
    • 5. Rank all search results by descending Uberscore.
    • 6. “Bucket” the ranked set of raw Uberscores into 10 subgroups that can be assigned a simple user-friendly value, such as 1-5 stars, hearts, or other appropriate indicator. These less granular buckets may meaningfully present a simple rating of search relevance alongside other matching-related data such as Personality and Relationship Compatibility Indexes. The ranges for these Uberscore buckets may consider asymmetrical weights for a favorable presentation of the inventory (for example, 5 stars might be 80%-100%, 4.5 stars might be 70%-79%, 4 stars might be 60%-69%, etc.).
    • 7. Apply a secondary sort (e.g., activity, age, distance, online) if initiated by a given searcher.

May further include targeted weightings for specific searcher types, such as male/female, subscriber/non-subscriber, basic/Honeymoon, or different age brackets. Additionally, the invention may include a user-friendly administrative interface that may allow Y!Personals management to adjust specific weights quickly on an ad hoc basis for specific business goals (e.g., driving increased conversion during limited periods by overweighting the MVP subscore).

GLOSSARY

Searcher: The user initiating a search.

Search Target: Any profile that is included in the results set for a given search.

Subscore: Any variable that is used to generate the Uberscore (e.g., search criteria subscore, distance, activity).

Uberscore: A combined score of all weighted subscores.

Search Sort Order: A descending order of all search targets based on Uberscore.

Must Have Search Criterion: A search criterion selected by the searcher that filters out any profiles that do not meet the values selected for that criterion.

Nice-to-Have Search Criterion: A search criterion selected by the searcher that is counted as desirable and used to calculate the Search Criteria Subscore below.

Search Criteria Subscore: In general terms, the Search Criteria Subscore is easily thought of as the number of nice-to-have search criteria satisfied over the total number of search criteria specified by the searcher. Currently, Search Criteria Subscore can refer to a 1-way (e.g., how a search target matches what the searcher is looking for) or reverse (e.g., how closely the searcher matches what the search target is looking for, also referred to as “2-way”). The exact formulas for each type are:

    • 1-Way: The normalized percentage of nice-to-have criteria that a given search target fulfills.
    • Reverse: The normalized percentage of each search target's nice-to-have criteria that the searcher's profile fulfills.

Relationship Compatibility Index: A score based on a comparison of the Relationship Test results of the searcher and each search target.

Personality Compatibility Index: A score based on a comparison of the Personality Test results of the searcher and each search target.

Distance Subscore: A subscore based on the distance that a given search target is from the location of the searcher. This subscore may be based on the Pythagorean distance between the lat/long coordinates of the searcher's location and that of each search target. The subscore may be equal to (maxDistance−distance)/maxDistance where maxDistance is the specified search radius. Distance behaves like a “must have” criteria in that all search targets outside of the maxDistance radius are excluded from search results.

Activity Subscore: A subscore based on which profiles have been active (e.g., logged in to the site) most recently. This subscore may be (maxLastActivityTime−timeSinceLastActivity)/maxLastActivityTime where maxLastActivityTime is the maximum possible value of ‘lastActivityTime’

Frequency Capping: If a searcher has seen a given search target x times or more without clicking on that profile to view its details, that search target is demoted in the overall search sort order so that the searcher may not continually see the same profiles. The current setting for x is 3, such that the Frequency Capping subscore is set to “0” for all search targets that the searcher has seen in his/her search results history 3 or more times and “1” for all other search targets. Search Targets can also be ‘immune’ from being frequency capped if the searcher has viewed his/her profile in detail, saved the profile to his/her saved profiles, or replied to the profile via the Personals Mailbox. Search Targets granted such immunity are also given frequency cap scores of ‘1’.

Reply Count: Currently, if a search target has received more than a defined count of initial replies (mboxReplyCountCeiling) in the last 24 hours, the invention may demote that search target in the overall search sort order to minimize the volume of new messages that the user receives and promote profiles which have a higher probability of responding to new messages. This value may be calculated as (mboxReplyCountCeiling−min(mboxReplyCountCeiling, mboxReplyCount))/mboxReplyCountCeiling. Reply Count has a tiered range of 6 possible values (0, 1, 2, 3, 4, 5 or more). The current value of mboxReplyCountCeiling is set to 5.

Affinity Intersection: A “similar profiles” ranking built according to a user interaction history store of all profiles that a searcher has interacted with (e.g., profiles clicked on, profiles communicated with (both emailed, icebreaker'd, and IM'd), profiles saved, and profiles forwarded). From this data store, the system identifies a set of “similar profiles” to those with whom the searcher has interacted. The current per user quota for this user interaction history store may be predetermined to some value, such as 16 kb or the like, at which limit the oldest information is cleared out to make room for new data. This subscore may vary from “0” to “1” where “0” means no affinity intersection. For other profiles that have an affinity intersection rank, this subscore may be equal to (nAffinityIntersectionAds−rank+1)/nAffinityIntersectionAds, where nAffinityIntersectionAds is the number of affinity intersection profiles in the searcher's history record. All profiles in the result sets of non-logged in users (or of logged-in users without affinity intersection lists) may be given an affinity intersection rank subscore of “0.” For those profiles without sufficient relevant history, their affinity intersection subscore may be zero.

MVP Subscore: If a profile's daily count for any one of the following three attributes exceeds x, then that profile is assigned a negative score and may be demoted in the overall search sorting order: 1) number of times viewed; 2) number of times replied to; and 3) number of times saved in saved profiles. MVP subscore may no longer be used in place of affinity intersection when no sufficient relevant history exists, as the affinity intersection subscore in that case may be zero.

Sprinkling: Sprinkling refers to the practice of artificially inserting non-search target profiles into the search sort order (e.g., profiles based on affinity intersection or, if no sufficient relevant history exists, MVP subscores), typically in odd-numbered positions in the search sort order.

Language Sorting Options: The current search code is equipped to allow users to specify that a given language be assigned absolute priority in the final search sort order (e.g., so that all Spanish-language profiles in a given search results are sorted higher than English-language profiles in the same set, regardless of each profile's relative search criteria subscore. (Language sorting may not be incorporated into the Uberscore formula. Instead, if a user selects multiple languages, the invention may display search results according to the Uberscore ranking without regard to language, so the profiles in search results may be mixed (e.g., a Spanish profile may be followed by two English profiles and then another Spanish profile), with potentially best matches shown first.

Cross-Search: The current search code also allows users to “cross-search” across multiple international sites as well (e.g., a searcher in London that selects a wide-enough radius would also see search results from France and Germany). Potential issues regarding adapting cross-search to the proposed approach include 1) a search sort order that includes a mixed order of languages and 2) different sets of available search criteria across intl sites (e.g., Pets in France).

Description of the functionality Search Back-End Weighting Description System-Defined May assign an appropriate weighting to each nice-to-have Weighting for criteria when calculating the search criteria subscores. Nice-to-Have The weighting may be based on quantitative data on the Search Criteria most popular saved search criteria among Y! Personals searchers as well as qualitative evidence of user preferences (e.g., assigning a 2x weight to those criteria that have been selected as “must have” in 20% or more of saved searches, such as body type, smoking, ethnicity, marital status, employment, drinking, or education, and assigning a 1x weight to lesser criteria such as TV habits, astrological sign, or living situation). Distinct 1-Way and Two distinct search criteria subscores may be weighted Reverse Search individually: Criteria Subscores 1-way Search Criteria Subscore: The normalized percentage of nice-to-have criteria that a given search target fulfills. Reverse Search Criteria Subscore: The normalized percentage of each search target's nice-to-have criteria that the searcher's profile fulfills. Uberscore May assign appropriate weighting to each of the relevant subscores, compute a combined “Uberscore” that takes into account the normalized values for all subscores, and then sort the search target set from highest to lowest Uberscore. Uberscore Buckets May map all raw Uberscore values to a smaller range of values to ensure a simple visual representation of the Uberscore to users. Mapping of Uberscores to buckets may be predefined based on a variety of criteria. For example, may assume 10 buckets to allow for a 5-tier system with half-point scores. Secondary Sort Searchers can initiate a secondary sort of their search Options results according to various criteria (e.g., activity, age, distance, online). With regard to the Uberscore, this sorting may be achieved outside of the weighted Uberscore formula by applying a secondary fixed sort to the search results set that would prioritize the given sort ahead of Uberscore. For example, a secondary sort by age would resort all search results by age, then by Uberscore as a tiebreaker. These additional sorts may be secondary because the default sort order for all searches might be by descending Uberscore. Administrative May include an easy-to-use interface that allows Y! Tools Personals Management to make quick changes to the weights used to generate the Uberscore; and an easy process for extracting data on search performance to enable trend analyses of key search metrics. User-Defined May allow the searcher to define an importance scale for Weighting for each nice-to-have search criteria. Nice-to-Have Search Criteria User-Defined May allow the searcher to define appropriate weights for Weighting for certain search subscores. For example, the user may be Subscores able to define the relative importance of various dating considerations as part of the search process, such as “I am interested in finding someone who is compatible with me”, “I am most interested in finding someone who meets my desired physical characteristics,” or “I am most interested in dating someone who lives very close to me”. Segment-Specific May allow Y! Personals to define different search Search Formulas formulas for specific customer segments (e.g., subscribers vs. non-subscribers, male vs. female, basic vs. Honeymoon, or distinct age brackets). For example, a search back-end formula for subscribers could address our business goals of subscriber satisfaction and retention by emphasizing frequency capping and reply count to ensure a sufficient variety of search results and as wide a set of potential matches as possible. Similarly, for non- subscribers, the invention may use a formula that disables frequency capping and reply count and overweighs the MVP subscore to showcase the 2% of users that are already known are directly responsible for more than 50% of our conversions.

APPENDIX D

The present invention further includes a Message Center feature that revamps a current Mailbox platform to create a more intuitive system for Personals users to send and receive communication of all forms, which may include email and icebreakers, IM, mobile/SMS, voice, and video greetings. The design offers Y!P users ease of use, visual simplicity, and tools for conversation tracking, automation, and manageability. These may drive greater interaction among users, increase subscriber satisfaction, and in turn improve retention. Moreover, the message center feature is directed towards:

    • Improving the current mailbox interface to create a more intuitive and efficient experience that may increase and extend usage of on-site communication tools.
    • Introducing functionality in the mailbox to foster “Personals etiquette” among users and increase inventory photo penetration and the value of the profile base.
    • Improving the backend infrastructure to offer redundancy and integrate the message center servers more seamlessly with other components of the service.
      Description

The communication platform for Yahoo!Personals includes:

    • 1. Conversation “Threads”: The invention may allow members to optimize and track their communication with other users via intuitive conversation “threads.” Instead of a traditional mail inbox built to handle individual sent and received messages, the Message Center may be organized according to threads with other users. For example, the first time that a user communicates with another user on the service, the Message Center may create a stored thread to capture all subsequent messages between these two users in a conversation-style format. This functionality may replace a typical inbox with a sortable, visually simple view of all the profiles with whom a given user has communicated. In keeping with traditional mailbox convention, this view may show new and recently updated threads at the top by default. Clicking on a given profile in the Message Center may allow the user to see all messages sent to and received from that profile since the first contact between the two users. The Thread View for each connected profile may be updated with each new message. This format has many advantages over a traditional mail UI because it:
      • Allows users to keep track of their interactions with specific profiles easily
      • Simplifies daily communication tasks and improves usability
      • Alleviates the current “email bombardment” experienced by women users by consolidating multiple messages from the same user into a single thread and providing various options for sorting threads in the Message Center.
      • Allows for a more graphical communication experience (e.g., profile thumbnails, emoticons, visual format “a la iChat”)
      • Minimizes additional administrative overhead (e.g., icebreaker folders, sent messages folder, drafts folder, etc.)
    • The Message Center design may preserve traditional mail functionality such as saving drafts and deleting (of Messages). Additionally, this design may further include:
      • Pre-canned messages such as “No Thanks” or “Need More Info” to make daily communication tasks more convenient and time-efficient (NOTE: Icebreakers may be addressed by this project because they are an existing form of pre-canned messages).
      • Notes to help users keep track of their prospective dating partners
      • Saved “snippets” of previous messages that can be repurposed to woo future dates
      • Templated conversations to help users carry on more successful communication with prospective dates
      • Closer integration of the Message Center with a user's saved profiles to foster communication with saved profiles that a user has not yet contacted
      • Future sitewide integrations (e.g., links to threads directly from profiles, a front page Message Center module with links to newly updated threads)
    • 2. Pre-Canned Messages: To improve retention and manage user expectations, the invention may introduce functionality that may allow subscribers and non-subscribers to optimize their communication with other members. For example, the invention may introduce a “Need More Info” request tool that generates a system message requesting that the recipient provide the sender with additional detail. To increase the value of the Personals inventory, such responses may request that the recipient post a photo, add additional detail to his/her profile, complete a Honeymoon-related personality or relationship test, or write a more detailed “In my own words . . . ” description. A similar system messaging feature may allow members to end communication with other members tactfully through a list of “no thanks” responses. These gender-specific responses may notify the recipient about a lack of mutual interest or chemistry and keep users engaged in the service by suggesting affinity profiles for the recipient to consider. The end goal of this functionality is to improve the experience for both parties and instill a sense of “Personals etiquette” into the online dating cycle.
    • 3. Deeper Integration of Communication with Other Site Processes: The message center feature further enables message machines to talk to the servers running search and other front-end machines. For example, the invention may introduce affinity suggestions into the pre-canned message flow to encourage members to contact more people. Similarly, the invention may lay the groundwork for tying the Saved Profiles functionality more directly to the communication system to highlight to users those profiles that they have saved but not yet contacted.
      • Increase communication among Y!Personals users, as captured by the following:
        • Initial Messages Sent (total volume, distribution, and per user average across all types: emails, icebreakers)
        • Replies to Messages Received (total volume, distribution, and per user average across all types: emails and pre-canned messages)
        • Courtesy Pre-Canned Messages Sent (total volume, distribution, and per user average across all types: “No Thanks” and “Need More Info” messages)
        • Conversation Threads (total volume, distribution, and per user average for both new and existing threads)
      • Increase the percentage of total inventory that receives some form of communication
      • Increase the average # of messages exchanged between 2 users per week/month
      • Decrease the # of initial messages that get no response
      • Increase inventory richness (% of subscribers who have profiles with photos, % of subscribers who have robust profiles and “In my own words” descriptions)
      • Decrease the volume of communication-related customer care issues
      • Increase overall user satisfaction with the communication tools offered on Yahoo!Personals

GLOSSARY

01 Message An email sent by a user via the “Email me!” profile link or as a response to a received message from another user. 02 Thread A unified set of sent and received messages between two unique users. Also referred to as “connection,” “conversation thread,” or “communication threads.” 03 Thread List A sortable list of all current threads in the user's message center, somewhat analogous to the “inbox” in a traditional mail UI. Also referred to as “Mailbox Home”. 04 Pre-Canned A message including pre-defined content which the user can quickly Message send from within the Message Center to other users to begin, continue, or end a thread. Also referred to as “Quick Reply”. 05 Icebreaker A type of pre-canned message sent by a user via the “Break the Ice for Free!” profile link and included in the thread along with other messages. 06 Preview An excerpt of text from the latest message sent/received in the thread that is displayed in the Thread List. 07 Note Text saved by a user about another unique user with whom he/she communicates. 08 Snippet Text saved by a user for later use in other messages. 09 Personals name Yahoo! Public Profile attached to a Y! Personals account. Also referred to as “alias” within Y! Personals. 10 Nickname A user-defined name for another user with whom he/she communicates.

The Message Center feature is further described in the use cases of FIGS. 3-33, and an example mailbox status is illustrated in FIG. 34.

Claims

1. A method for tracking a status of a user, comprising:

determining whether a first user specified a predefined status of availability within an online dating environment; and
if the first user specified the predefined status, automatically providing an indication of the predefined status of the first user to a second user in response to a message from the second user to the first user in the online dating environment.

2. The method of claim 1, wherein the predefined status indicates at least one of an availability and an interest in further communication in the online dating environment.

3. The method of claim 1, further comprising enabling the second user to identify the first user in the online dating environment prior to communication of the message from the second user to the first user.

4. The method of claim 1, further comprising enabling the first user to provide an interim response to the message from the second user.

5. The method of claim 4, wherein the interim response indicates a level of interest in further communication with the second user.

6. The method of claim 4, wherein the interim response comprises at least one of a request for additional information about the second user, an indication that the first user desires time to think about further communication with the second user, an indication that the first user is not interested in further communication with the second user, and an indication that the first user is interested in further communication with the second user.

7. The method of claim 1, further comprising storing the indication and enabling the second user to track the indication with a plurality of other indications from other users.

8. The method of claim 1, further comprising storing the message in a thread of communication between the first user and the second user.

9. The method of claim 1, further comprising enabling at least one of the first user and the second user to enter a note in the online dating environment.

10. The method of claim 1, further comprising enabling the first user to communicate an evaluation of the second user to the second user in the online dating environment.

11. The method of claim 1, further comprising at least one of:

the first user employing a mobile device to specify the predefined status in the online dating environment; and
the second user employing a mobile device to communicate with the first user in the online dating environment.

12. The method of claim 1, wherein the message comprises at least one of an email message, an instant message, and a short message service (SMS) message.

13. The method of claim 1, further comprising:

determining that the first user identified the second user in the online dating environment and the first user indicated an interest in the second user prior to communication of the message from the second user to the first user; and
notifying the first user and the second user of a mutual interest.

14. A system for tracking a status of a user, comprising:

a transceiver for receiving and sending information to another computing device;
a processor in communication with the transceiver; and
a memory in communication with the processor and storing data and machine instructions that cause the processor to perform a plurality of operations, including: determining whether a first user specified a predefined status of availability within an online dating environment; and if the first user specified the predefined status, automatically providing an indication of the predefined status of the first user to a second user in response to a message from the second user to the first user in the online dating environment.

15. The system of claim 14, wherein the predefined status indicates at least one of an availability and an interest in further communication in the online dating environment.

16. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of enabling the second user to identify the first user in the online dating environment prior to communication of the message from the second user to the first user.

17. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of enabling the first user to provide an interim response to the message from the second user.

18. The system of claim 17, wherein the interim response indicates a level of interest in further communication with the second user.

19. The system of claim 17, wherein the interim response comprises at least one of a request for additional information about the second user, an indication that the first user desires time to think about further communication with the second user, an indication that the first user is not interested in further communication with the second user, and an indication that the first user is interested in further communication with the second user.

20. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of storing the indication and enabling the second user to track the indication with a plurality of other indications from other users.

21. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of storing the message in a thread of communication between the first user and the second user.

22. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of enabling at least one of the first user and the second user to enter a note in the online dating environment.

23. The system of claim 14, wherein the machine instructions further cause the processor to perform the operation of enabling the first user to communicate an evaluation of the second user to the second user in the online dating environment.

24. The system of claim 14, wherein the message comprises at least one of an email message, an instant message, and a short message service (SMS) message.

25. The system of claim 14, wherein the machine instructions further cause the processor to perform the operations of:

determining that the first user identified the second user in the online dating environment and the first user indicated an interest in the second user prior to communication of the message from the second user to the first user; and
notifying the first user and the second user of a mutual interest.

26. A client device that is configured for use in tracking a status of a user, comprising:

a display;
a transceiver for receiving and sending information to another computing device;
a processor in communication with the display and the transceiver; and
a memory in communication with the processor and storing data and machine instructions that causes the processor to perform a plurality of operations, including: enabling a first user to specify a predefined status within an online dating environment; receiving a message from a second user who identified the first user in the online dating environment; and enabling the first user to provide an interim response to the message from the second user in the online dating environment, wherein the interim response is one of in addition to, and alternative to a predefined message associated with the predefined status specified by the first user.

27. The client device of claim 26, wherein the client device further comprises a mobile device.

28. The client device of claim 26, wherein the interim response indicates a level of interest in further communication with the second user.

29. The client device of claim 26, wherein the machine instructions further cause the processor to perform the operation of storing the message in a thread of communication between the first user and the second user.

30. The client device of claim 26, wherein the machine instructions further cause the processor to perform the operation of enabling the first user to enter a note associated with the second user in the online dating environment.

31. The client device of claim 26, wherein the machine instructions further cause the processor to perform the operation of enabling the first user to communicate an evaluation of the second user to the second user in the online dating environment.

Patent History
Publication number: 20060059159
Type: Application
Filed: Feb 11, 2005
Publication Date: Mar 16, 2006
Inventors: Vu Hao Thi Truong (Sunnyvale, CA), Maurice Clancy (San Francisco, CA), Egon Smola (Mountain View, CA), Wei Wang (Atherton, CA), Tracy Rocca (Alameda, CA)
Application Number: 11/057,075
Classifications
Current U.S. Class: 707/10.000
International Classification: G06F 17/30 (20060101);