CA 02513306 2005-08-09
09/08/05 Yaron Mayer 1 /98
System and method for searching, finding and contacting dates on the Internet
in
instant messaging networks and/or in other methods that enable immediate
finding and creating immediate contact.
This patent application is a continuation-in part of US application 10/328,088
of Dec.
20, 2002, hereb i~rporated by reference in its entirety, which is a
continuation-in-
part of PCT application PCT/IL 01/00572 (which claims priority from Israeli
patent
application 136945 of June 22, 2000 and from US provisional latent application
60/214,003 of June 26, 2000) and of US application 10/086,216 of Feb. 20,
2002, and
which also claims benef t and priorities from the following US Provisional
patent
applications, hereby incorporated by reference in their entirety: 60/359,554
of Feb.
19, 2002, 60/370,631 of Apr. 2, 2002 & 60/376,235 of Apr. 24, 2002.
This patent application is also a continuation-in part of US application
10/086,216 of
Feb. 20, 2002, here incorporated by reference in its entirety, which is a
continuation-in-part of the above PCT application PCT/IL 01/00572.
This patent application is also a continuation-in part of US application
10/621,509 of
Jul. 18, 2003, hereby incomorated b~ reference in its entirety, which is also
a
continuation-in-part of the above applications, and which claims priority also
from
Canadian application 2,419,120 of Feb. 18, 2003, and from Canadian application
2,432,811 of Jul. 2, 2003, and from Canadian application 2,432,817 of Jul. 4,
2003,
hereb i~ ncorporated by reference in their entireties.
This patent application is also a continuation-in part of and claims priority
from US
application 10/913,392 of Auk. 9, 2004, which is also a CIP of the above
applications
and which claims~riority from Canadian application 2,437,456 of Au~. 8, 2003,
and
from Canadian application 2,437,451 of Aug. 13, 2003, and from Canadian
application 2,440,398 of Sept. 5, 2003, and from Canadian application
2,443,036 of
Sept. 14, 2003, and from Canadian application 2,455,342 of Dec. 17 2003 and
from
Canadian application 2,452,778 of Dec. 29, 2003, hereby incorporated by
reference in
their entireties.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 3/98
Background of the invention
Field of the invention:
The present invention relates to instant messaging and computer dating on the
Internet, and more specifically to a system and method for computer dating in
the
context of instant messaging, and/or in other methods that enable immediate
finding
of potential dates and creating immediate contact.
Back~~ound
Computer dating means matching people by computer after filling a
questionnaire
which typically contains a description of a list of attributes in themselves
and a list of
attributes that they want in their ideal date. Such services have existed on
the Internet
for a number of years.
Instant messaging is a relatively new technology, in which people are able to
find
instantly if any individuals in a specified list of friends or acquaintances
are logged in
to the Internet at a given time and, if so, communicate with them instantly.
This
technology is typically based on the principle of the client program sending a
very
short message (with the user's unique id number in the instant messaging
network) at
relatively short intervals (such as for example once a minute) to a central
server or
servers whenever the user is logged-in to the Internet and the client program
is
activated. This way, when these messages cease, the servers) knows that the
user is
no longer connected, even if he did not terminate the connection properly.
When users
know that they are online at the same time, they can start exchanging instant
messages
or open real time textual online chat. The 3 most known instant messaging
networks
on the Internet today are ICQ, AOL's Instant Messenger, and Microsoft's MSN
Messenger.
However, when searching for new people, the current instant messaging networks
typically allow users to search mainly by name or by e-mail and some of them
also by
interests, although one of them (Odigo) allows to search also by sex, age,
area,
languages, occupation & interests. However, to the best of my knowledge there
is no
way to systematically search in these networks for compatible dates by
attributes such
as for example education, general background, appearance, attitudes, and
personality,
or by reciprocal compatibility in any of the above mentioned attributes. This
is a
waste of a huge potential since some of these networks already have more than
dozens
of millions of people. Also, Odigo allows searching only among people
currently
connected, which means that highly compatible dates can be missed just because
they
don't happen to be Online at exactly the time of the search. Also, Odigo does
not
show people by order of compatibility. Adding such features to instant
messaging
systems would be a significant improvement over the prior art in instant
messaging
systems and in computer dating systems.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 4/98
This ability for instant contact is important also because one of the things
that are
missing in online computer-dating systems is the ability to have a systematic
search
for reciprocally compatible dates immediately a8er filling the questionnaire,
and then
being able to contact immediately the compatible dates, such as for example by
getting their phone number or being able to instantly communicate with them
through
the Internet. Typically computer dating systems give usually only the e-mail
address
of compatible dates, or even worse - allow only to leave them a message in a
special
mailbox within the computer-dating system. This can be very bad because if a
normal
e-mail is not generated it can take a long and frustrating time to get a
response.
The only relevant patent that I saw is US patent number 5,963,951 by Gregg
Collins, granted Oct. 5, 1999. However, my opinion is that almost everything
in that
patent is either trivial or exists already in prior art. And yet he got the
patent. The
Present invention is much more sophisticated and with much more advance over
the
prior art. Another relevant patent, which was found in the International
Search Report,
is US patent 6,272,467, issued on Aug. 7, 2001, to Durand et. al. However,
this patent
claims in the background section that "it is believed that most computer
dating
systems fall into two basic types: ( 1 ) linear matching; and (2) one-way
compatibility
screening...This similar/non-similar type of matching fails to take into
account the fact
that persons may place different emphasis on a trait in others than on a trait
that they
themselves exhibit. Moreover, this type of matching fails to account for the
fact that
males and females place significantly different emphasis on the weighting of
factors
and also have significantly different tolerances for variability in factors...
prior
computer dating systems thus have failed to employ two-way matching and to
utilize
a numerical method of evaluating potential matches instead of similar/not-
similar
approach". This statement is clearly wrong because for example the present
inventor
has been running a computer-dating service based on two-way, reciprocal
compatibility, which also takes into account the importance for each question,
and
creates and reports compatibility scores (and also uses for example a minimum
compatibility threshold), at least since 1991 in Israel, and since 1995 in the
USA,
under the name "The Internet Computer Dating Service", in a web site
(http:/%computer-datin~com) which has been well indexed in major search
engines,
including for example yahoo, and publicized in the relevant news groups.
Therefore,
the main "improvements over the prior art" claimed in the above patent are
simply not
novel and exist in the prior art. Consequently, most of the claims in the
above patent
can be easily invalidated by prior art.
Summary of the invention
The present invention is a novel concept which applies computer dating to the
context of instant messaging, in a systematic and flexible way that to the
best of the
inventor's knowledge has never been done before. This system and method enable
the
user to search and find instantly compatible dates in instant messaging
networks on
the basis of attribute search or 1-way compatibility search or 2-way
compatibility
search instead of being limited to search only by the limited options
described above,
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 5/98
and to search either for potential dates that are currently Online or Offline,
and also
take advantage of many additional features, and especially features that are
based on
improved integration between computer dating and instant messaging. A further
feature of the present invention is that preferably at least in one embodiment
it can
work also across instant messaging networks, so that users can fmd each other
even if
they are members in different instant messaging networks. A further feature of
this
invention is that it can make the large instant messaging networks also the
biggest
dating services in the world. It can also help them start charging for
payments in the
future, after a sufficient number of users have also started using the dating
option. It
can help them grow even faster for example by increasing further the users'
motivation to recommend the system to additional friends, for example by
giving the
user more privileges, such as for example additional lists or credit points
for each
friend that they bring. This can be done for example by letting the user have
for
example a free membership for example for one or more months (or other
reasonable
period) for each new user that he/she adds to the service (or for example only
if the
friend pays for at least some subscription, or for example if the friend pays
then the
free extension is for a longer period) (preferably each new member gets
initially a free
trial period of for example a few days or one month or other reasonable
period),
and/or for example creating a preferably recursive MLM (Mufti-Level
Marketing), so
that for example each user can even make some profit as a preferably small
percent of
subscription fees paid by new users that he/she has brought to the service,
and
preferably for example, preferably to a lesser extent, also revenues from
additional
users brought by these additional users, for example until a certain
cumulative percent
(and/or for example until some maximum amount for example per new user) and/or
until a certain level in the tree. In this case, preferably this structure can
be traced by
the users for example on the Internet so that each user can know preferably at
all
times how many "agents" are working in the logical tree below him/her at any
time
and/or preferably how much each of them sold and preferably what his/her
credit
status is at any time, etc. Another possible variation is that for example
each user is
encouraged to add a link to the IM network and/or related dating site from a
web page
and gets for example free membership and/or other benefits as long as the link
exists
(This can for example improve the placement of the site for example in search
engines
such as Google, even if the page itself does not bring much more traffic).
(Preferably
the users that make the link have to comply with specific text (for example in
the href
and/or near it) and/or icons that are approved by the dating service, but the
dating
service preferably makes available a sufficient number of texts and/or icons
which the
users can choose from). Another possible variation is that the added friend or
new
user preferably also gets some benefit, such as for example some reduction is
his/her
own subscription fees or some additional credit or for example some extended
free
period (preferably compared to new users who were not brought by other users),
so
that he/she does not feel that only the person who brought him/her gains
something.
Preferably users can add their friends for example by filling a form which
sends them
an email (in which case preferably the system checks and lets the user know if
the
friend is already in the system, and when each new user joins preferably the
system
automatically checks if that user has been added through one of these forms).
However, since people can tell their friends about the service also without
using the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 6/98
form for that, preferably also when filling the questionnaire the new user
preferably
has a field for indicating the name and/or email of the friend (or other user)
who
brought him if he/she was referred to the service by a friend (or other user).
Another
possible variation is to let each user for example press some icon (or for
example link
or key, or perform any other simple action) which automatically sends a
message
about the dating service to all the people in his/her IM contactee list, and
preferably
allowing him/her to do it also with other IM clients if he is using more than
one IM
service. (Of course, if the dating service is related to one of the leading IM
networks,
then the IM company itself can also send for example automatic messages about
the
dating service to all the existing members of the IM network). Another
possible
variation is to offer to users for example the chance to win free membership
for
example for half a year (or any other reasonable period) if they join within a
short
time (so that for example 1 in 5 users, or any other reasonable ratio, can win
this at
random). It might also be extended similarly to cover also chat networks such
as for
example IRC (for example by coupling an appropriate add-on to the IRC client).
The system and method are preferably based at least on two main elements:
1. A module (or modules) for filling and/or making changes to the computer
dating questionnaire, preferably containing self description, description of
the
ideal date, and the importance for each question. This module can be
implemented preferably as either:
a. An appropriate plug-in or add-on or element in a plug-in or add-on for
the client program preferably for each of the main instant messaging
networks where plug-ins or add-ons are possible,
b. A standalone application or part of a custom-made instant messaging
client.
The data filled by the user is then preferably either saved locally on his/her
computer, or sent to a central server (or servers), or both.
2. A search & instant messaging contact module or modules for finding &
contacting potential dates (For example by attribute search or reciprocal
compatibility search) who are currently Online and/or who can be added to a
contactee list (Preferably even if they are not currently Online) in order to
notify the user when they are Online again. Preferably, this module can be
either based on:
a. A suitable plug-in or add-on coupled to the client program preferably
for each of the main instant messaging networks where plug-ins or add-
ons are possible, that is preferably activated each time the user activates
said client program. Whenever this plug-in or add-on is activated,
preferably it first sends the user's compatibility questionnaire data to a
central server (or servers) (this is needed for example in case the
database of potential dates is dynamic and exists only during the time
that these people are logged in, or if the user has just filled the
questionnaire for the first time or made changes to it) and then
preferably sends only small packets of data containing at least the user's
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 7/98
unique id every certain interval. (Taking care of sending these short
messages may be done also by a separate element or plug-in or add-on).
When the user wants to search for new people to add to his contact list
for example according to attributes search or 2-way compatibility
search, preferably the search is done either on the dynamic database as
explained above or in a static database of users that filled the
compatibility questionnaire, according to different embodiments. The
system can (preferably in different embodiments, or as options in one
program) use either a static database or a dynamic one, or both - for
different types of searches and for efficiency considerations. However,
even if a dynamic database is used, at least minimal data such as for
example the user's name and e-mail and unique ID, is preferably kept
also in a central static database on the server. If the search is done on the
dynamic database (or on a static database with a request to ignore all
those who are not currently Online), the people found are already by
definition only people that are currently logged on. If the search is done
on a static database of people that filled the questionnaire without the
requirement that they be currently online, preferably the user can either:
1. Add them to the contact list on his normal instant messaging
client program, and then the user will be notified by the instant
messaging client itself whenever they are logged in. However, if
some of these persons are members of other instant messaging
networks, the user will need to ask them to join also the network
in which he/she is enlisted, otherwise he/she will not be able to
add them in this way.
2. Add them to a special contact list maintained by the plug-in or
add-on itself, and then the user will be notified by the plug-in or
add-on whenever they are logged in. This second option is better
of course, because it enables the user to be notified also if the
target people are members in instant messaging networks other
than the one the user belongs to. However, in this case the plug-
in or add-on preferably also includes an element that enables the
user to communicate and exchange instant messages with users
of other instant messaging networks, unless the user asks them to
join also his/her own network. Preferably, the plug-in or add-on
does this for example by using the same protocol for instant
message exchange between plug-ins or add-ons in all types of
clients for which we design a plug-in or add-ons. Another
possible implementation of this feature is that if the add-on is
based at least in part on a wrapper around the client or is more
fully integrated with the client, it can for example let the client or
part of the client act as if it is communicating with another client
of the same network or with its server, but translate the
communication to another protocol and/or redirect it, as shown in
Fig. 7. This has the advantage of letting the user continue
working with the interface and front-end that he/she is used to in
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 8/98
his/her favorite IM network. Preferably the system knows if
someone is Online either by contacting the appropriate server of
the IM network to which the client belongs, or, preferably in a
different embodiment, by using our own server and generating
our own repeating signal from the client. This is no problem,
since in order to participate in the dating, all users of the system
on other IM networks are using an appropriate plug-in or add-on
anyway, so they all can connect to the same server and use the
same protocol for the repeating signal.
Both if the search was only for people currently online or also people
offline, preferably the user can similarly add any of the people that
came up in the search to his/her list of contactees in any of the ways
explained above - so that he/she can be automatically notified when
they are Online again the next time (Preferably the user may for
example click on them one by one or mark a whole group for adding).
Preferably this notification is by at least one of the following ways:
When the user is using the client program preferably the program
indicates to the user visually and/or by an attention getting sound
when a compatible date that is on the contactee list (and/or for
example on the list of compatibility search results) becomes online.
Another possible variation is that if the user himself/herself is not
currently Online, the user can be automatically notified for example
by SMS or by email or by preferably automatic phone call when such
a date becomes online or for example at least for dates which the user
marked as especially important to him/her or requested to be
especially notified about them.
b. A complete or independent instant messaging application that works
like a normal instant messaging client connecting to a main server or
servers, with the added features of being able to search for users for
example by attributes or by 1-way or 2-way compatibility. Preferably,
the system can also similarly use either a static database or a dynamic
one, or preferably both - for different types of searches and for
efficiency considerations (preferably in different embodiments), and
have features as described above. However, even if a dynamic database
is used, at least minimal data such as for example the user's name and e-
mail and unique ID, is preferably kept also in a central static database
on the server. This complete application can be either a stand-alone, or a
plug-in or add-on coupled to a major Internet communication program,
such as for example one of the big browsers, or for example an integral
part of the browser, so that for example the IM client (or at least part of
it) and/or the part of the client that deals with dating are integral parts of
the browser.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 9/98
Definitions and clarification
Through out the patent whenever variations or various solutions are mentioned,
it is also possible to use various combinations of these variations or of
elements in
them, and when combinations are used, it is also possible to use at least some
elements in them separately or in other combinations. These variations can be
in
different embodiments, or different versions of the software, or sometimes
different options available to choose from. In other words: certain features
of the
invention, which are described in the context of separate embodiments, may
also
be provided in combination in a single embodiment. Conversely, various
features
of the invention, which are described in the context of a single embodiment,
may
also be provided separately or in any suitable sub-combination.
As used throughout the entire specifications and the claims, the following
words have
the indicated meanings:
"Client" or "Client program" is an application that runs on the user's
computer and
communicates with a server or servers, usually on the Internet. In the context
of this
invention, Client means Instant Messaging Client, unless stated otherwise.
"Server" or "Servers" as used throughout the patent, including the claims, are
always
meant interchangeably to be either server or servers. "Server" is a computer
on a
network that is running software (or the software itself) that provides data
and
services to clients over the network (which can be any kind of network,
including the
Internet).
"Our client" or "Our own client" refers to a custom-made instant-messaging
client
with the features of this invention built-in.
"Our server" or "Our own server" refers to a custom-made instant-messaging
server
with the features of this invention built-in.
"Standalone" is an application that runs on it's own.
"Plug-in" is an application that runs as part of or as an addition to another
application
and is called from it when needed. "Add-on" is a more general term than plug-
in and
refers to elements or features that are added to or coupled to a given
application in any
way possible, such as for example a plug-in or with a program that wraps
around it, or
in any other way allowed by the application or by the operating system. As
used
throughout the text of the patent, including the claims, these terms are meant
to be
interchangeably either plug-in or add-on.
"Plug-in" or "Plug-ins" as used throughout the patent, including the claims,
are
always meant interchangeably to be either Plug-in or Plug-ins
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 10/98
"Add-on" or "Add-ons" as used throughout the patent, including the claims, are
always meant interchangeably to be either add-on or add-ons.
"User" or "users" as used throughout the patent, including the claims, can
interchangeably to be either user or users, and can refer to both sexes even
when
words such as "he" or "she" or "his" or "her" are used.
"Dynamic Database" as used throughout the text, including the claims, means
that the
data from the users questionnaires is kept on the server or servers only as
long as they
are Online, so when a user becomes Online again his/her data is resent from
his/her
client program to the server.
"Static Database" as used throughout the text, including the claims, means
that the
data from the users questionnaires is kept on the server or servers also when
they are
not Online, and preferably their Online/Offline status is kept as part of
their records or
in a separate file or pointer or index. Of course 'static' does not mean that
the data in
the database doesn't change - data can be updated as often as needed.
"Database" or "Databases" or "DB" as used throughout the patent, including the
claims, are always meant interchangeably to be either database or databases.
"Contactee list" or "Contact list" or "Buddy list" refers to the list of
people for which
the user wishes to be notified when they are Online.
"History list" in instant messaging systems is the list of previous messages
exchanged
between the user and a given contactee.
"IM" is short for Instant Messaging.
"Cellular phone" or "mobile phone" or "wireless phone" as used throughout the
patent, including the claims, can mean any device for communications through
wireless and/or cellular technology, including for example Internet-enabled
cellular
phones, such as for example the Japanese DoCoMo, 3'd Generation cellular
communication devices, palm computers communicating by cellular and/or
wireless
technology, etc.
"Computer" as used throughout the text of the patent, including the claims,
can refer
to a personal computer, or any automated device or gadget with one or more
processor or CPU, capable of more than simple arithmetic functions. This
includes for
example also cellular phones and portable computing devices such as for
example
palm pilot.
"Online" or "logged-on" or "logged-in" as used throughout the text of the
patent,
including the claims, in the context of IM networks means that a user is
connected to
the Internet, with the IM client open, unless for example the contact has been
open for
a long time and the user hasn't typed anything (or clicked or responded or
shown any
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 11/98
other type of activity). In the context of Online Computer Dating Services it
means
that the user has logged into the system for example with his/her user name
and
password not longer than a certain time ago (for example within the last 20
minutes or
any other reasonable time frame), and/or the user has performed at least one
activity
in the system (such as for example view data, change data, or perform a search
for
compatible dates) not longer than a certain short time ago.
"Internet" is the Internet as it is now, or any other similar network that
exists or will
exist in the fixture.
"Self Description" or "Self data" throughout the text, including the claims,
means the
answers the user gives about himself/herself in the Dating Questionnaire.
Except for
some special questions, the user can preferably choose just one answer in each
question for his/her self description. For example, the user marks that he has
dark hair
in the question about hair color.
"Desired date", "Ideal date", "Preferences" or "Wanted" throughout the text,
including the claims, means the answers the user gives about the optimal and
acceptable levels he/she wants to have in the desired date in each question.
Preferably,
the user can choose more than one option in the "wanted", and preferably also
specify
the level of desirability of each option that he/she prefers. For example in
hair color
the user may want Blonde girls with higher desirability and red hair with
lower
desirability.
"Importance" or "Weight" means the level of importance the user gives each
question, for example: Doesn't matter, Slightly important, Important, Very
important,
Extremely important, or Necessary.
"2-way compatibility" means that the matching is done by taking into account
both
the user's self description and preferences and each potential date's self
description
and preferences, and preferably also the importance given by each of them to
each of
the questions.
"1-way compatibility" means that the matching is done at least by taking into
account
the user's preferences and each potential date's self description and
preferably also
the importance the user gave to each question. However, preferably even when
conducting 1-way search, the system actually does a 2-way search, in order to
check
that the user also fulfills the potential date's expectations by at least a
certain
minimum, preferably defined by the system. Since the dating questionnaire is
preferably long, containing for example above 100 questions, preferably when
conducting 1-way or 2-way searches the data is used directly from the saved
questionnaire.
"Attribute search" means that the user just marks a certain preferably small
number of
attributes that he/she wants to search for in the potential dates. The
importances for
this small set of preferences can be for example assumed to be necessary, or
in
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 12/98
another possible embodiment the user can specify the importances even in this
case.
Preferably this fast search is either conducted by ignoring the user's self
description,
or conducted similarly to the 1-way search described above, except that the
attributes
are preferably defined by the user on the fly and used instead of his/her full
list of
preferences. Preferably, the results of the attribute search can be for
example just
dates that fulfill a 100% of the requests, or any percent above the defined
minimum
like in the 1-way and 2-way searches.
"Frozen" means that a certain user does not receive compatible dates lists and
does
not appear on other users' lists until the user requests to be unfrozen or the
system
decides that a certain event has occurred that justifies unfreezing him/her
(for example
if the user has reentered the system after being Offline for a long time and
the freezing
was done automatically by the system due to lack of activity and not due to a
specific
request by the user).
Brief description of the drawings
Fig, la shows a preferable structure of the client-server system in the
instant
messaging network, with the part that implements the dating.
Fig. 1 is a schematic diagram of a preferable way the questionnaire-filling
application
works as a plug-in or add-on within an instant-messaging client.
Fig. 2 is a schematic diagram of a preferable way the questionnaire-filling
application
works as a standalone application or as part of a custom-made instant
messaging
client.
Fig. 3 is a schematic diagram of a preferable way that a dynamic database of
users
that are currently Online works.
Fig. 4 is a schematic diagram of a preferable way that a static database of
users that
filled the compatibility questionnaire works.
Fig. 5 is a schematic diagram of a preferable way the search plug-in or add-on
conducts attribute and compatibility searches within the context of the
instant
messaging client.
Fig. 6 is a schematic diagram of a preferable way attribute and compatibility
searches
are conducted within a custom-made instant messaging client.
Fig. 7 is a schematic diagram of a preferable way that the add-on can for
example let
the client or part of the client act as if it is communicating with another
client of the
same network or with its server, but translate the communication to another
protocol
and/or redirect it to the other network.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 13/98
Fig. 8 is an example of a preferable way that the extended contactee list can
look like.
Fig. 9 is an example of a preferable way that the list of most compatible
dates
following a reciprocal compatibility search can look like.
Fig. 10 is an example of a Javascript computer-dating questionnaire which
shows
each time one question and uses elongated radio and checkbox buttons.
Detailed description of the preferred embodiments
All of descriptions in this and other sections are intended to be illustrative
examples
and not limiting. The system and method described may be also regarded as a
virtual
machine that performs the described functions.
Fig. la shows a preferable structure of the client-server system in the IM
network,
with the part that implements the dating. The instant messaging client (2)
runs within
the user's computer ( 1 ), and, if it's not a custom-made client, is
preferably coupled to
a plug-in or plug-ins or add-on or add-ons (3) for adding the special features
of the
present invention, otherwise the parts that implement these features in the
client are
part of the client itself. The user's computer (1) is connected through
connection (4)
to the Internet (5), where our servers) (6) (with dynamic or static databases)
or both
(7)) reside. The database (no matter if dynamic or static) is of course
preferably run
by the server, and all date searches are preferably carried out there,
although there can
be for example a separation between the server (or servers) that handles the
IM
activity, and another server (or servers) that run the actual dating database
and
perform the searches and compatibility matches, etc., and return the results
to the
requesting client programs.
Preferably the system also has at least one or more of the following
improvements
over existing Instant Messaging systems:
1. The contactee list is preferably run by the client program (2) in the
customary
shape of a table, but preferably indicates also preferably near each contactee
additional data such as for example the last date & time he/she was online (in
the instant messaging network) and/or the most common range of hours and/or
week days he/she is most likely to be found online (In another variation this
can be a more crude time range, such as for example, morning, noon,
afternoon, early evening, late evening, and night), and/or for example the
last
time he/she performed a search for potential dates in the system (preferably
the
client program automatically gets these updates from the server when the user
is Online), and/or geographical area (or for example some relative distance
estimate compared to the user), and/or the compatibility scores, and/or how
often they are usually online (such as for example how many hours on average
per week or per day). This is very important since many times, and especially
if the user has not used the system for some time, it is very hard to tell
which
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 14/98
of your contactees are still available and when it is likely to encounter
them.
Preferably near each contactee is listed also the last time contact was made
with him/her and/or for example the length of his/her history list.
Preferably,
the table of contactees contains also a visible status indication about each
person - for example if he/she is still looking for romance or other types of
connection, etc. Preferably these additional data fields are visible by
default
near each contactee without having to click on anything in order to see them.
An example of a way the contactee list can look like is shown in Fig. 8. Of
course, like other features of this invention, these features can be used also
independently of any other features of this invention, so that for example at
least some of these additional data (such as for example the last date & time
the contactee was online, the most common range of hours and/or week days
he/she is most likely to be found online, and/or how often he is usually
online)
can be used also in contactee lists of IM networks that are not integrated
with
dating. Of course it is also possible for example to keep a separate contactee
list only for contactees that were added through the dating, instead of
keeping
them for example in a separate sub-list as shown in the example of Fig. 8, but
that is less preferable.
2. Preferably the user can choose if to sort the contactee list according to
alphabetic order, compatibility score (at least for those contactees that were
added through the date-searching), or any of the other data mentioned in
clause
1 above, or additional data, or any combinations of these.
3. Preferably the user has the ability to know how many people have him/her in
their contactee lists and/or for example how many people received him/her in
their dating lists. This is very easy to accomplish since either the user's
client
program or the server or both can for example increase a counter or decrease
it
whenever someone adds or deletes the user. Another possible variation is that
the client program or the server or both can also keep a list of all the
people
that added the user to their contactee lists, so that the user can for example
send
messages that can be automatically distributed to all of them, and/or request
to
view the list of people that have him/her on their lists (preferably at least
their
names and e-mails and/or IM ids). So preferably the server and/or the client
program keep for each user also a "reverse" contactee-list, which lists all
the
other users who added him/her to their list and haven't deleted him/her yet.
Another possible variation is that the server keeps only a copy of each
contactee list and when needed the server runs over these lists and searches
them, preferably with the aid of an index. (Of course, if the act of adding
someone to the list of contactees is reciprocal, then the client program can
know automatically that you were also added to their list, but this is not
necessarily so, especially in cases that the person has not limited adding him
to
the list to requesting explicit authorization. Also, even if the adding to the
contactee list could in some systems be automatically reciprocal, there is no
reason why the deletion should be like this: if person A deletes person B from
his list, it does not necessarily mean that person B wants to delete person A
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 15/98
from his list, so the deletion process would make it non-trivial to know on
which or on how many contactee lists you are actually listed). Another
possible
variation is that the system automatically indicates near each person in the
user's contactee list and/or in his/her date-search results list if that
person has
already added the user to his/her own contactee list. Another possible
variation
is that when someone adds the user to his/her contactee list, the user gets a
preferably instant automatic notification about this and is preferably
automatically invited (for example with a link or icon to press) to view the
other person's data and/or the compatibility score with the other person
and/or
to make the link reciprocal. The instant notification can be for example by
any
of the methods for instant notification described in this application.
However,
if such automatic notification is used, preferably the adding user has also an
option to suppress the automatic notification to the added user (for example
as
a default choice that will be used also for the next people that he/she adds
to
his/her list, or for example the user has to request this suppression
explicitly in
each case, in order to encourage people not to interfere with this
notification).
(However, suppressing this automatic notification preferably does not change
the ability of users to view their reverse contactee lists, as explained
above).
Also, the user can preferably also suppress for example such automatic
notifications to him/her.
4. Preferably, if someone changes his/her status for example from "available
for
dating" to non-available, etc., this is automatically broadcast (for example
by
the client program of that user or by the server) to all the people who have
him/her on their contactee list, so that his/her status is updated on their
lists
(This can be done for example by an automatic message directly from that
user's client program that updates the client programs of these people when
they are Online and if they are Offline preferably waits for them till they
are
Online again, or for example done similarly through the server). This updating
is of course preferably in addition to making the person not appear in
fixrther
date searches by others if the change in status implied this (until the status
allows this again) - for example if he/she is in a relationship, etc. Another
possible variation is that preferably each user can also remove
hirnself/herself
automatically from all the contactee lists where he/she is listed and/or at
least
for example block certain users for example by being deleted from their
contactee lists or by making the system never let them know that the user is
online. However, these, like other features, can preferably be used only with
a
password and/or other safety means so that no other users can make such
changes in the user's name by pretending to be the user.
5. Preferably when the matching potential dates are found, they are listed by
descending reciprocal compatibility score. However, since there can be a large
variance between the way people mark the acceptable ranges in the "Wanted"
in each question and the way they mark the importances of questions, the score
of how much someone fits the user's expectations can depend very much on
the general bias of the user, in other words his/her tendency to be more or
less
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 16/98
"generous" in general in his/her scores. Therefore, in order to create a
certain
minimum normalization, preferably for sorting by reciprocal score, the score
of
how much the potential date fits the user's expectations is preferably given
stronger weight (and thus effects more the reciprocal score, which is a
weighted average) than how much the user fits the potential date's
expectations. Another possible variation is to create some normalization of
this
by taking into account for example the average 1-way score that the user gives
compatible dates and his standard deviation, and thus either use normalized
scores, or use the normalization to create only a partial correction of the
absolute scores. This is more preferable than full normalization because the
fact that someone gives generally higher scores to everyone can also mean that
he/she is really more open and more fit for many people than someone who
gives lower scores in general. This can have the effect of automatically also
reducing the number of times such a person appears on other users' lists, in
order to improve the balance. If such normalization is used, preferably the
relevant data, such as for example average score and standard deviation is
saved in the date's record, preferably following his/her own searches, so that
it
is immediately available without further calculation the next time that date
is
matched with someone. Another possible variation is for example to
automatically limit at least temporarily the number of times the user can
appear
on other users' lists if his/her number of appearances in other lists has gone
beyond a certain excess limit defined by the program (preferably in terms of
percentages, since the absolute numbers change as the database grows).
Preferably such a limitation can be for example defined automatically by the
system and/or for example specified by users who request such limitation.
Another possible variation is to allow the user to specify more than 2 levels
of
acceptability, for example 3 levels (For example: optimal, desirable and
acceptable). This can increase the flexibility and allow a better
approximation
to the real curve. In addition to this, preferably if a user's compatibility
scores
are generally low beyond a certain criterion, preferably the system can report
to the user (for example automatically or upon the user's request after
displaying this option) the list of questions that most contributed to the
problem (for example the 10 questions that most lower his scores with other
people, or all the questions that contributed more than a certain factor to
towering the scores, preferably in descending order of magnitude of effect
and/or for example in descending order of the importance of these questions to
the user). This can be done for example by letting the matching program that
runs on the server keep statistics for each user while running him/her against
the potential dates, so that the statistics track the questions that are most
problematic. Another possible variation is to run this statistical check only
upon request and/or only on a subset sample of potential dates in order not to
slow down the normal matching process when running the search on all
potential dates. Another possible variation is to allow any user, even if
there is
no problem, to request and view for example a similar list of all the
questions
that had most effect on lowering or on adding to the compatibility scores,
preferably in descending of magnitude and/or importance. Another possible
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 17/98
variation is for example to give the user also the option of choosing sorting
by
1-way compatibility scores, and in that case preferably the user will get
someone only if the opposite 1-way compatibility score is above a certain
minimum, preferably a minimum set by the system and not by the user. (In
other words you can request a sorting by how much the mate fits your
expectations, but you will only be allowed to get mates whose expectations
you also fit to a certain minimum). Preferably in this case the search results
list
shows also the reverse compatibility for each date. Of course these options
can
be used also in normal computer-dating systems. As mentioned above,
preferably the user has also the option to request just a search by a list of
traits,
which is in other words a 1-way compatibility but typically on a small number
of traits and without necessarily checking the opposite 1-way score, but in
this
case preferably the system can for example create various limitations such as
for example that persons who don't fill the questionnaire completely (or at
least a minimal subset of required questions) cannot participate at all in
searches by others, etc., or for example not giving the person's phone, etc.,
in
order to reduce the chance for harassment if the search ignores the reverse
compatibility. So if the questionnaire has for example about 150 questions,
preferably the users can have a very systematic and serious compatibility
search, but also experiment with instant searches especially when first trying
out the system, by filling just the Wanted and the Importance in the few
questions that most interest him/her, and thus start getting results already
from
the first minutes. So for example within minutes after entering the system for
the first time, the user can search for example for all the blondes with high
IQ
and a big bust that are either currently online or not. Allowing such huge
flexibility is very important because each persons can want very different
things so a very large number of questions to choose from is preferably given
to the user, eventhough the user might choose for example just 3-10 questions
to start with, but these are the few questions most important to him/her.
(When
choosing this option after the user has already filled the full questionnaire,
preferably these requested traits are used instead of his preferences as
marked
for the full questionnaire, and his self data from the questionnaire can
preferably either be taken into consideration or not, or taken into
consideration
at least partially, depending on the type of search or other considerations).
Another possible variation is to allow any two users of the system to check
the
exact compatibility between them, for example by entering their two unique Id
numbers and thus get normal compatibility scores or for example an even more
detailed analysis (Of course the detailed analysis can preferably be requested
by one or both of the users, however the level of analysis can preferably
reveal
more if it is requested by both users). Such more detailed analysis might
include for example the lists of questions that most contributed to or reduced
their compatibility scores (preferably in descending order of magnitude of
affect and preferably with an indication of the points or percents added or
deleted from the score by each such question), and/or for example a numeric
and/or verbal and/or graphic display of the level of matching on each question
(if a graphic display is used then preferably for example the color and/or
size
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 1$/98
and/or shape of the marks can show the level of matching on each question
and/or the importance of that), listed for example in the original order of
the
questionnaire, or for example sorted in descending order of importance or for
example in descending order of matching, so that the most highly matching
question are listed at the top. The above lists can be either separate, for
example one list or group of lists for showing the 1-way matching to the first
person and a 2°d list or group of lists for showing the opposite 1-way
match, or
the lists might be combined, so that for example the questions are listed only
once and for example only the reciprocal match is shown for each question, or
also the 2 1-way matches. Another possible variation is to include in this
analysis for example also the serial position of each of the two persons on
the
other person's list, in other words, how many other persons with higher
compatibility exists (for example there are 125 other potential dates with
higher compatibility than the 2°d person for the 1St person, i.e.
he/she would
appear on the 1 S' person's list at the 126th place, and there are for example
80
other potential dates with higher compatibility than the 1 S' person for the
2°d
person). (Another possible variation is that this position of the user in the
other
person's list can be automatically shown also for example near each date that
the user gets, but this would be more problematic since for efficiency reasons
it
would be preferable to keep for this at the server the list of results for
each date
from the last time it was run, so such a list might not be updated enough, and
also each user might generate his/her list according to different criteria).
Another possible variation is that the user can for example request to sort
the
results according to preferably any one or more specific questions that exist
in
the questionnaire, so that the user can for example request to view the girls
in
descending order of IQ and/or for example descending order of bust size.
Although, as explained above, preferably at least in some embodiments a
similar result can be obtained anyway by filling for example only these two
questions in the search request, this is more flexible, since the user can for
example either request to take into account only these questions in the
search,
or for example get results with detailed compatibility scores on a large
number
of questions, but still request for example to sort the results according to
one or
more specific questions. (In this case preferably within compatible dates who
are in the same position according to the sorting questions, the internal
order is
preferably sorted by the compatibility scores). This way the user can for
example use freely any small number of questions for a 1-way search, but still
preferably get also a reciprocal compatibility score with each of the
potential
dates that appears in the search results, for example according to all the
questions. Preferably the user can also be told for example for each question
or
for each search results exactly how many potential dates fit the request, even
if
for example only a small number of dates is shown at each step in the list. Of
course, various combinations of the above variations are also possible.
6. Preferably, if the user requested a search also on people who are not
currently
Online, those that are Online appear in the list of results with a preferably
easily visible mark, such as for example a different color indication and/or
text
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 19/98
size and/or shape and/or special icon, or for example two or more separate
lists
are generated (or one list divided into two or more parts), one with people
currently online and one or more with people not currently online. Within each
list or part of the list preferably the results are still ordered by
descending
compatibility score. Preferably near each person in the list of people not
currently online there is preferably also additional data such as for example
when they were last online and/or how often they are usually online (such as
for example how many hours on average per week or per day), and/or for
example on which hours and/or days they are usually online, as shown in the
example in Fig. 9. (Of course, this information can be shown for example also
if they ARE currently online) Another possible variation is that the list of
people who are not currently online can be further divided for example into
smaller parts, so that for example people who were online in the last week
appear in a section before people who haven't been online for example for
more than a month, etc. Within each section preferably the sorting is again
based on descending, preferably reciprocal, compatibility score. Preferably
the
size of each section can be determined automatically for example both by the
compatibility score and by the recency. Another possible variation is that
when
dealing with people not currently Online the system automatically tries to
come up with a list of most compatible dates (preferably in descending order
of
compatibility) who are most recent (for example people who joined or were
active within the last 3 months), and if the scores are not high enough and/or
the list is not long enough (preferably according to criteria determined by
the
system), the system automatically decides to create instead a list containing
also people who are less recent - for example people who were active within
the last half year, and so on in one or more steps, until the list is long
enough
and/or the scores are high enough and/or the recency compromise has reached
some time limit of going backwards enough (which can be specified for
example by the system and/or by the user, for example people who were active
with the last 15 months). If this variation is used then preferably it is done
very
efficiently for example by automatically keeping during the search conducted
for the user a table of most highly matching scores for each of the above time
steps (for example a table of the for example 150 highest scores for people
who
joined or were active for example within the last 3 months, a table of the for
example 150 highest scores for people who joined or were active for example
within the last 6 months, a table of the for example 150 highest scores for
people who joined or were active for example within the last 12 months, etc.),
and then the system can choose for example the table of the shortest period
which contains sufficiently high scores, and simply display to the user on
that
run only dates who joined or were active within that time frame (Of course,
the
above time steps and the table size of 150 highest scores are just examples
and
other numbers and time steps can also be used). Another possible variation is
that there are no separate sections according to recency, but the
compatibility
score itself and/or the sorting takes into account to a certain degree also
the
recency, for example according to a weight assigned for the recency factor,
determined either by the user or by the system or both. Preferably the mark
that
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 20/98
indicates if someone is currently online (and/or for example also the
availability status of each date, but that is less important since
availability for
dating typically changes much less often than being Online or not, so it will
be
updated anyway when the user performs a new search) can be automatically
updated also on the list of compatible dates, if the user for example saves
the
list or keeps the window of the list open, like in the automatic updating of
the
contactee list, as explained in the reference to Fig. 8. This way the results
list
can for example assume also additional functions of the contactee list, thus
becoming in a way a special contactee list for dating results. Of course
various
combinations of these and other variations are also possible. Of course many
of
the variations mentioned here and in other clauses can also be used in normal
computer-dating systems. An example of the way the results can look like is
shown in Fig. 9.
7. Preferably the client program can receive automatic updates from the
server, so
that for example if questions (or options within questions) were added or
deleted or changed in the compatibility questionnaire, it will be updated when
the user is online with the client program. (If for example new questions are
added, preferably each user is automatically invited to fill only the new
questions, so that for example preferably the new questions automatically
appear for example every time he/she becomes online or enters the dating site
or tries to perform certain acts in the site, such as for example perform a
search, preferably until he/she f lls them, or at least under some conditions
or
at least for a certain time period). This is important, since unlike normal
dating
services on the Internet, where the questionnaire is typically on the server,
in
this case, for efficiency the questionnaire can be in the client itself, which
also
enables filling or correcting the questionnaire also when you are offline.
Another possible variation is that the client program retrieves again a new
updated copy of the questionnaire when the user goes online. Preferably the
client program can also be itself updated automatically when needed, for
example by sending automatically new modules to all the users in the IM
network. This feature if it had existed in advance could for example be used
to
add the dating option to all the ICQ users in the world almost instantly (or
for
example to add additional features to it later), without waiting for them to
go
and download a new version of the client program. This is very important,
since even if users are informed about a great set of new features, it
typically
takes a long time till they go and actually download it, and the lag in
updating
causes incompatibilities between users who have already downloaded the new
version and users that didn't. It can be also much more efficient in terms of
bandwidth, especially if it is done for example with at least some of the
methods of optimization described in US patent application 10/375,208 of Feb.
17, 2003, by the present inventor. (However, for reasons of security, when
this
automatic update occurs, preferably the user is informed about it by the
system
and asked for confirmation).
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 21/98
8. Preferably, If the user is accessing the system from a client program on a
different computer then preferably after giving an Id and password, the client
program can get his/her questionnaire data and a copy of his/her contactee
list
from the server, so he/she can still work normally in the instant messaging
network. However, this means that a copy of each user's contactee list is
preferably kept also on the server.
9. Many of these concepts can also be similarly implemented also in cellular
phone networks, and especially in networks where the phones are constantly
connected and there is high bandwidth, such as for example in the 3G (3'a
Generation) cellular networks. In such networks, in addition to the normal
ability to send the person an e-mail or an instant message, preferably the
user
can also generate for example an SMS message, or generate a phone-call right
from the instant-messaging client. However, (both with cellular and non-
cellular phones) in case some people don't like to give their phone in the
questionnaire for example for fear of harassment, preferably the system
applies
an optional "phone proxy" or "phone escrow service", which means that the
user has an option to mark his/her phone as protected, and when someone gets
his/her phone on the list, that someone can call the user for example through
a
special visible code but the code does not contain the real number and the
call
has to go through the proxy. The call itself can be done for example by direct
activation though the client program (if it is done for example from a
cellular
phone connected to the Internet, or from a computer with a microphone and
sound card), or for example through phoning a special number and then
clicking the code, and the server there automatically routes the call to the
real
number. The call routing can then of course be through the normal phone
system, but is preferably done as much as possible by using VOIP (Voice Over
IP) preferably through the Internet at least part of the way, so that either
it
becomes a local phone-call, or for example the call is eventually routed to an
invitation to enter Voice mode if the called user is online and has a sound
card
with a microphone. This way various protections can be implemented, such as
for example allowing only a few first calls through the code and if the caller
does not get from the user his/her real phone number by then, he/she can no
longer use the code, thus automatically preventing harassments. The code can
also be for example uniquely generated for each person who conducted the
search, so that the code cannot be used by someone else. Also, since the code
can preferably be changed very easily, the user can preferably also request to
change it immediately if harassed by someone, so that someone can't use it
anymore even if the use limit hasn't been reached yet. Preferably this can
also
be used for example to enforce normal calling times and/or preferred calling
times specified by the user, so the system preferably uses the information
about
the country from the questionnaire and/or the time data from the system on
each user's computer or cellular phone, and using an updated table of time
zones, preferably when someone is calling through the code, the system makes
sure that the call will not be for example in the night hours of the person
being
called. Another possible variation is that even without a code, simply
clicking
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 22/98
for example on a phoning option near the displayed date can immediately
connect the user to that person without disclosing at this stage the number
itself. This has the further advantage that this clicking option is available
only
to the user, so there is no code that can be transferred to others. Of course,
such
a "Phone proxy" system can be used also in other Online computer dating
services that want to allow the user to get a list of dates which can all be
reached immediately by phone, so those that don't want to give the phone can
use the "protected phone" option. Although US application 20020106066 filed
on February 5, 2001 by Swanson (published August 8, 2002) describes an
anonymous telephone communications system, this works differently because
the Swanson method checks compatibility after the request for voice
communication is initiated, which is less efficient. Also, it was published
after
this feature was already included in the present invention. In addition,
preferably direct Voice communication over IP is available whenever two
clients are in chat mode using the IM chat features if they have a sound card
with a microphone. Of course, various combinations of the above variations
are also possible.
10. Another problem in such constantly connected cellular networks, and also
for
example in other constant Internet connections, such as for example through
cable TV companies or through ADSL, a new definition is needed about what
it means to be "online", otherwise everyone on those networks can be defined
as being online all the time (especially if the Instant messaging client is
configured to connect automatically when starting an Internet connection).
Therefore, at least in such networks preferably the user is considered to be
online for example only if he has initiated or responded to any action related
to
the Instant messaging client for example in the last hour (or any other
reasonable time) and/or is considered to be off line for example if he hasn't
typed anything on the computer for a certain time, etc. This means of course
that preferably the static and/or dynamic database is updated also according
to
these activity rules and not only when a user activates or deactivates the
client
or the connection. Another possible variation is to use these or similar rules
also in any type of connection, as explained also in the definition of
"Online"
in the definition section.
ll.In cellular networks preferably the system contains also additional
features,
such as for example being able to get a special indication if someone is very
near to the user, for example within a certain radius. This can be
accomplished
for example by using info from the cellular company's cells, and/or by using
this info directly from the phones, for example when they become GPS
enabled. This way the user can know for example that some compatible date is
very close to him/her (for example by a special mark in his list of search
results
and/or in his contactee list). Another possible variation is for example that
if
the user sees someone that he/she likes and both have cellular phones and are
members of the system, then preferably a certain optical or wireless signal
generated by the phones themselves can tell the user through the status if the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 23/98
person next to him/her is available, and preferably the two phones can
exchange Id's or numbers automatically and/or the questionnaire data directly
and thus the client program can immediately run a check (preferably through
the server) to see how compatible the two persons are. Preferably this is done
by a short range wireless technology, such as for example Bluetooth, since
Bluetooth technology will probably be standard on most cellular phones within
the next few years, but it can also be any other short range wireless
technology
that is used or will be used in the future, such as for example UWB (a pulse-
based technology, without a carrier-wave), which can easily compete with
Bluetooth. Another possible variation is that the client program on each or at
least on one of the phones or cellular devices can run the matching between
the
user and the potential dates in the immediate area without the need to access
the server for this, for example by running a local, preferably limited,
version
of the matching program and preferably limiting the check to the one or more
relevant persons around. Therefore, this feature can be used also
independently
of the IM network and/or of the online dating service, for example by simply
letting cellular phones that are close to each other and are marked by their
user
with the status "available for dating" - exchange data and/or check
automatically compatibility and alert the user anytime he/she is close to
someone available for dating and compatible. A more limited implementation
of this that does not even need a real matching program is for example to use
this method just to let the user know that someone next to him/her is
available
for dating, or use it for example with a minimum amount of data, such as for
example age, sex, education, etc. If the match is sufficient, then preferably
for
example the user or each of the matching persons gets at least a few minimal
details about the other person's appearance (such as for example Appearance,
Height, Body build, Hair length, Hair color, Hair shape, etc., and/or a
picture,
if available, or "approximate image" if available, as explained below in
clause
16, if no real picture is available) in order to be able to try and match this
with
what he/she sees around, and the other person's phone number (or "proxy
number", as explained above, and/or an option to click for example on a phone
icon near the date's data and be connected immediately), and/or be able to
enter for example immediate textual chat with the other person. This can be
useful for example at a university, on a bus, on a train, in shopping malls,
etc.
Another possible variation is that the phone (or other mobile device) can use
for example the GPS of its own position and the position of the potential date
and use for example its own north-west or compass direction, in order to point
to the user the direction and distance to the potential date that was found,
or for
example use also geographical information such as for example a street map
(obtainable for example from the nearby cells), in order to let the user know
more exactly the location of the potential date. Another possible variation is
that the cellular phones (or for example palm or other relevant cellular or
wireless devices, as explained in the definitions) are able to exchange
various
queries between them. For example each user can mark that out of the large
number of questions to choose from there are for example 5 questions which
he/she would like to know in advance: for example, apart from is the other
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 24/98
person available for dating, what is his/her level of education, what is
his/her
main area of work or study, etc. Preferably the user can also send the query
with additional specifications in order to increase the chance that the reply
will
come from the right person. For example in a bus or train or university
cafeteria or library there can be dozens or even hundreds of people within
range. So if for example it is a blonde girl that looks a certain age,
preferably
the user can ask for example that only the devices of blonde girls that are
available for dating and within a certain age limits reply. The query is then
preferably transmitted by the bluetooth (or other short range communication)
to all the devices in the vicinity that are in range, and each device checks
if its
user is marked available for dating, and then if he/she fits the definitions,
before broadcasting the reply to the question described above (such as for
example is the person available, what is his/her education, what is his/her
field
of study or work, etc.). Preferably there is a different answer if the person
is
not available than if he/she is not a member of the system, otherwise a lack
of
reply could mean ambiguously both of these possibilities. Another possible
variation is that the phone (or a preferably small and non-conspicuous add-on
coupled to the phone) enables the user to point his/her device directly at the
direction of the person that caught his/her eye, which preferably transmits
some Id code and/or the phone number of the user who points it, and
preferably sensors on that device of the person that was pointed to can find
out
that someone pointed the device and reply to the query directly with its own
Id
and/or phone number, etc. This pointing device can be based for example on
infrared or on a directional short range wireless antenna. (This can work also
on other devices even without the cellular network, such as for example palm
devices that are bluetooth enabled even if they are not connected to the
cellular
network, or special gadgets for dating). However this is less desirable, since
at
least some people might be embarrassed to buy a special device for that and/or
embarrassed to be seen pointing the phone at someone. Another possible
variation is to implement it for example on the level of cells or groups of
cells,
so that the cellular phones know that they are close to each other for example
by getting the information from the cellular company's cells. Another possible
variation is to run the matching normally, but when dates are found that
according to the info from the cells and/or for example from the GPS and/or
for example from the bluetooth indication (or other short range communication
technology) are also very close to the user, these dates are preferably for
example marked with a special conspicuous sign (for example in the search
results list and/or or in the contactee list) and/or moved to a special
category on
top of the list of date search results and/or in the contactee list, or their
score
for match on area is increased by a certain factor and simply incorporated in
the total compatibility score. In this version, preferably dates that are
close for
example by blutooth indication are given even a more emphasized mark and/or
moved higher to the top than dates who are only close by info from the cells.
Since for some users the level of compatibility is much more important as long
as the date is still within a reasonable area, while for others the fact that
someone is now very close to them might be more important, preferably the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 25/98
user can easily experiment with increasing and reducing the weight given to
the immediate vicinity factor. Also, for example people looking for pen-pals
will probably put much less weight on the area. Another possible variation is
that the system allows the user also to request separate search results lists
(and/or contactee lists) according to area or marking for closer people - also
more generally, such as for example putting all the people from the same
country or state or town in a separate category. Another possible variation is
that if the server or servers become for example too overloaded because of too
many users using the system, preferably different servers are used for
different
areas and date searches are for example limited in the size of areas that can
be
requested. Although PCT application WOt?115480 byNokia, published March
1, 2001 describes the idea of indicating to users when a match is very near in
cellular networks, this clause 11 describes also many new and different
variations. Also the Nokia patent did not refer to instant messaging. Of
course,
various combinations of the above variations are also possible.
12. Preferably if someone hasn't entered the system for a certain time period,
such
as for example a few months (and/or if someone else fills a for example a
"freeze form" or some other form of report about that person, reporting that
the
person said that it is no longer relevant), the server can preferably generate
an
automatic message to him/her (for example through e-mail or instant message)
to ask for example if he/she is still interested in compatible dates, and if
the
person confirms this, or if no reply comes back for example after a certain
period and/or preferably after sending more reminders, the person is
preferably
automatically "frozen" (so that people no longer receive him/her in the
searches) until there is another indication (for example if he/she enters the
system, or performs a new search, or updates the data, etc.). Preferably, the
freeze form contains also the reason (such as for example the person found
someone through the service, found someone elsewhere, found someone
through the service and got married, found someone not through the service
and got married, etc.). Another possible variation is that the system ignores
the
"freeze form" (that was filled by someone else) if the user has been active
very
recently or is currently Online, and especially if he/she performed a dating-
related activity such as for example conducting a date-search recently.
Another
possible variation is that the system does not ignore the freeze form if the
reason is more significant, such as for example the person got married
according to the report. By using this feature the weight given to the recency
data can be significantly reduced since this can significantly decrease the
chance that the potential dates found will be no longer relevant, even if
their
data is older. (of course if the user fills a freeze form about
himself/herself,
then there is no problem).
13. In one of the possible embodiments, preferably when the matching is done,
the
matching program (which is preferably on the server or servers), can take into
account at least in some questions (preferably except in questions where the
user marked the question as "necessary") also the distance between what was
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 26/98
requested and what was found. For example, if the user wanted a date that is
only "Highly above average" in appearance and an otherwise highly
compatible date rated herself as just "above average" in appearance", the
number of points taken down because of this mismatch can be lower than if the
date rated herself as "average". This is preferably implemented especially for
example in ordinal scale questions which are also subjective in nature, since
in
such questions the replies both in self description and in the requested ideal
date should preferably be taken with caution. Preferably, this distance
function
can in some cases take into account also the direction of difference, and
regard
the distance differently depending on this direction. For example, if the user
wants someone who only has a post secondary education and the date has a
B.A., the "damage" to the user should be much smaller than if the user only
has highschool education. A more extreme variation of this that the system
automatically complements the wanted scale upwards at least in some of these
cases where it clearly makes no sense to ask for something bad and not mark
also better options, however this is preferably done with caution since my own
research has shown that in many cases users still insist on the "unreasonable
reply" even when confronted with it. However this more extreme variation is
not needed when the users fill the questionnaire online, since the filling
program itself can warn them about such illogic request, and if they still
insist
then so be it. Another possible variation is that when taking the distance
into
account the system preferably takes into account also the distance from the
optimal level (or levels), so that for example if the user marked that he/she
wants a date with appearance average or above but marked for example higher
preference for "average" than for "above average" and for "much above
average", then the "damage" caused by a date who is below average is less
than for example if the user marked a lower preference for "average" then for
the higher options.
14. When matching by area, some computer dating systems today match by letting
the user mark his/her own area (for example town, state and country), and also
a list of areas from which the potential dates can be, and some match instead
for example by zip code. However, using the zip code alone is problematic
because zip codes depend on many things and do not necessarily translate to
actual distances. For example in Australia a small difference in zip numbers
can represent a huge distance, compared for example to Honk Kong where it
can represent much smaller distances. A better solution is to use matching by
selected areas, and use other info such as for example the absolute difference
from subtracting two zip numbers only as a supplement. So preferably the
difference in zip codes is used only when the date is in one of the requested
areas. Another possible variation is to take the zip code into account when
the
date is outside the requested area, in a way similar to the distance function
described in clause 13 above. Anyway, this can work only within countries
since the zip system can be different between countries. Another possible
variation is to use for example the first few digits of the phone numbers (or
the
absolute difference (subtraction) between the numbers) instead or in addition
to
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 27/98
zip data. However this is problematic since it does not help for example if
people give a cellular phone instead of their stationary phone number.
Preferably this is used in addition to the variation of using proximity data
described in clause 11. Another possible variation is to use directly absolute
Geographical location information, such as for example GPS coordinates, for
example directly from each user's IP address, since this Geographical Location
will be probably available in the next generation Internet. This is much more
reliable and exact than zip code. Another possible variation is to still use
this
together with the areas selected by the users. Of course various combinations
of the above variations are also possible.
15. Preferably the user can also request from the system to notify him/her
automatically whenever there is a new potential date that entered the system
and has a higher compatibility with him/her than at least one criterion (such
as
for example higher than the lowest compatibility score in his/her current
contactee list, or higher than an absolute minimal score defined by the user),
or
fulfills a certain condition, for example, all blondes with big bust and high
IQ.
Another possible variation is that this is done for example automatically by
default unless the user requests otherwise. This is better than the state of
the
art, where the user gets a list only at certain times (such as for example
once a
month or, when he/she himself initiates a search). This can be applied for
example when the new person submits his/her data for the first time to the
system or performs a compatibility search for the first time, and preferably
the
user can ask either to be notified for example whenever such a new person
exists in the static database, (if there is a static database), or only when
that
user is also Online (Of course when submitting the questionnaire or performing
the search the new person is by definition Online, but the user that wished to
be
notified might be for example offline at that time and when he/she comes back
Online the new person might be offline already). This can be done for example
by keeping pending search requests (preferably only one search-request or up
to a few pending search requests permitted per person) and/or keeping the
minimum criterion for that person on his/her record on the server (for example
the lowest score on the list that he/she got so far and/or the lowest score on
his
contactee list so far), and for example when the new person sends his/her data
for the first time or requests a search or changes the data (but for
efficiency
reasons most preferably this is done only or mainly when the new user requests
a search), a reciprocal search is performed on all the potential mates in the
system, and while checking the new person's data against each relevant
potential mate in the system, the server preferably also checks if a condition
has been fulfilled that requires sending the appropriate notification or
update to
the person against which the new person's data is being checked. This may
sound a bit inefficient but preferably it has only a relatively small effect
on the
search speed, since various optimizations can be performed anyway such as for
example stopping the comparison with a given person immediately for
example if the area doesn't fit or the age doesn't fit. Preferably the user
can
also choose for example if he/she wants to be notified by an e-mail and/or
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 28/98
instant message and/or by automatically having the new persons be inserted
into his/her list of contactees (This choice can be made for example in
general,
or depending on the case, so that for example the user requests that someone
be
added automatically into his/her contactee list only in cases of especially
high
matching). Preferably the new person also has the choice in advance if he/she
wants to be inserted automatically into the contactee lists of relevant people
or
at least for example into the contactee lists of the persons that appear in
high
places his/her list of date-search results and/or fit one or more other
criteria or
conditions. This saves a lot of time and increases the chance for instant
connection, especially if the new person prefers for example that the other
dates contact him/her (females for example tend more than males to prefer to
wait for someone to contact them). When the user is a member through cellular
phone and not currently Online, another possible variation is to notify the
user
also for example preferably by sending an automatic ring signal to the phone
and then displaying the message, or for example sounding a voice message, or
for example by SMS. Preferably by clicking on an icon or option near the
user's data the user can than automatically enter for example chat mode with
the person or initiate an automatic call to the person (Preferably without
knowing the actual number at this stage - at least if the new person requested
the "Proxy phone" method, or with the actual number). This can be used also
for example whenever someone highly compatible enters within Bluetooth
range from him/her or is close according to the information from the cells, or
for example from the GPS, and then preferably the user is also given data that
can help him/her locate the person for example by showing the appearance data
that are available, and/or giving the user more precise location data, such as
for
example pointing him/her to the direction and distance of the potential date,
and/or giving for example street information, as explained above in clause 11
(However, this is intended mainly for locating someone on the street, and
preferably not for giving the exact address where he/she lives, so that the
actual
address from the potential date's questionnaire is preferably not given to the
user even if available. Also, preferably users can request to block this
feature
so that potential dates that get their data will not be given pointers to
their
exact location). Another possible variation is that for example instead of
sending the notification preferably as soon as possible after the new date
becomes available, the system waits for example until one or more such highly
compatible dates become available and if they do (for example 2 or 3 or 10
such dates are now available) then the message is preferably sent immediately,
otherwise the system preferably waits a certain time limit, for example until
one hour or for example up to a few hours or for example up to a few days, and
if no additional highly compatible dates that meet the criteria become
available, then the message is preferably sent anyway (The maximum time till
the notification is sent and/or the minimum number of highly compatibles
dates that forces sending even before the time limit has been reached can
preferably be defined for example by the user and/or automatically by the
system). However this is less preferable since the idea of instant dating is
best
served by instant notification for each new such date without waiting for an
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 29/98
additional time or additional dates. As explained in the patent summary,
another possible variation is to use a similar notification for letting the
user
know when a compatible date that is already on his contactee list and/or on
his
compatibility search results list becomes online: When the user is using the
client program preferably the program indicates to the user visually and/or by
an attention getting sound when a compatible date that is on the contactee
list
(and/or for example on the list of compatibility search results) becomes
online.
Another possible variation is to use for example a more attention-getting
notification at least for dates that the user marked as especially important
to
him/her or requested to be especially notified about them. Another possible
variation is that if the user himself/herself is not currently Online, the
user can
be automatically notified for example by SMS or by email or by phone call
when such a date becomes online or for example at least for dates which the
user marked as especially important to him/her or requested to be especially
notified about them. Of course, various combinations of the above variations
are also possible.
16. Since practice shows that most people in computer dating services,
including
Online services, don't like to send their pictures (Typically for example only
less than 10% or even just 5% send their own photo) but prefer to search dates
that have pictures, preferably the system allows users to use a systematic
data
pool of pictures (which can be for example a taxonomy or hierarchy),
preferably with real photographs (for example hundreds of pictures of male
faces, hundreds of pictures of female faces, and similar separate sets for
body
shapes) and to choose at least one face that is most similar to the way they
look
and preferably also at least one body shape that is most similar to the way
they
look (preferably the marking is on a scale, so that the user indicates also
how
much he is similar to that picture or image), and preferably also mark
similarly
the kinds of appearances they would most like in their ideal date (for example
by marking the pictures that they most like, preferably with the ability to
indicate the level of liking on a scale). Preferably there are more faces to
choose from than body shapes, since there is much more possible variation in
faces. Another possible variation is to use preferably carefully drawn images,
which makes it easier to control more systematically various variables (or for
example some photos and some drawings, etc.). If drawn images are used then
preferably these are automatically generated by the computer (for example
completely automatically or with the use in part of at least some manually
drawn elements and/or photographs and/or parts of photographs, etc.). This has
the advantage that a large number of images can be easily made automatically
and systematic in advance and/or on the fly, and also the analysis of these
images is automatic since the system knows exactly according to which
parameters each image was generated. Preferably the generated images look
realistic - almost like a photo, and not like outlines. Another possible
variation
is to make the choices (for example both for self description and for
description of the ideal date) more modular than just body and faces, thus
allowing the users to create more combinations. For the more modular choices,
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 30/98
preferably either the users are shown the modular elements (facial parts
and/or
body parts) separately, and/or the user can for example mark or choose each
time such one or more elements within preferably full faces and/or preferably
full body images (or for example within partially full faces and/or partially
full
body images), for example mark or otherwise indicate that he/she wants a date
with a hair and/or eyes similar in shape and/or in color to that element in a
given image or a given photo (or in a group of images or photos), and then the
system preferably changes the image accordingly and/or for example brings the
user to the appropriate place in the taxonomy, and/or for example generates
the
relevant part of the taxonomy on the fly and/or displays multiple similar
images next to each other. Especially if the images used are images that are
systematically generated by the computer, then the choices can for example be
automatically generated on the fly for the user according to his/her previous
choices. This has the advantage that it is much easier for the user to view
holistic variations than to view disconnected parts in order to choose which
parts to put in the desired images. For example the choice of the preferred
images in the taxonomy can be by clicking on the part of the face or of the
body that the user most likes and then the system automatically knows where
to proceed according to that part, so that for example by clicking on a
certain
part in a certain image the user both chooses the desired image and a specific
element in it. (Another possible variation is that if the user for example
clicks
on the hair, then the system can for example ask the user if he/she wants to
view more images with the same or similar hair color, the same or similar hair
style, the same or similar hair length, or any combination of the above, or
for
example view similar images where these elements are different, for example
the hair is more blonde, etc. In other words, the system can ask the user for
example if he wants a specific type of choice about that element or any
combination of the available types of choices for that element. One possible
variation is that for example by clicking for example on the hair with one
mouse button the user can request to see more images with similar hair and by
clicking with another mouse button the user can choose for example to change
the element and/or what to change in the for example hair and/or can use for
example the scroll button of the mouse (and/or for example the arrows and/or
other keys) in order to have the chosen element or elements - for example
various hair styles or colors - change instantly on the same image, preferably
across the various available options. However, this is of course just one
possible variation and many additional variations are also possible.
Preferably
for defining his/her own appearance the user uses more the functions of
changing various modular elements until the right appearance is selected, and
for defining the desired date preferably the user uses more the functions of
showing similar appearances, since when defining preferences typically there
is a large range of variations or types that the user may like). Another
possible
variation is for example to allow the user to drag or push or pull various
parts
of the image for example with the mouse, for example to make some element
wider or thinner or smaller or bigger or other changes or move it, except that
preferably the system allows only reasonable or acceptable changes or changes
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 31/98
that are within the allowed set of variations and for example avoids any
distortions that would be considered unnatural. Of course it is also possible
for
example to let the user view during the selection process a composite image
that includes both the selected body and the selected face, so that the
changing
or scrolling across options of modular elements occurs on the fly over this
composite image of body and face. This is also important because it is very
difficult to properly cover appearance, which is holistic, by a few analytic
questions. So by using this method we overcome both the problem that only
few users are willing to submit their photographs and the problem that it is
hard to sufficiently cover appearance by analytical questions. Preferably when
this additional info is available it is used for the scoring of compatibility
in
appearance in addition to the normal textual questions about appearance.
Preferably when there is no direct match between marked self image (of the
other person) and marked preferences in these images (a direct match is for
example if the user marked that he wants females who look like any of
systematic female photos numbers 520, 700, 819, etc. and the potential female
date marked herself as similar to one of these photos, and preferably the
matching takes into account also the scale of how similar that female marked
herself to the photo and/or how much the user marked that likes the photo, in
order to further refine the matching score on this), the system takes into
account a also the distance or similarity between the preferred and the actual
image, preferably based on the systematic classification of the images
according to various variables. Preferably this analysis is done on the
distance
between the images that were marked by the user as preferred images and the
image or images that were marked by the date as most similar to
himself/herself (and of course preferably the relevant parameters of each
image
are coded in advance as numeric data so that no actual image analysis is done
during the compatibility search). Of course, if reciprocal compatibility is
used
then preferably the test for direct match on marked images (and also such
analysis of distance or similarity if it is used), is done both ways, once
based
on the user's preferences and once based on the date's preferences. On the
other hand the variation of checking only if there is a direct match or not,
without analyzing the distance if there is no direct match, can be much more
efficient. If such an analysis is used and if the date submitted also an
actual
photo then another possible variation is to run such an analysis of distance
or
similarity in addition or instead also with the actual photo, however this
option
might be much less efficient and might also be less reliable unless the system
is
able to automatically analyze the actual photos supplied by the users at a
high
level. Similarly, another possible variation is to check the similarity to an
actual photo supplied by the person, if is it available, for checking if there
is a
direct match, however that might be again much less efficient, since, in
contrast, checking if there is a match between images from the systematic pool
marked by the users is preferably based on just checking if there is an
overlap
in a small list of picture serial numbers. However, the efficiency of dealing
with actual photos submitted by the users can be considerably improved if they
are analyzed in advance and coded according to various parameters so that
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 32/98
during the actual matching run only these codes are used, as explained below.
So for example when an actual photo supplied by the user is available the
actual photo can be used to correct when needed the marking by the user of
how similar he/she is to the pictures of the systematic pool (or even instead
of
the marking by the user), and then in the actual matching run preferably only
the corrected marking is used. But, as explained above, this might be in fact
less reliable than using the marks made by the users unless the automatic
analysis is very sophisticated, since automatic intelligent analysis of photos
can
be very problematic. When a potential date's data is displayed, and when no
real picture of the date is available, preferably this "approximate image" is
displayed instead. This has the additional advantage of saving bandwidth and
saving space and load on the server, because for approximate images it is
sufficient to transfer just some numerical codes. Preferably these pictures or
images are small and are downloaded automatically as part of the client, so
that
viewing them does not overload the server. (Preferably they can also be
automatically updated sometimes by the server when needed, like the other
updates described above in clause 7). For efficiency reasons, preferably when
letting the user mark choices many images are displayed on the screen
together, as long as they don't become too small to discern the important
details. Another possible variation is that the user is preferably asked to
make
choices in a tree-like manner - for example choose first between a number of
images and then refine the choices based on the previous choices (For example
the user can be shown at first for example 12 images which are typical of
various main branches in the taxonomy, and after he chooses one or more
preferred branches he is shown at the next step for example 9 images that are
typical each of a main sub-branches of the chosen one or more branches, etc.
However this is just one example and many other variations of this are also
possible). When the choice is made for self description preferably the user
can
choose only one answer on each step in the tree (However, as explained above
another possible variation is that even in this case the user can mark at
least in
some stages more than one option, for example if he thinks that he is
sufficiently similar to more than one image), and when the choices are made
for the desired date preferably the user can mark multiple options at least in
some of the stages. (Preferably at least the top of the decision making tree
may
contain textual descriptions and/or explanations instead or in addition to
images). Another possible variation is that preferably the user first fills
the
textual questions about appearance and then the system displays the graphic
choices already based on the textual information about the self description
and
about the desired date. This narrows down the choices that have to be made
and the number of images that actually need to be displayed and thus increases
the efficiency. This way even if thousands of images are available to choose
from, the choices can still be made very quickly and very efficiently. Another
possible variation is that this is used even with users that do send a photo,
in
addition to the photo, because of the above described advantages in
comparison to just using photos. Another possible variation is, instead or in
addition, to use similar methods with the actual photos that are supplied by
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 33/98
users, so that for example if the user browses through photos of opposite sex
users, he/she can for example request to view for example more photos (or all
photos) that are similar to a certain photo (or more than one photo) that he
likes
and then the system automatically shows him those photos, for example sorted
by descending order of similarity to that photo (or photos), and/or to use
this as
one of the criteria for the automatic matching. However that can be more
difficult to implement since it might require almost AI analysis of the photos
to
determine how similar each two photographs are. Since there can be a number
of possible parameters or dimensions on which the similarity is based, the
system can assume for example that the most similar pictures are those which
have a highest total similarity score across the various dimensions or
parameters, or for example the system can search among the available photos
for a list of similar photos based on one or more different parameters each
time, and then decide according to the user's following responses which
dimensions are actually more important for him. For example the system can
find by trial and error and/or by asking the user that after finding for the
user a
list of female pictures that are most similar (according to various
parameters)
to a certain one or more previously marked pictures, the user actually likes
mostly the pictures with the same hair style and the same hair color, and for
example does not really care about many other parameters. Another possible
variation is that the user asks for similar pictures for example by clicking
on
the relevant body part or face part and then the system looks for images who
have a similar corresponding part (for example similar hair, similar bust
shape
and size, etc.). Another possible variation is that in this case the system
can for
example ask the user if he/she wants for example similar hair color, similar
hair style, similar hair length, or any combinations of the above. Another
possible variation is to create an automatic analysis of these parameters by
looking for the common features among the pictures which the user initially
marks as most desired. (With the systematic pool of pictures the automatic
analysis of similarity between pictures is not needed since each user
indicates
the pictures to which he or she is most similar, however, as explained above,
another possible variation is that for users that included an actual
photograph
of themselves such automatic analysis is also used in addition to or instead
of
the user's own rating, in order to further improve the reliability of this
subjective ranking, if such an automatic analysis is itself sufficiently
reliable).
Another possible variation is that the systematic pool prepared in advance is
used mainly for the automatic scoring of compatibility, and the request for
photos similar to a actual user's photo is used more for browsing, for example
if the automatic scoring of similarity between two photographs is not reliable
enough. On the other hand, preferably similar browsing of actual user photos
can also be requested for example for photos that are similar to any of the
systematic photos that the user marked as desirable, and in this case the
system
can use for example the users' own ranking of similarity, so that for example
the system lets the user browse all (or some of) the photos of females which
marked themselves as similar to the desired photos that the user marked,
preferably in a descending order of similarity according to how similar the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 34/98
female marked that she is to that photo. In any of the above variations where
the actual photos supplied by users are also taken into account, preferably
the
photo is automatically analyzed in advance after the user submits it according
to various parameters in order to convert it into numerical codes, so that
during
the actual compatibility search and/or during searching for similar photos
preferably only these numerical codes are used. (Another possible variation is
to make such analysis for example by principles of holography, so that for
example each photo is coded in advance according the results of its
holographic processing, but, again, this can be very problematic if for
example
various light or shade effects change the way that someone looks, so
intelligent
analysis is preferably for this). Another possible variation is to allow the
user
for example to supply an actual photo and have it converted automatically by
the system to an approximate image so that the approximate image is similar to
him/her but not exactly the same and preferably looks like one of the
systematically drawn images. This can be used preferably in order to protect
the user's privacy, so that after the conversion the database preferably
contains
only the converted approximate image, and so at least for example for users
who prefer not to expose their actual photo, this image is preferably shown
next to their data instead of their actual photo, thus making more users
willing
to submit their actual photos. In this case, preferably for users who do not
refuse to reveal their actual image, preferably the actual image is shown in
addition or instead of the automatically generated approximate image and/or
the approximate self image which the user selected from the systematic pool of
images. Of course, various combinations of the above variations are also
possible. Another possible variation is to use these approximate images
(and/or
real photos when available) to create Virtual Reality environments where users
can "meet". Another possible variation is to allow the users for example also
to
choose from preferably modular clothing items, for example for the virtual
reality implementation and/or for the approximate image that is displayed near
their data. Of course, the approximate image that is displayed near the user's
data and/or is used in virtual reality meetings preferably includes both the
body
and the face, preferably combined properly. Another possible variation is that
the actual photo and/or the approximate image can appear also near each entry
in the contactee lists (for example by default or if the user requests it)
and/or
the user can mark or indicate which photo or image should appear near each
contactee if more than one option is available (for example if there is both
an
approximate image and an actual photo and/or if more than one photo is
available. This can be for example marked explicitly by the user or for
example
the system remembers automatically the last photo that the user chose to
display for example when he/she last accessed that person's data). Another
possible variation is that for example if more than one image is available
(for
example more than one photo and/or more than one approximate image) then
more than one preferably small image is automatically shown for example near
the potential date, for example in the search results list and/or in the
contactee
list. (For displaying for example smaller photos before the user clicks on one
of
them to see it in larger size, the images can for example be automatically
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 35/98
downscaled in size and resolution. Another possible variation is that, in
addition or instead, the image is automatically truncated, and for example
various heuristics are used in order to find the central point of interest
automatically, such as for example finding the human face in the image,
starting automatically from the geometrical center, etc.) Another possible
variation is to use for example similar methods and/or automatic analyses for
example on sound, so that for example the user can scroll over various
parameters of preferably synthesized speech (and/or for example a systematic
set of recordings of real voices, and/or for example real voices that are
manipulated by the computer to reflect different parameters, such as for
example different pitch, etc.) in order to select or choose a voice similar to
his/her own voice and/or types of preferable voices in the preferred dates
(for
example the desired pitch and/or other characteristics), and the system can
for
example use this as additional selection criteria. In this case, if an actual
recording of the user is available, this is preferably analyzed automatically
according to the relevant criteria and used in addition to or instead of the
systematic sounds to which the users refer. Of course, all the analyses are
preferably done in advance so that during the actual matching run preferably
only numerical codes are used. Also, similarly the user might for example
browse potential dates and request to view for example potential dates with a
similar voice to a voice that he/she likes. Another possible variation is that
for
example to encourage people to upload their pictures, people who did not
upload at least one acceptable picture of themselves cannot view at all the
pictures of others, or for example they can view only the first picture of
each
potential mate even when that mate has for example uploaded a few pictures
(preferably with an indication that additional pictures of this user are
available
to users who have uploaded their own picture, etc.), and/or for example see
the
pictures of other members only for example in smaller format and/or for
example in lower resolution and/or for example each picture appears with a
missing or blocked part in it (or for example the blocked part contains the
message inviting the user to upload his/her own photo so that he can see the
full images undisturbed) , etc. (this way the user knows better what he/she is
missing). Of course, various combinations of the above and other variations
are
also possible.
17. Another problem, that exists both in IM networks and in Online dating
service,
is that many times the same user enters the system under more than one
identity, for example because he/she forgot his/her login and/or password, or
because he/she wants to get again a free bonus that is offered only to new
users, or because he/she wants to experiment with a few different identities,
or
other reasons. However, this can create a number of problems, such as for
example making it hard to know how many real people are actually in the
system, the possibility that a user will get someone on the list or lists of
compatible dates more than once, with different compatibility scores each
time,
and making it hani to determine if a user is really new or not in systems
where
for example a user gets one free list and then has to pay for the next, or for
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 36/98
example if the method of "proxy phone" is used, since by using different
identities users can cheat the number of limitations. Therefore, preferably
the
system uses various heuristics in order to try to automatically catch suspect
duplicates: For example, if the e-mail starts with the same or a very similar
name on the left side of the "@" and/or if the name is similar and the birth
date
is the same or very similar, preferably the system checks if other data are
also
similar (such as for example area and other important background data, or for
example some numerical function of the general similarity between the
suspected duplicate profiles), and then automatically decides if the data is
similar enough to decide that it is the same person. If it is, then the system
preferably automatically uses the new data as an update of the older data and
preferably also notifies the user about it. If the system is less sure, then
preferably it asks the user if he/she is indeed the same person and/or reports
it
to a log for human decision and/or warns the user for example that various
sanctions will be taken against people who deliberately try to mislead the
system. Of course, in order to check similarity efficiently preferably the
system
uses sorting and/or an index in order to cluster together the relevant similar
items that have to be compared. In addition, preferably the system uses also
statistical considerations, which can be for example based on direct
statistics
from the Database, so that for example if the suspect duplicate is with a rare
user name it is considered more significant than if is for example a very
common name, etc. Of course, like other features of this invention, these
features can be used also independently of any other features of this
invention,
so that for example this or similar methods can be used fox example also in
normal IM networks even if they are not related to dating, for example in
order
to find duplicate records of IM users, and preferably if the user for example
still prefers to get a new user number in the IM network, the system can for
example automatically import all the contactees from his/her previous IM user
number or numbers (which were properly identified as duplicates) to the
contactee list of the new user number and/or for example send an automatic
update to other IM clients which have that user on their contactee lists with
the
automatic change in the user's IM user number, etc.
18. Another possible variation is to use the data from the compatibility
questionnaires filled by the users to create "group compatibility' - which
means creating a group of compatible people. One of the possible ways to
accomplish this is for example by running the following algorithm with at
least
some of the following steps: 1. First one or more individual is chosen that
fulfill some required criteria. 2. Assuming that for example one female was
chosen, the computer preferably now finds one or more males highly or most
compatible with her (preferably by reciprocal compatibility) and adds them to
the group (This finding of most compatible dates can be done on the fly or by
using for example the previously generated list of most compatible dates that
each person has). 3. For each of the males last added to the group the
computer
preferably now finds one or more of the females highly or most compatible
with them (on condition that they are not already in the group) and adds them
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 37/98
also to the group. 4. The computer now preferably finds one or more of the
highly or most compatible dates for each of the recently added females, then
for the newly added mates, and so on, until the required group size has been
reached. When finding the highly or most compatible date or dates for each
newly added member, the computer can for example either take each time the
next most compatible date for that person, or take into consideration for
example also how compatible the new candidate is with the other members of
the opposite sex that are already in the group (for example on average). This
is
useful for example for creating meetings or parties or virtual meetings for
groups with high group compatibility. Of course this is just an example and
many other variations or combinations can also be used.
19. Another problem is that to the best of my knowledge in the state-of the-
art
computer dating systems there are no provisions for logical relations between
the various questions other than logical "AND". In other words, although each
question can preferably be given an importance level (or 0 importance) by the
user, the default relation between each two questions is automatically only
"AND", so that the system by definition lowers the score for the potential
date
if he/she fulfills only some of the requested traits of non-zero importance to
the
user. This does not allow the user to define also alternate relations between
the
various questions (or traits), such as for example "OR" relations or "IF"
relations. So preferably the user is also allowed to define such
relationships.
For example, if some girl wants guys that have a white-collar job such as for
example Medical Doctors, Lawyers, Accountants, Engineers, etc., and wants
that the guy will be someone who works in any of these fields but does not
care
which of them it is, there is no way to define this in normal computer dating
systems, since marking for example a high importance that the guy will be
someone working in each of these jobs will lower the score to anyone that
works only in one of these areas and not in all of them. So preferably the
user
is allowed to add an "OR" mark to each member of the requested group of
traits or for example graphically pull them together into a common area.
Another example is if the girl for example wants only someone who is
interested mainly in the Humanities fields of interest or mainly in Technical
fields of interest, etc. Preferably, defining an "OR" relationship does not
override the "AND", so that if the potential dates satisfies more then one of
the
questions in the "OR" group, a special bonus is added to the score. (Another
possible solutions is, of course, for example to add additional questions, in
this
example, about wanting someone with a white-collar status and/or about higher
levels of categorization of fields of interest/vocation, but obviously this
would
not really solve the problem since individual users might want specific
combinations that are specifically important to them, and the questionnaire
cannot incorporate in advance all such possible special requests). An "IF"
relation is needed for example if the user wants to define that some condition
can be for example automatically relaxed or tightened if another condition is
met. For example, a user might define with Absolute importance that the date
will have a high IQ and also define with Absolute importance a minimum
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 38/98
Education of M.A., but for girls that have an extremely high IQ he is willing
to
accept them also for example if they have only a B.A. Or someone for example
wants in general only thin or medium-weight girls, but if they have a very
large
bust he is willing to accept also fat girls. Or for example someone can define
that he/she wants a date that actually works in music only if that date also
marked in the questions that deal with music for example that he/she likes
music of the 60's and 70's and not classical music. So preferably, for such
cases the system allows the user to define also such dependencies, for example
by letting the user define at the end of the questionnaire a set (or sets) of
rules
that can create changes in various requirements in case certain other
requirements are met. This can be accomplished for example by letting the user
graphically connect certain different variations of filling a certain question
with
certain options in another question, or for example allowing the user to def
ne a
set of "If then" sentences for example after finishing the normal filling of
the
questionnaire. This way the users can have much more flexibility in defining
more complex relationships between various questions or sets of questions.
However, the ability to add "IF" relationships is less important than "OR",
since "OR" relationships represent something that is very different from the
ordinary "AND", whereas "IF" might typically be needed only in a few rare
cases. So for example in the music example given above, the user might simply
mark with high importance that he/she wants someone who likes music of the
60's and 70's and not classical music and also mark with high importance that
he/she would like a potential date that works in music, and this already
increases the chance of getting a date who satisfies both requirements.
Another
possible variation is that the questionnaire can contain at least one or a few
questions that are variable for example according to Country, culture and/or
religion and/or other significant relevant background parameters, so that for
example certain cultures or religions can have a few specific questions that
are
relevant only to these cultures or religions. Preferably such questions are
taken
into consideration only among users who have both answered them and/or who
both belong to the relevant group or groups, and are preferably ignored for
checking the compatibility between people that are across such groups. Of
course, various combinations of the above and other variations can also be
used.
20. Another preferable variation is that when the user makes changes in one or
more questions, he/she is preferably immediately allowed by the system to see
for example an indication of the direction and extent of the change in results
that this will cause. This can be done for example by automatically running
the
user against other potential dates upon each change in a question, but for
efficiency reasons preferably this can be done for example by using general
statistics of the answers by the opposite sex members to each question. So for
example if the user first marks that he wants girls with medium or large bust
and he had for example 500 hundred potential dates with compatibility scores
above 80%, and then changes it to include only girls with large bust, or
changes for example the requirements for high intelligence and/or changes the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 39/98
importance for these questions, the system can for example predict
immediately more or less some general estimate of the amount of increase or
decrease in the number of potential dates this is likely to cause (by simply
using for example the statistics of the percent of girls that will be dropped
by
this change, preferably together with an estimate of the amount of drop or
increase in scores that each level of importance marked by the user typically
causes) and display it for example graphically to the user. Of course, this
estimate can be wrong, but in general it can preferably give a rough estimate
of
what will happen after the changes, and then, for example after finishing a
group of changes, the user can request an actual matching run and see the
actual effect of the change. Another possible variation is to give the user
feedback of results already during filling the questionnaire, so that for
example
after filling each question the user is given for example the choice to view
similar information as described above, preferably based on statistics, since
otherwise it might be very inefficient with a large database of potential
dates.
Another possible variation is to allow the user to request a run on potential
dates for example after having filled only part of the questionnaire, or at
least
after having finished a section of the questionnaire (for example background
data, appearance, interests, etc) however in this case preferably there are
various restrictions, for example such as those described in clause number 5
above, in order to encourage the user to complete filling the questionnaire
before he/she can gain full access. In such a case preferably the questions
are
arranged, for example within each section of the questionnaire, or across the
entire questionnaire, according to descending order of importance (for example
by using data from previous users), so that the results can be more meaningful
even after filling only a subset of the questionnaire.
21. Another possible variation is to automatically analyze the user's answers
during filling the questionnaire, in order to check the quality of his/her
answers
and preferably give the user feedback if the answers are not reasonable
enough.
This feedback can be given to the user for example during the filling process
and/or after he/she has finished it and/or at least after various stages have
been
completed. Preferably the user's answers can be rated for example based on the
optimal levels that he/she chooses, the acceptable levels on which he/she is
willing to compromise, and the importance he/she gives to the question. So for
example the user's choices can be defined as sufficiently discriminating or
distinctive or differentiating if he/she has shown sufficient variation (for
example in any of the above criteria - such as for example different levels of
importance, various optimal levels or ranges, various acceptable levels or
ranges or at least in some of them) among his answers about the various
questions, if he/she has shown sufficient resolution (for example if he/she
used
all the possible levels, for example of characterization and/or all the
possible
weights - preferably across the questions), and/or used a sufficient range of
levels (for example of characterization and/or of weights). Another possible
variable is consistency - which checks for example if he/she used similar
characterizations and/or weights for questions which are known to be similar
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 40/98
or highly correlated. For example if someone wants very smart females but
wants them to have only low education, or vice versa, this doesn't make sense.
Another possible variable is coherence, which means for example the
correlation between importance and the range of acceptable levels and the
position of the optimal level (or levels). For example the more important a
question is, the less reasonable it is to mark only levels in the middle
without
reaching one of the extreme options (one of the edges of the scale), although
this might depend also on the specific content of the question. Also, if the
user
for example consistently uses high importance together with a wider range of
acceptable levels than in low importance questions, it can be for example
brought to his attention that this is not reasonable. Or the user can be
warned
for example if he/she gives too many questions absolute or high weight or
gives too many questions weight 0. In such cases, and preferably depending on
the case, the system can for example advise the user to correct specific
unreasonable answers and/or to correct answers in general, and/or for example
to consult with a human counselor about this. Of course various combinations
of the above and other variations are also possible.
22. Although the system preferably requires the user to answer all the
questions in
the compatibility questionnaire, another possible variation is that, if the
user
did not answer some questions, the system handles the missing values for
example by taking into account the average or most frequent answers in each
question that the user did not answer. However, if this is done, preferably
the
system takes into account also the correlations of each missing answer with
other answers, thus taking into account for example the other variables that
are
most in correlation with the missing question, such as for example sex, age,
education, etc. Another possible variation is to give a lower score for
matching
on missing values, in a way that reflects the uncertainty. Of course various
combinations of the above and other variations can also be used.
23. Another problem with large dating sites is that only a small percent of
clients
pay (typically just 10% or even considerably less) and in order to extract
payment the sites typically offer only a very limited service to people who
don't pay, so that for example they cannot contact anyone and they can only be
contacted by the small percent of people who paid, and therefore the total
quality of service is much below the true potential. This is typically because
the sites try to charge too much from each paying client, such as for example
$15-20 per month. Therefore, preferably the site charges a considerably lower
fee that can encourage much more people to pay for the service, for example
just $2 a month or $5 a month, and preferably the charge is done for example
automatically through the user's ISP (Internet access provider), preferably
without indicating to the ISP that this is a charge for a dating site (in
order to
preserve privacy), so that the user doesn't even feel the payment. Another
problem is that many users who have not paid and are waiting for others to
contact them, don't realize how many of the others can't really contact them
because said others haven't paid either. Therefore, another possible variation
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 41/98
that can encourage the user to decide to become a paying member is that he/she
is given, preferably on a regular basis, for example daily or weekly, relevant
statistical details about it, such as for example how many other matching
dates
have viewed his/her data but were unable to contact him/her because they did
not pay, and/or for example based on real-time notification, for example when
a highly compatible match, according to one or more criteria, views the user's
data (In this case preferably the user is for example shown the details of the
person who has just tried to contact him/her). Another possible variation is
that
users are for example encouraged to pay by giving them a partial experience,
so that for example the user can contact dates even if he/she didn't pay, but
can
for example send each potential date only a limited number of messages if
he/she did not pay (for example just 1 or 2 or 3 messages). The logic in this
is
that if a user has started for example an IM session with someone and that
person has indeed responded, then the user will have a much higher motivation
to pay if otherwise he/she can't continue the IM session with that person,
especially if the fee is very low, as explained above). Of course, various
combinations of the above and other variations can also be used.
24. Another problem with instant messaging is that many times users, and
especially more popular users, are engaged in more than one Instant messaging
session at the same time, and/or have one or more chat windows open, which
means that they simply cannot answer an additional user who has just sent
them an instant message, or take a long time to do so because they are
distracted by the other IM sessions and/or by one or more chat windows. (An
IM session typically means a window that shows the history of the most recent
exchange of messages between two users and into which the new messages are
added). This can be very frustrating to the user who tries to send to such a
user
an IM message, since the sending user often does not know if a lack of
response is because the other user is not interested in the sending user in
general, or for example because the other user did not like the particular
message sent, or for example because the other user is engaged in other IM
"conversations" and/or for example in a chat window and/or in some other
activity, or even for example because the other user is marked as Online but
is
not really near his computer. This problem is preferably solved by at least
one
of the following solutions:
_a. As explained above and below, preferably the user's activity at the
computer is taken into consideration, so that if the user is not active for
a certain time (for example no mouse activity and no keyboard activity
for more than for example 5 or 10 or 20 minutes or any other reasonable
time), then the system can assume that the user is not really Online and
mark him/her as offline until such activity resumes).
b. Preferably near each user or compatible date that is online, the system
preferably shows if he/she is currently engaged in another IM session
and/or chat with one or more persons, and/or in how many such sessions
he/she is engaged and/or with how many other users. (This is preferably
shown automatically for example in the results list and/or in the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 42/98
contactee list and/or when the user looks at the potential date's profile,
however another possible variation is that preferably the user can for
example turn this feature on or off). (A session can be for example an
open chat window, or for example an IM window which is open and for
example may show the recent IM messages that have been exchanged,
or for example a sequence of IM messages to and/or from other persons
over a certain time period. Of course, this data is preferably
automatically gathered, preferably by the user's IM client (and/or for
example by the server), according to the number of open sessions the
user has, and/or over a period of time of for example a few minutes or
more. Another possible variation is that if the user is in the middle of
typing something in a chat session with someone else or in the middle
of typing an Instant Message to someone else this can be given even
stronger weight, so that for example some icon shows that he/she is
actually typing a message to someone else now). This can give the
sending user a clear indication if he/she has a good chance of getting a
response quickly or at all. Another possible variation is that the system
for example keeps (and of course preferably shows) statistics for each
user, such as for example to what percent of IM messages (and/or for
example also of normal non IM messages) that user has responded,
and/or his/her average time for response. Another possible variation is
showing for example how many other people already added that person
to their contactee list through the dating service and/or how many of
them already sent messages to that person so far (for example since
he/she joined or for example in the last month or any other convenient
period) and/or how many people from the dating service that person has
already added to his/her contactee list and/or has contacted so far
(Preferably these statistics are automatically also normalized to include
also a score that takes into account also for example for how long that
person has been in the service (and/or for example how often he/she is
active in the dating search or in the related dating site, if the service
works also with a related dating web site), since people who have been
in the service for a longer time will normally have more connections,
and preferably this info of how long the person has been in the service
and/or how often he/she is active in the dating-related activity of the
service is also shown near his/her details), so that the user can estimate
for example how much competition he/she might face in each case.
(Although the new dating site webdate.com now automatically shows
near each user profile of a potential date also pictures which link to
other people which that potential date already added to his/her list of
preferred dates, and thus the user can also see how many people that
potential date has added to his/her list, this is not admitted as prior art
since this new dating site has only existed since 2003 and it is not
known when this feature has been added to it, and the possibility of
letting users explore contactee lists of other users has already been
added to the present invention in clause 28 of the reference to Fig. 1 a in
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 43/98
the Canadian application of Dec. 29, 2003). Preferably the system can
also give the sender of an IM message for example a confirmation if
and/or when the IM message has reached the intended recipient and/or if
and/or when he/she has opened it and/or read it and/or if he/she is
currently typing a response to it (Although a recent version of AOL's
AIM can now let the user know when the other person is typing a
response to his Instant Message, this is less useful than being able to
know if and/or when the other person has seen the message, since when
the other person is already typing a response, the user will typically get
it anyway within a moment, since instant messages are typically very
short by nature - for example one or a few lines). Preferably for this
preferably the recipient's client (or for example his/her browser)
automatically sends back for example an automatic Instant Message that
indicates to the sending client that the Instant Message has been opened
and/or read by the receiving user, and this is preferably indicated to the
sender for example by some icon and/or text and/or sound. Another
possible variation is that the system allows the sender for example to
cancel and/or correct an Instant Message after it has already been sent -
preferably as long as the recipient has not opened it or read it yet (and/or
this feature can be for example limited in time, so that the correction or
canceling can be done for example only within a limited time since it
was sent). For making these cancellations or corrections preferably the
user can for example use some back arrow to return to the last Instant
Message or a recent Instant Message and correct it and request to send it
as a replacement of the previous sending of that Instant Message instead
of a new Instant Message and/or request its deletion, and the receiving
client can then comply with the request, for example if the receiving
user has not read it yet and/or the request is within the allowed time
limit, etc. Another possible variation is that for example during real-
time chat (in which each user can see as the other user is typing for
example on a split-window) and/or for example in IM sessions where
the user can see the history of his/her previous messages and/or the
messages of the other party, the user can correct any errors for example
in previous messages and/or previous lines for example by simply using
for example the arrows and/or the mouse to reach a certain place in the
text and simply typing-in the correction, and preferably this correction
can be immediately updated also in the corresponding text that shows
for example on the split-screen of the other user. (This can be
accompanied for example by some attention-getting mark or for
example momentary flashing at the place where the correction is being
made, in order to get the attention of the other party). This is preferably
limited only to messages that are still on the same screen and/or for
example only to messages that have been recently typed, such as for
example up to a few minutes ago. Of course, like other features of this
invention, these features can be used also independently of other
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 44/98
features, such as for example also in IM applications that are not related
to dating.
c. Another possible variation is that preferably the sender gets an
indication when the user to which the IM message was sent (and/or even
for non IM messages) sees the message. This can give the sender a clear
indication if the user who was sent the message does not respond
because he/she has not seen it yet or for example because he/she is not
interested in answering that message.
_d. In addition, as explained below, preferably whenever a user gets a new
IM message he/she also gets an auditory indication so that he/she can be
aware of the message even if he/she is currently distracted by other
activities. Another possible variation is that this auditory indication
includes for example in addition or instead a vocal message by the
system stating for example the nickname and/or other identification of
the user who sent the message, for example "message from Sherryl0
has arrived", or "new message from Shenyl0", or "you have a new
message from Sherryl0", etc. However, since such an auditory message
can also be a nuisance for some users at least some of the time,
preferably of course this feature can be turned off and on, preferably
easily.
Of course, various combinations of the above and other variations can also be
used. In addition, like other features of this invention, the above solutions
can
also be used independently of any other features, for example also in normal
IM networks that do not have dating features.
25. Another possible variation is to use similar methods to determine if
someone is
"online" and/or to implement Instant Messaging for example also in Interactive
TV, if the dating service is run for example in addition or instead over an
Interactive TV network. Of course, if the Interactive TV is simply used as
another way of accessing the Internet, then automatically any features
available
on the Internet can also be made available on the Interactive TV. However,
most interactive TV services today are still are a dedicated service that lets
the
user access only the given one or more dedicated Interactive channels.
Anyway, in an interactive TV environment, regardless of the question if the
user has also direct access to the Internet or not, there is still a
significant
problem of defining if a user is Online or not, especially for example if the
user
did not explicitly connect to the Internet and/or to the interactive TV
channel,
but is indeed for example near the TV or is watching TV. To determine if
someone is currently Online preferably the system uses at least one of the
following methods:
a. Preferably the Cable TV decoder or satellite decoder (also called set-
top-box) preferably senses any button that the user presses on the
remote control (preferably also if the button broadcasts a signal intended
for the TV set and not for the decoder, such as for example the volume
control, and/or even senses for example if other remote controls are
used, such as for example the TV remote control or the VCR or DVD
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 45/98
remote control) and if any such button has been pressed for example
during the last 5 or 10 or 20 minutes (or any other reasonable time
period) the system preferably assumes that the user is currently Online.
b_. Another possible variation is that the decoder can sense the signal of
turning the TV on or off and assumes that someone is "Online" if the
TV is currently turned on.
c. Another possible variation is that the decoder senses if the TV is
currently on by sensing the electromagnetic field emitted by the TV.
d. Another possible variation is that such or similar detection features are
integrated in the TV itself, but that is less preferable since it is much
easier to do it with the set-top-box.
_e. Another possible variation is that someone is considered Online only if
he/she is currently on the Interactive TV channel. However, this option
is less preferable since a user can preferably be reached by the IM
features over such a network also if he/she is currently not on the same
Interactive channel (for example if he/she is currently on another
Interactive channel or for example is watching a normal channel).
However, preferably the users have an option for example to disable
interrupting them if they are on another channel and/or if they are
watching some normal program.
f_. Another possible variation is that the decoder has for example a video
camera and/or volumetric sensor and/or other sensor or sensors that can
sense automatically if someone is moving in the room and/or is sitting
in front of the TV. However, this option is less preferable, since many
users might not agree to have a decoder that "spies" on them.
Of course, like other features of the present invention, the above methods can
also be used independently of other features of this invention, for example as
a
methods for implementing an automatic people-meter for rating of TV
channels. (Although this has the disadvantage that it does not identify
specifically which of the house members is using the TV, unlike special
equipment that allows users to signal which of the people in the house is
currently using the TV, this has the advantage that it can be completely
automatic and thus a much more reliable and much large sample can be used
than the typical sample of just a few hundred or a few thousand households
that get the special equipment).
For implementing IM features over such a network, preferably the system uses
at least one of the following methods:
a. The user can receive instant messages preferably on the screen,
preferably at least when he/she is in the same interactive channel. If the
user is in another channel (for example another interactive channel or a
normal channel) preferably the user can at least receive some preferably
non-interfering visual and/or auditory indication that an IM message has
arrived, such as for example some short beep and/or some icon
appearing for example at one of the corners of the screen, and for
example by jumping to the same Interactive channel and/or by pressing
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 46/98
some button for example without leaving the current channel, the user
can view the message or messages and/or respond to it.
b. For sending IM messages preferably either the remote control contains
also letter keys and/or some additional keyboard is available for this,
and/or the IM messages can be example vocal messages, preferably
enabled by including a microphone in the remote control so that
preferably the user can press some button to record a message, and
preferably there is also a speaker on the remote control, so that the users
can for example choose if to hear an auditory message over the TV
speakers or directly through the remote control. Preferably, especially if
the messages are through voice communication, the users can continue
to watch the program undisturbed, so that for example two or more
users can also discuss this way for example the program that they are
watching, etc.
c. All IM messages over such an interactive TV networks are preferably
communicated or relayed through one or more servers, since of course
users are typically not connected directly to each other.
d. Preferably the users can save contactee lists, preferably on a nonvolatile
memory storage for example on the set-to-box and/or for example on
the remote control.
Such features have the advantage that they can allow access also for example
to people who don't have a computer and/or don't have a connection to the
Internet. However, preferably the same database is also connected to the
Internet and preferably the IM implementations are also connected across these
platforms, so that preferably people can find each other and/or contact each
other no matter if they accessed the system through the Internet or through
Interactive TV. Although AOL has recently added the ability to send and
receive IM messages in an interactive TV network, as can be seen for example
at http://www.sk ublicitv.co.uk%press d.asp'?rel===38() and for example at
http:/!www.howstt~ffworks.comlnews-item36.htm, this is based on actively
logging in into the AOL active service, and is actually based on accessing
directly the Internet, like Microsoft's WebTV, and does not include the wider
automatic definition of being online, as described above. Of course, various
combinations of the above and other variations can also be used.
26. Another preferable improvement is speeding up the time needed for filling
the
questionnaire. This is preferably done by at least one of the following
improvements:
_a. Preferably the radio and/or checkbox buttons are defined as wider than
their height, and their height is preferably increased just a little, so that
without unduly large line-spacing the user can easily mark or unmark
such areas without having to reach precisely the exact point in terms of
right/left. This is preferably done with the new htrnl "style" command
near the button, for example "style="width: 280px; height: 30px". (The
present inventor has not yet seen any Internet site that uses this
command to create buttons that are wider than their height). As can be
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 47/98
seen in the example of a question in Fig. 10, the elongated square (91 )
shows the area from which the radio button of the "self description" can
be changed, the elongated squares (92) show the 2 areas from which the
checkbox buttons can be changed, and the elongated square (93) shows
the area from which the radio button of the importance can be changed.
(Of course, this is just an example and other ratios and/or differences in
sizes can also be used). However, it should be noted that currently for
example MSIE (Microsoft Internet Explorer) and Netscape version only
show the elongated square when the user actually clicks within it. It
would be more preferable to change the actual implementation by the
browsers so that for example the elongated squares are visible all the
time, or even more preferably, they are visible whenever the mouse is
within the area of one of them even before the user clicks on it, or for
example only the specific square becomes visible when the mouse is
within its area, even before clicking on it. This way the user can find
more easily the borders of the clickable area each time. Another
possible variation is to show for example the radio or checkbox button
itself in the expanded form, as was done by Netscape 6.2, except that
preferably the mark within it is also enlarged accordingly for example
automatically, or for example the "style" command is expanded to
include also the ability to define the size of the mark within the button.
(In Netscape 6.2 the mark within the larger radio button is a miniature
dot). Another possible variation is for example to allow the programmer
to define a separate elongation to the right and to the left of the button.
Of course this can be used for example also in combination with making
clicking on the text near the checkbox or radio button also activate the
button, preferably by using the "target" tag and an appropriate "onclick"
command, for example:
<a target=" blank" class="radio" onclick="FormQuest.self[4].checked
=true;parent.q.question[2].self=4">Has M.A. degree or more</a>
in addition to the radio or checkbox itself. However, this is less
important, since clicking on the nearby text in order to mark the radio or
checkbox button next to it is unnatural, so being able to click near the
button instead of only in it is much more important. (Another possible
variation is for example to add another html command and/or add for
example one or more additional options for example to the "style"
command, so that preferably the user can define for example the width
of the area that will affect the button without causing the rest of the line
to move away from it, which is what happens with the current "style"
command. Another possible variation is for example to expand the
command set of html and/or for example of Javascript, in order to
enable for example overlapping frames, for example by letting the
programmer define the screen coordinates of each frame. This can allow
for example creating various layers over the same screen area. This can
further increase the flexibility of using various effects, for example by
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 48/98
being able to define which frame or which parts of it will be visible
and/or take precedence over each area). (Another possible variation is
that the html protocol is improved and/or the browser is improved
and/or for example Javascript is used so that user can for example also
unmark a marked radio button even without marking another radio
button instead, for example by clicking the right mouse button over the
radio button, or for example clicking the normal mouse button while
pressing some key, or for example pressing some undo key, etc.).
b. Preferably the html command set and/or for example the Javascript
command set is improved so that preferably it is possible to define
which button (or buttons) will be activated by default for example if the
user presses for example the Enter Key and/or for example the Space
Key, so that for example in the case of Fig. 10 for example preferably
the "Next Question" button is defined as the default button (so that the
user can quickly move on to the next question without having to move
the mouse to that button). Currently to the best of my knowledge there
is no way to do this. (Although it is possible for example to define
which button will be in focus, this changes immediately when the user
clicks on anything else). So preferably there is added for example a
command such as for example:
<input type=button value="Next Question" onclick="parent.showNextQuestion"
defaultby="Charl3,char32,PgDn">
Preferably such a command allows for example to associate any key or
keys with any button (or at least for example some keys with some
buttons), so that for example pressing page Down (PgDn) can also
activate this button, and for example Page UP can be similarly
associated for example with the "Prey Question" button in the example
of Fig. 10. Of course, this is just an example, and many other forms of
such commands might also be designed. Also, preferably if for example
the PageUp and/or PageDown and/or arrow keys are not defined
explicitly for some other specific action, preferably for example the
html and/or Javascript and/or the browser are preferably defined so that
by default they will cause the page to move up or down even if the focus
is on a text field, unlike the prior art where the user would have to first
click with the mouse outside of the text field. This is very convenient,
since clearly if the user presses PageUp or PageDown or arrows even
when the focus is still within a text field, the user probably wants to
move up or down. Another possible variation is that for example the up
and down arrows can be used for jumping between form field lines
(unlike today, where only the Tab key and shift-tab allow movement
between fields without having to use the mouse). However, preferably
they can be defined for that anyway for example by the Javasrcipt or
html programmer as explained above.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 49/98
_c. Another possible variation is to improve the command set of the html
and/or for example of Javascript, so that for example pressing a button
for more then a certain time causes automatic repeat. So that for
example by keeping the "Next Question" button pressed in the example
of Fig. 10 the user can quickly browse forward through the questions
and for example by keeping the "Prev Question" button pressed in the
example of Fig. 10 the user can quickly browse backwards through the
questions (Of course, since these are virtual buttons, the real button that
is pressed in this case is preferably the mouse button).
d. Another problem is that for example with the Javascript questionnaire of
fig. 10 there can be various problems for example with using Hebrew,
since various parts in the code are currently implemented differently
from other parts and implemented differently for example in Netscape
and in MSIE. For example text within Alert messages can be treated one
way, text within normal printing can be treated another way, and text
within buttons can be treated another way. This can cause
inconsistencies that make it hard for programmers to make the Hebrew
appear OK in all cases, and this problem is even further complicated by
the fact that for example sometimes a new version of a browser treats
something differently than a previous version, which means that the
programmer has to check all the time if the new versions also work OK,
and if not, the programmer might have to create for example a different
version of the questionnaire to work which each version of the browser
that works differently. This can also cause additional problems to the
users, since sometimes the browser does not detect properly which
version of the encoding is correct, and then the user might for example
have to correct the encoding manually (through the View menu in the
browser) for example from Hebrew-Visual to Hebrew-Logical, or vice
versa. (In addition, in a Javascript page even this might not help since
the changed encoding might not effect all the parts). So preferably this
is solved by adding for example to the HTML command set an encoding
command, for example as an additional option in the <font> tag, and/or
adding for example various commands for various parameters of
handling text in other languages. In addition, if the programmer has to
prepare different versions of the questionnaire for different versions of
browsers (for example because of language problems or for example
because of new features, such as for example the differently sized
buttons, that are supported only by later versions of the browsers and
cause problems if used with an older version), then the programmer
might have to offer the users a menu of different versions of the
questionnaire according to which version of which browser they are
using, and/or for example detect automatically if the user chose the
wrong version, and then preferably switch automatically to the correct
version. However, this might require passing parameters to the other
version, so preferably the Javascript and/or html command set is
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 50/98
expanded to include the possibility to use for example the "location"
command (which switches to another page) or a similar command
together with the ability to transfer one or more parameters that can
contain data between the pages (this can also be done for example
through browser cookies, but being able to use parameters can make it
much more convenient and easy to use). (Of course the programmer can
also for example use just one version of the questionnaire with various
dependent commands that change according to the detected version,
however if there are many changes this can make the version very
cumbersome and also might make it work too slow because of too many
IF's).
e. In addition, preferably the system is able to detect and/or report
automatically for example cases where users stop filling the
questionnaire in the middle and/or for example quit for some reason.
This can be done for example by sending an automatic email message to
the site operators (or for example adding data to one or more files) for
example after the user finishes each part of the questionnaire (or for
example only at one or more checkpoints) and/or for example using an
automatic timer since the user starts filling the questionnaire or since he
starts filling various parts of it, so that preferably the system can
automatically detect such problems. (This can be done for example by
using a button for moving to the next part, which is actually defined as a
submit button of a form and activates a function which contains the
"location" command, so although the user is moved to the next part by
the "location" command, the submitted form also does something else at
the server side at the same time). This can be used for example for
obtaining statistics about what percent of users have problems for
example with each part of the questionnaire and/or for example finished
some parts but not other parts, and/or for example for sending
(preferably automatically) an appropriate email to such clients,
preferably with questions on what exactly was the problem, etc.
_f. Preferably the Internet browsers are improved so that the user can for
example preferably easily change the font size of the web page when
printing it, so that for example the user can make a hard copy of search
results or of the data of a compatible date at any convenient size. This is
preferably correlated with a WYSYWIG adjustable display on the
screen. This is different from the prior art, which allows increasing font
size on screen in Internet browsers but does not enable changing the
font size when the page is printed. In addition preferably the user can
also change any colors and/or background colors of a certain page or a
certain site in a way that will be remembered by default for example
only for that web page or for example for that domain, but preferably
does not effect other sites. This is better than the prior art, since in the
prior art if the user wants to use for example his own colors this choice
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 51 /98
effects automatically all sites, so the user has to switch this on or off
each time he enters a site that needs a change from the previous choice.
Another possible variation is that for example the user preferred font
size can also be remembered automatically preferably by the browser,
preferably for example per site or per page. (Of course, like other
features of this invention, these features can be used also in general,
independently of any other features of this invention).
Of course, various combinations of the above can also be used. Like other
features of this invention, these features can be used also independently of
other features, including for example independently of any dating and/or any
IM application.
27. Another problem is preventing for example users from filling by mistake
their
wrong sex, which can happen if there are no special precautions to prevent it.
Preferably the chance for this is reduced by at least one of the following
means:
a. Preferably the system indicates the self marked sex clearly after the
person
has marked it, preferably also in each subsequent section of the
questionnaire, so that if the user made a mistake he/she can clearly see it.
b. If the system has at least some sex-different questions, such as for
example
bust size for women and for example facial hair for men, preferably the
system indicates near these questions that if the question does not fit then
probably the user has made a mistake in indicating his/her own sex.
c. Preferably the system automatically checks if the requested wanted date's
age range in comparison to the user's own age fits the usual pattern of the
marked sex, and warns the user in case it does not, to make sure if he/she
filled the correct sex (or for example did not fill properly the ages). This
is
a very good heuristic since almost always females want males in a range of
ages that goes only or mainly above their age and males want females in a
range of ages that goes only or mainly below their age.
d. Another possible variation is for example automatic analysis of the user's
photo, if the user provided a photo, so that the system can preferably
automatically indicate if the photo does not fit the marked sex, however
that of course requires much more sophisticated processing.
28. Another possible variation is that the system can allow users to explore
connections between users (for example through automatically generated
graphs), and preferably the connections can be automatically defined for
example when a user brings friends to the service and/or for example when two
people exchange messages and/or add each other to their contactee lists (i.e.
become reciprocally linked through their contactee lists), or for example each
contactee list can be regarded as a list of links to the persons that are
included
in it regardless of whether the user is also in the other person's list. This
is
preferably a graph and not a tree since there can be for example also multiple
sideways connections, and there can be for example more than one route
CA 02513306 2005-08-09
09/08/05 Yaron Mayer $2/98
between two persons. Another possible variation is that the system can for
example use such information in order to show for example near each
compatible date (or for example near each compatible date for which the user
requests such analysis) if he/she is related to the user through any of the
above
connections (for example if there is a link through less then a certain number
of
steps, for example just up to 2 or 3 steps), and then preferably for example
the
user can click on an appropriate link or icon near the person and explore this
connection by viewing for example a graph that shows the relevant links.
However, if such showing of relations is allowed, preferably users can also
block it, so that for example the user can decide that whoever he/she contacts
or adds to his/her contactee list does not become visibly linked to him/her in
a
way that other users can see, since this might for example compromise his/her
privacy. Preferably for example the user can mark which of his/her contactees
can be viewed by others (Preferably the default is for example that his/her
contactees can be viewed, so that the user has to mark for example a specific
contactee or for example a group, preferably by dragging the mouse over the
entire group, if he wants them not to be visible to others or to other that
are
connected too him. Another possible variation is that by default the user's
contactees are not visible to others or to others that are connected to the
user
and the user has to explicitly make them visible, but that is less preferably
since it would automatically make the network smaller), however, in the
context of dating of course preferably only the user's dating contactees
become
visible by default (This can be done regardless of whether the dating
contactee
lists is a separate contactee list or dating contactees are simply marked as
such
in a more general contactee list, etc.). Another possible variation is that
the
graph shows also preferably automatically the strength of the links (for
example by a different color and/or thickness of the link), so that for
example
direct links that are reciprocal (for example if both persons are in each
others
contactee list) are automatically marked as stronger links and/or for example
the strength of the link is automatically determined also by the number of IM
messages and/or normal messages exchanged between the users and/or the
recency of them, etc., and/or for example each user can also mark manually in
his/her contactee list which links he/she considers most important and/or
other
characteristics of the link and this is preferably also taken into
consideration.
Another possible variation is that if information about such connections is
used, it is preferably limited for example to for example just 1-3 steps, and
is
preferably displayed in a limited way, so that for example if two users have a
common friend (for example if both have the same person on their contactee
list directly or for example through 1 or 2 or a few additional steps, and/or
for
example the same person has such a reverse link to them), then the system can
for example automatically indicate to these users that they have a common
friend and/or for example indicate how many such common friends they have
and/or indicate who these common friends are and/or how they are connected.
Another possible variation is that the user can use such relations as part of
the
search criteria, such as for example find all potential dates (or for example
people in general or according to various criteria) for which there is a link
of
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 53/98
no more than 3 steps (or any other convenient number, etc.). The above
variations are much better than normal social networking sites, where people
have to wait until invited in order to join the network or can for example
search
only a network tree which starts with friends which they themselves added, and
the above automatic generation of connections is much more efficient. Of
course, like other features of this invention, this can be used also
independently
of other features of this invention, for example in systems without dating
features.
29. Another possible variation is that the system can for example allow users
to
post assessments or comments on other users that they have met or contacted,
for example in a way similar to the way that eBay clients can report on their
previous experiences with specific sellers, so that for example when a user
gets
the details of a compatible date, there is also a link to comments by other
users
about that person, if other users have already posted comments about him/her.
Another possible variation is that the system can for example recommend
automatically to users for example that other users who have added a certain
person to their contactee list typically added also the following other
persons
(so that the system preferably uses various statistics to determine the most
relevant patterns - for example showing such additional persons only if a
certain percent or above of other people that added for example that girl to
their contactee list also added that specific additional person)(for example
in a
way similar to book recommendations in Amazon). However this is less
preferable, since there can be a lot of differences in user preferences, and
also,
for example the knowledge that many other people added certain potential
dates to their contactee lists might actually be a turn off for at least some
users.
Another possible variation is to add the recommendation only if the other
people that added the relevant person or persons were also similar enough to
the user in the profile of their desired date beyond a minimal similarity
value.
Another possible embodiment of this invention is to use at least some of the
above
features in a normal preferably Internet computer dating service, preferably
with the
additional requirement that each user must also supply a phone number
(preferably
with the option of requesting "protected phone" as described above) and
preferably
also an instant messaging id if available. This is preferably done together
with
reciprocal compatibility search, since people are more willing to give the
phone if
they know that the people that get them also fulfill their own expectations.
The feature
of automatic notifcation (described in clause 15 above) in this case (without
instant
messaging and contactee lists as an inherent part of the system) is preferably
done for
example by sending the person that requested the notification an automatic e-
mail
message about it, or SMS, (or for example an automatically generated phone-
call,
preferably if he/she pays for it), preferably including the phone number (or
proxy-
phone number as a code or a link without code) of the new person (preferably
in
addition to the new person's e-mail, and preferably also IM number, if
available), so
that the person receiving the notification can also contact the new person
immediately. This is in contrast to the state of the art, in which users are
updated only
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 54/98
on a periodic basis or when they perform a search. Another possible variation
is that,
at least for users that gave also an IM id number, the system tries to find
out if they
are currently Online for example through an element that contacts the relevant
server,
and if so, when showing a potential date's data on a dating search results
list, the
system preferably shows also his/her IM id number, the IM network that it
belongs to,
and an indication if he/she is currently Online, so that the user can
instantly contact
him/her through the appropriate IM client program. Another possible variation
is that
being Online can be defined by at least one of the following two conditions: A
user
has logged into the system with his/her user name and password not longer than
a
certain time ago, b. A user has performed at least 1 activity in the system
not longer
than a certain time ago. Another possible variation is that the system allows
users to
send to persons who are currently online according to the above definition
instant
messages for example by displaying a preferably visibly conspicuous messages
to the
person for example the next time he/she tries to access pages on the system
(for
example any page, or most pages or the menu) (this can be done for example by
generating a page on the fly when the system recognizes by browser cookies
that this
is the person for whom the message is intended) and preferably one of the
options on
this generated page is for example to press a link that enables the users to
enter a chat
channel. Another possible variation is that some or all of the pages on the
dating site
have an automatic refresh instruction (for example once every minute or every
few
minutes, for example through an html tag or through Javascipt or ActiveX, if
the
browser supports it) and the user simply has to leave at least one window of
the
browser open on the site (and it is preferably recommended to do so in the
instructions for users on the site) and the user can for example go on sliding
in other
windows, and when there is a notification for him/her, then it is included
automatically in the next refresh, preferably with the addition of an audible
sound that
can get the user's attention. If it is done for example by Javascript or
ActiveX,
preferably the Javascript or ActiveX (or for example other software or mobile
code)
can also check for example if the user continues to actively use the browser
(in order
to be able to apply more efficiently the activity rules to check if the user
is still
Online), and when requesting the refresh the browser can for example transfer
an
additional parameter to the requested url that represents the Online status of
the user.
If it is for example ActiveX, this can be even more comprehensive, because the
ActiveX (or for example other software or mobile code) can preferably know for
example if the user typed or clicked anything at all and not just used the
browser. This
has the advantage that no special client program is needed in addition to the
browser.
But regardless of which exact technique is used, the idea of checking if the
user has
clicked on anything (for example keyboard and/or mouse) is important since it
is
more preferable than just deciding if the user is still "in the dating site"
on not, since if
the user is still near his/her computer and is connected to the Internet,
he/she can
preferably be reached by the IM features even if he/she has "left" the dating
site, i.e.
for example has not done any recent activity in the dating site itself. Of
course, adding
additional IM features to an online computer-dating service can make it
equivalent to
adding Computer Dating features to IM networks. Using an independent IM client
has
of course the additional advantage that users can be "spotted" as being Online
even if
they don't enter the dating site. And as explained above, the IM client can be
for
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 55/98
example a plug-in in the browser (which preferably installs itself
automatically in all
the relevant browsers on the user's computer), so that for example the dating
site can
install the plug-in the first time the user agrees to use the IM client (This
means that if
for example such a plug-in is used, when users want for example to initiate or
respond
to an IM message, preferably their plug-ins can of course for example
communicate
directly with each other like normal IM clients, and/or for example they can
open a
browser widow on the dating site and make the communication or at least part
of it
through these browser windows, for example by any of the above methods).
(Another
possible variation is that for example a server in the dating site or related
to it can
automatically run appropriate IM clients or client simulators on behalf of
users on the
server, so that for example if the user does not want to download any IM
client or
plug-in and for example has currently an open browser window in the dating
site or
for example has defined being Online according to his AOL's AIM client and for
example a certain girl in his results lists also did not want to download a
plug-in and
has defined her Online status for example according to her MSN messenger
client,
then the dating site can for example convert messages between the user's
browser and
the other IM client, or for example between the two different IM clients,
preferably by
using a proxy IM user number which is actually on the client that runs on the
server,
so that when each user gets the IM user number of the other user, preferably
it is
actually the proxy user number that is run on the server. As explained above
in some
of the above variations the server can for example communicate with the IM
server of
each user to find if his/her real user number is currently Online, and for
example in
this case the dating server or related server preferably can for example find
out if the
girl is online through her MSN messenger network, and then in addition the
dating
sever or related server for example preferably sends the appropriate info to
the AIM
server as if the proxy client of the girl is now Online, so that the user can
see that she
is Online on his IM client, and vice versa for example for showing her that he
is
Online, etc. However such an implementation can be much less efficient and
more
problematic than downloading for example a browser plug-in or independent IM
client or plug-in for other IM clients (or other software), so that, as
explained above,
this plug-in or software on the user's computer can preferably implement or
work
with the dating site's own IM network and/or talk directly with clients and/or
servers
of other IM networks, so that it can for example pretend do be an IM client in
a
number of major IM networks). Preferably the Online status of dates in the
list of
compatible dates is automatically updated if it changes while the list is
still open (for
example if the user has kept the window of the list open or has previously
saved it and
reopens it), for example by automatic refresh, for example every minute or
more or
less. Another possible variation is that in order to save bandwidth for
example the
html protocol is changed so that it is possible to define for example "refresh
on a need
basis", which means that the refresh command is initiated automatically by the
site
when there is any change in the preferably dynamic page (so that the browser
can get
a refresh even if it didn't ask for it), or for example the browser asks for
refresh more
often (for example every 20 seconds or even less), but if nothing has changed
then the
browser gets just for example a code that tells it to keep the current page or
window
as is. The first of these two variations is more preferable since it saves
also the waste
of bandwidth by unnecessary refresh requests by the browsers. In addition,
when the
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 56/98
refresh is sent, preferably it can be a smart refresh, which tells the browser
preferably
only what to change on the page instead of having to send the entire page
again.
Another possible variation is to implement this "refresh on need" for example
by
active X and/or Java and/or Javascript and/or some plug-in or other dynamic
code that
is updated only when there is a need for it. Another possible variation is for
example
to keep the page open like a streaming audio or video so that the browser
always waits
for new input but preferably knows how to use the new input for updating the
page
without having to get the whole page again and preferably doesn't have to do
anything until the new input arrives. These features are even more important
for
example for the implementation of the instant messaging and/or the automatic
notification if it is done with automatic refresh, in order to increase
efficiency and
speed of communication. In addition, of course the contents of each page or
window
that contains an IM session are preferably saved on the user's computer and/or
on the
dating site preferably after every new message and/or at least when the window
is
closed, so that even if the window is closed and the user reopens it, the
history of the
IM session and/or all the history of communication with the given other user
is
preferably automatically available to the user, in order to make it preferably
equivalent to an IM network that keeps a history of communications between
users.
Of course, like other features in this invention, the above features or
variations can be
used also independently of any other features of this invention, for example
also
independently of any dating application and/or of any IM application.
Preferably, this
method can also be used as an additional option for the automatic
notification.
Another possible variation is to use some combination so that for example the
service
is done with two separate interfaces - one as an Instant Messaging network
with
dating features added to it and one as a dating site with Instant Messaging
features
added to it, but preferably use the same database, so that practically the
users can be
matched with compatible users from the entire database, no matter which
interface
they used. In this case the adding of IM features to the dating site is
preferably by
connecting directly to the IM network, since the user needs to know if any
matching
date is Online according to the IM network. However, another possible
variation is to
use at the dating site a combination with the additional methods for
determining if
someone is currently Online, such as for example those described above, so
that the
system can know if users are Online or offline even if they choose not to use
the client
program of the IM network. Anyway, if a contactee list is used both on the
dating site
and in a related IM client (For example in a dating site with IM features a
list of
preferred dates which shows when they are Online is actually a contactee list
according to the above definition of a contactee list), preferably the user
can
preferably easily and preferably directly copy dates from the list of
preferred dates (or
other contactee list) to his/her IM contactee list and/or vice versa.
Preferably this
copying can be done for example by requesting the system to automatically copy
for
example to the IM contactee list the details of any dates that appear on the
list of
preferred dates but don't appear yet in the IM contactee list (and/or vice
versa), or for
example marking specific dates or groups or ranges of dates for copying, or
for
example the data is not really copied but only linked to the other list for
example
though pointers or cross-links, or for example any dates that appear in the
list of
preferred dates are automatically copied also to the IM contactee list
(preferably under
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 57/98
the category of dating, as explained above) or automatically get a cross-link
in the IM
contactee list. (Another possible variation is that for example these
automatically
copied dates to not show normally in the IM contactee list, but for example
appear
there only when the date is online). Another possible variation is that, in
addition or
instead, for example near any potential date that is shown the user has icons
for
adding the date to his/her list of favorites, to his/her IM contactee list, or
to both, or
for example after clicking on an icon for adding one or more dates, the user
is allowed
to choose if to add the date or dates to his favorites list on the dating site
or to the IM
contactee list or to both and preferably the last choice is used the next time
as default
(This transfer of information between the two contactee lists is preferably
done for
example by adding an appropriate plug-in to the browser, which is preferably
the
same browser plug-in described above, so that the plug-in can communicate
directly
with the IM client on the user's computer and/or by letting for example the
server at
the dating site communicate directly with the server of the IM network and
then the
IM server for example automatically updates the IM client, and/or for example
by
improving the IM client so that it can communicate directly with the user's
browser).
Another possible variation is that for example clicking on a date (or for
example on a
certain icon next to him/her) in the IM contactee list can automatically open
for
example a browser window on the dating site with the page that lists the data
on that
date (or for example the page that shows the list of preferred dates). Another
possible
variation is to allow users for example to "import" their data from other
dating sites,
so that if for example the user has already filled his/her data in another
dating site the
user can for example use cut & paste of the URL that displays his/her data on
the
other site or for example use cut & paste on the content of that page, and
then his/her
data is preferably automatically converted to the correct format in the
current dating
site. This can be done for example by creating the appropriate templates
and/or
conversion rules at least for the largest other dating sites, and for example
for any data
that is missing the user can be preferably automatically asked to complete
only the
missing data. However, in order to avoid legal complications if for example
someone
"imports" this way the data of another user without his/her consent,
preferably if such
importing is allowed, preferably this procedure is combined with sending an
email to
that user or for example a message to his/her message box on the site from
which
his/her data is being imported or for example an instant message, preferably
automatically, for verification, and preferably automatically logging the
reply.
Another possible variation is for example automatic importing of contactee
lists from
other IM networks, so that if the user has for example a few dozen people in
his/her
contactee list on a certain IM network and he/she wants to be able to access
them also
in another IM network, he/she can for example initiate an automatic search
preferably
for all of them (for example according to name, nick name, email, and/or other
identifiers) to check if they exist there too (so that the system preferably
searches
automatically for each of them, without the user having to activate the search
manually for each one) or for example send to all of them an automatic
question if
they are listed also in the other IM network, or for example an automatic
invitation to
join also the other IM network, etc. Of course, if and when various IM
networks
eventually allow direct communication across different IM networks, preferably
the
user will automatically be able to import his/her contactees from other IM
networks to
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 58/98
be added to his/her contactee list in the desired IM network (for example with
an
indication to which IM network they belong). This can be implemented for
example
in any of the ways described in the patent summary. Another possible variation
is that
if the site uses for example mailboxes for sending messages to other users
apart from
IM (for example when the user sends a message instead of an IM for example
because
the other user is not currently Online), preferably a copy of the message
itself (and not
just a notification about the message) is automatically sent also the email of
the
receiving user (so that the user can have an even higher motivation for
example to
click on the link and go to the site). Of course, various combinations of
these
variations can also be used.
Fig. 1 shows a preferable way in which the user fills the questionnaire as a
plug-in or
add-on within an instant-messaging client program. When the user activates the
client
( 11 ), the system first checks if the user has already been registered in the
system and,
if not, gives him/her a new unique user id, and/or the system can also use for
example
the id that the user has in the network in which he/she is a member together
with a
code of the network. (This check can be done either by checking locally on the
user's
computer or by checking on our servers) on the Internet) ( 12). If the user
hasn't filled
the questionnaire already, he is asked to fill it, including preferably his
self
description, description of the ideal date, and the importance for each
question (13).
Then, if the user has made changes or has filled the questionnaire for the
first time,
the user's data is saved, preferably both on the user's computer and on our
servers(s)
on the Internet in a static database of all users who filled the questionnaire
or in a
dynamic database of users currently online (14). After this, the user
continues to work
with the instant messaging client (15).
Fig. 2 shows a preferable way in which the user fills the questionnaire as a
standalone
application or as part of custom-made instant messaging client. First the
system
checks if the user has already been registered in the system and, if not,
gives him/her a
new unique user id, and/or the system can also use for example the id that the
user has
in the network in which he/she is a member together with a code of the
network. (This
check can be done either by checking locally on the user's computer or by
checking
on our servers) on the Internet) (21 ). If the user hasn't filled the
questionnaire
already, he is asked to fill it, including preferably his self description,
description of
the ideal date, and the importance for each question (22). Then if the user
has made
changes or has filled the questionnaire for the first time, the user's data is
saved,
preferably both on the user's computer and on our servers(s) on the Internet
in a static
database of all users who filled the questionnaire or in a dynamic database of
users
currently online (23). After this, the user either activates the instant
messaging client
program which is coupled to the search plug-in or add-on (if the standalone
filling
application works in conjunction with the existing main instant messaging
networks)
or continues to work with the standalone's own instant messaging client (if it
is part
of our own instant messaging client) (24).
Fig. 3 shows a preferable way in which the dynamic database of users that are
currently Online works. As soon as the user opens the Internet connection and
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 59/98
activates the instant messaging client (which is either our own client program
or the
client program of one of the common instant messaging networks with our custom-
made plug-in or plug-ins or add-on or add-ons), preferably a message is sent
to the
dynamic database servers) containing the user's filled compatibility
questionnaire
data (31 ). Then our client or the plug-in or add-on coupled to the client
preferably
keeps sending at short intervals a short message to one of our servers
containing the
user's unique id so that the system can tell if the user is still logged-in
(preferably
these short messages are sent either to the Database server itself or to
another server,
which will in turn notify the database server if the messages stop coming)
(32). (of
course, if it is a plug-in or add-on to an existing client program, it is also
possible to
get such info by letting our server query the normal server of the client, but
that is less
efficient and might be for example blocked by the normal server of the
client).
Another possible variation is for example instead of using short messages at
short
intervals, for example to rely on some automatic logoff signals, however since
that is
less reliable, such a method is preferably accompanied for example by
automatic
notification to the server and/or to other clients whenever attempts (for
example by
the server or by any other client) to communicate with the user who is still
supposed
to be online show that he/she is no longer online. In other words: The IM
server is
automatically informed by other IM clients if they try to reach a client that
is
considered Online but don't succeed and thus the IM server can assume that
that IM
client is no longer Online, and/or assumes so if the server itself does not
succeed to
connect to that client. Similarly, preferably if the server and/or other
clients receive
communications from a client that was considered to be offline, the receiving
clients
report it to the server and the server updates its status to Online. If
automatic logolf
signals are used, preferably the client software creates a hook or interface
with the
communication software and/or with the routines that are activated when the OS
(Operating System) is shut down so that when the user closes the client
software
and/or the Internet connection and/or shuts down properly the OS, the client
software
can still first send to the IM server a message that the user has logout out,
before
letting the connection to actually be closed. However, since the user might
for
example turn off the computer through the power switch or through pressing
reset
(without properly shutting down the OS or the connection), the above automatic
notification is preferably also used. Of course, these alternative methods of
determining if a user is still Online can be used also in combination with any
other
variation in this patent. When the user requests an instant dating search (For
example
with his profile in a 2-way compatibility search or as a 1-way search or
search for a
small group of qualities, for example - find all the blondes with highest IQ
who are
currently logged in, or find them for example only if the reciprocal
compatibility
score with them is above a certain percent; Other search options can be for to
example
find only dates with a minimum compatibility score requested by the user, but
preferably the user cannot request a minimal score lower than a certain
minimum
required by the system as the minimal acceptable compatibility score), the
client
sends the appropriate request to the dynamic database (33). The dynamic
database
will make the search accordingly and send back the list of most compatible
dates that
are currently connected, preferably including various details about them
according to
the type of search. The user may also add any of them to his/her contactee
list and can
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 60/98
be notified immediately when they are Online again (34) in a similar way to
the
description of 44. When the short messages from the client cease reaching the
appropriate server, indicating that the user is no longer connected, his data
is removed
from the dynamic database (35).
Fig. 4 shows a preferable way in which the static database of users that
filled the
compatibility questionnaire works. After the user finishes filling the
questionnaire or
makes changes to it, his or her data (including also his name, e-mail and
unique user
Id) is transferred to the static DB (41 ) and is preferably saved also on the
user's
computer. As soon as the user activates the instant messaging client,
preferably short
messages are again sent to the appropriate server as in Figure 3, and the
static
database also preferably sets a logged-on mark in the record of each user that
is
currently logged-in on the Internet (This mark may be also set for example at
a
separate file or index or pointer in addition or instead, and held for example
in RAM
memory for maximum access speed, or on the disk, or both) (42). When the user
requests a dating search (again, for example 2-way compatibility or 1 way
search or
search for just certain attributes), preferably he/she may also choose if
he/she wants to
search for all compatible dates or only those that are currently Online. (If
the user
wants to search only for people who are currently online, preferably he has
the option
of choosing for example a maximum time that elapsed since someone was online
or
the minimum average frequency that someone is online) (43). The list of most
compatible dates (again, preferably, with various details) can be added to the
user's
list of contactees in the instant messaging client (if it's our own client or
the contactee
is a member of the same network) or to a special list maintained by the plug-
in or add-
on (if it is a plug-in or add-on coupled to one of the common instant
messaging
clients). Preferably, the user has a choice of marking which of these
compatible dates
to add to his contactee list or which of them to remove. (44). If any of these
chosen
compatible dates becomes Online, the user is preferably immediately notified
about it
(45). When a user is no longer online, his/her on-line mark or marks are set
again to
off (46).
Fig. 5 shows a preferable way in which the compatible-date search application
works
as a plug-in or add-on within an instant messaging client. When the user wants
to
search for new compatible people, he/she chooses within the plug-in or add-on
for
example if he/she wants to execute a 2-way compatibility search or just search
for
people with certain qualities (and also if to search only for people currently
Online, if
it is a static DB) (51 ). The plug-in or add-on then transfers the search
request to the
appropriate DB server (Which can be for example static, or dynamic, or both)
and
then displays the results to the user as explained in fig 3 and 4) (52).
Fig. 6 shows a preferable way in which the compatible-date search application
works
within a custom-made instant messaging client (in other words - our own
client).
When the user wants to search for new compatible people, he/she chooses for
example if he/she wants to execute a 2-way compatibility search or just search
for
people with certain qualities (and also if to search only for people currently
Online, if
it is a static DB) (61). The client then transfers the search request to the
appropriate
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 61/98
DB server (Which can be for example static, or dynamic, or both) and then
displays
the results to the user as explained in fig 3 and 4) (62). This custom-made
client can
be either a stand-alone application, or work as a plug-in or add-on within
another
Internet application such as for example one of the big browsers (such as
Netscape or
Microsoft Internet Explorer), or be an integral part of it. (Of course, the
plug-in or
add-on described for example in Fig. 5 can also be for example coupled to a
client
which is itself for example coupled to a browser or an integral part of it).
Fig. 7 is a schematic diagram of a preferable way that the add-on can for
example let
the client or part of the client act as if it is communicating with another
client of the
same network or with its server, but translate the communication to another
protocol
and/or redirect it to the other network. When the user's client program is
trying
communicate in its normal protocol, for example ICQ, with the normal interface
of its
chat windows (71 ), if the plug-in or add-on sees that the communication is
actually
intended for or coming from a client of a different network, for example MSN
(72), it
preferably steps-in and converts between protocols as needed (73). If it's an
outgoing
communication the add-on or plug-in preferably redirects the output to the
appropriate
server or client of the other network as needed. If it is an incoming
communication it
preferably translates it into the protocol that the client program expects to
see and
makes the client think that this communication came from its own network. In
order
to enable this, preferably all the contactees that are not really members of
the client
program's IM network are specially marked by the plug-in or add-on, So that it
can
intervene when the user's client program is trying to communicate with them.
Fig. 8 is an example of a preferable way that the extended contactee list can
look like.
In the example shown the order is to show first contactees that are available
for
dating, then friends or other contactees not related to dating (marked with
"N/A" _
Not Applicable), and then people who were found in the context of date
searching but
are now no more interested or available for dating. In this example this group
is
preferably last since the user is probably least likely to want to contact
them. Inside
each group the order can be for example alphabetic and/or based on the most
recent
activity and/or on putting the persons with the longest contact history with
the user on
top, or any combinations of this, as explained in the reference to this in
Fig. 1 a.
("comm." stands for communications with the user). When someone is not
available
preferably he/she changes his/her status on his/her client, which then
preferably
propagates automatically to update all the other contactee lists where that
person is
listed. This is like having a computer dating output list which is updated in
real time
(or when the user is next Online) whenever there is any change in the status
of the
persons on the list. In this example "*F" means found someone through the
service,
"*E" means found someone elsewhere, "*TF" and "*TE" mean this new status is
only
temporary, "*FM means found someone trough the service and got married", "*EM
means found someone not trough the service and got married", "*T means
temporarily unavailable, etc. Of course other status options and codes can be
used
instead or in addition. For implementing for example the reporting on most
frequent
activity hours (activity in the IM network) (and/or for example how often the
user is
Online in general), preferably the statistics are gathered for each user by
his/her own
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 62/98
client program and sent to the server, in order to save time and not
unnecessarily
burden the server or servers, however it is of course also possible to let the
server
gather these statistics directly. Preferably, the various times data are
displayed in
terms of the user's local time zone (for example by taking into account the
different
time zones between the user and the contactee and automatically adjusting it).
Preferably the compatibility scores (as reported in the search results list)
with each
person in the contactee list are also saved automatically when the person is
added to
the contactee list, so that the user can click on or near the contactee in
order to get for
example a reminder of these scores, and/or view also the contactee's profile
or at least
part of it. Of course this is just an example and other orders can also be
used, as
explained for example in clause 2 of the reference to fig. 1 a.
Fig. 9 is an example of a preferable way that the list of most compatible
dates
following a reciprocal compatibility search can look like. Since there are
preferably a
serious number of questions (such as for example 100 or above) for enabling
really
systematic matching, it is impractical to show the full profile of the date to
the user,
and it is also undesired because: A. some questions or types of questions
(such as in
the area of personality for example) are preferably kept discrete, otherwise
people will
not answer them honestly. B. With such a large number of questions people have
a
problem analyzing and integrating all this information, so detailed
compatibility
scores plus a list of most important fulfilled expectations can help the user
see the
picture very efficiently. Another possible variation is for example to let the
user click
on the date in order to get his/her profile, but the profile is preferably
shown without
the questions marked as discrete or confidential. Another possible variation
is that
when the user requests to see the date's profile, he/she is shown only the
answers the
date gave on the questions most important to him/her (preferably with the
additional
limitation that in any case this does not include questions that are
considered discrete
or confidential). For this reason preferably in the questionnaire itself the
questions
that are considered discrete and confidential are preferably marked
differently.
(Another possible variation is that the user can also mark for example up to a
certain
amount of questions as confidential while filling the questionnaire or
correcting it, or
can mark questions in certain section as confidential if he/she chooses, but
this is less
desirable since it can make filling the questionnaire more cumbersome). This
is just
an example of a possible way of ordering the results. Another possible
variation is for
example to list the Online and Offline users together in descending order of
compatibility scores, and just add a mark, or indicate for example by
different color if
they are online or offline. For example, dates who are currently online can be
marked
in a bright color, dates who are offline but have recently been online are
marked in a
darker color, and dates who have not been online for example for a few months
(a
limit which preferably can be determined also by the user), are marked for
example in
gray. Of course, more than 3 levels can also be used. This is more useful for
people
who want to seriously find a date and don't care if he/she is currently online
or not,
whereas people who prefer for example to chat with a compatible date right now
will
probably prefer the option that lists them separately. Therefore, preferably
the user
can choose which of these options to use. Other issues of ordering the results
and of
search and sorting options were discussed in the reference to this in Fig 1 a
above.
CA 02513306 2005-08-09
09/08/05 Yaron Mayer 63/98
Another possible variation is that the user can also save this list for later
reference,
and if there is change for example in the availability for dating of any of
the persons
in the list or for example in their geographical/physical vicinity, it is
preferably
updated automatically in a way similar to the way that this status can be
updated
automatically for people in the contactee list, as explained in the reference
to Figs. 1 a
& 8. Another possible variation is that after looking at the list the user can
for
example mark persons whom he/she doesn't want to show up again in future
searches
(this set of marked persons can be saved for example on the client or on the
server or
both). Also, other variations are possible, such as for example showing on the
results
list more concise data on each person that is expanded (for example into a
separate
window) if the user clicks on that person, or displaying for example a few
separate
sets of concise results for example for each geographical area that the user
requested,
etc. Of course various combinations of these and other variations are also
possible.
While the invention has been described with respect to a limited number of
embodiments, it will be appreciated that many variations, modifications,
expansions and other applications of the invention may be made which are
included within the scope of the present invention, as would be obvious to
those
skilled in the art.
