NZ561111A - Contact system and method - Google Patents

Abstract

A system for facilitating contact between at least two parties based on an encounter between the two parties comprises a computer adapted to process and store data, and to connect to and communicate over a network to one or more remote interfaces and a storage device in or remote to the computer. The computer is programmed to retrospectively receive first information specifying the encounter over a network, identifying from the storage device retrospectively received second information specifying an encounter and facilitating contact between the two parties if the second information correlates to the first information within the tolerance. The first information identifies at least one party to the encounter, at least the time and location of the encounter and a tolerance and the second information identifies at least one party to the encounter and at least the time and location of the encounter. A contact information system comprises an interface, including a map allowing details of a meeting to be entered; storage for storing said entered information on the meeting including the location on the map and the time of the meeting; means for searching for a similar meeting; and an interface to presents matches to users.

Description

561111 RECEIVED at IPONZ on 05 November 2009 NEW ZEALAND PATENTS ACT, 1953 No: 561111 Date: 31 August 2007 COMPLETE SPECIFICATION CONTACT SYSTEM AND METHOD We, OUR PLACE (NZ) LIMITED, Building B, 63 Apollo Drive, Rosedale, NORTH SHORE CITY 0632, do hereby declare the invention for which we pray that a patent may be granted to us, and the method by which it is to be performed, to be particularly described in and by the following statement: RECEIVED at IPONZ on 05 November 2009 561111 FIELD OF THE INVENTION The present invention relates to a contact system and method, more specifically, to a contact system and method that facilitates contact between people based on an encounter between two parties.

BACKGROUND OF THE INVENTION How often have you met someone only to lose their details or have seen someone across a room but not been able to make contact with them? It would be desirable to have a system and method for getting in contact with people based on an encounter.

While social networking systems exist, traditional systems do not facilitate contact between people based on chance encounters.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a contact system and method that facilitates 15 contact between two or more parties.

In one aspect the present invention may be said to consist in a method of facilitating contact between at least two parties based on an encounter between the two parties comprising: retrospectively receiving at an input interface first information specifying the encounter, the first 20 information identifying at least one party to the encounter, at least the time and location of the encounter and a tolerance, identifying stored second information retrospectively received at an input interface, the second information specifying an encounter and identifying at least one party to the encounter and at least the time and location of the encounter, facilitating contact between the two parties if the second information correlates to the first information within the tolerance.

Preferably the method further comprises, prior to identifying stored second information, retrospectively receiving second information specifying an encounter.

Preferably the first and second information is associated with and/or received from respective 30 parties to the encounter.

Preferably the method comprises transferring contact information to facilitate contact between the two parties.

Preferably the input interface(s) is/are one or more of: a website interface, a mobile device interface.

RECEIVED at IPONZ on 05 November 2009 561111 Preferably the input interface comprises a graphical interface depicting geographical locations.

Preferably the second information correlates to the first information within the tolerance if one or more of the time, location and/or party specified by both the first and second information matches 5 to within the tolerance.

Preferably the first information and the second information may or may not specify the same encounter.

Preferably the method comprises identifying further correlation between the first and/or second information to determine if they specify the same encounter.

Preferably the first and/or second information identify a range of times and/or locations that encompass the encounter, wherein the first information correlates to the second information if one 15 or more of the locations and/or times specified by the ranges match to within the tolerance.

Preferably the range of times and/or locations that encompass the encounter identified by the first and/or second information define the tolerance.

Preferably the first and or second information comprises a code for specifying the location.

Preferably a range of times and/or locations are specified using a slider on a graphical interface.

Preferably the tolerance is specified using a slider on a graphical interface.

Preferably the first and or second information are received via text messaging or email.

In another aspect the present invention may be said to consist in a method of facilitating contact between at least two parties based on an encounter between the two parties comprising: 30 retrospectively receiving information on a plurality of encounters at one or more input interfaces, each information specifying the time and location of an encounter and a tolerance, receiving a request for a match to an encounter, searching to identify information specifying one or more encounters that correlate to that encounter to within the tolerance, and conveying the identified information.

RECEIVED at IPONZ on 05 November 2009 561111 In another aspect the present invention may be said to consist in a system for facilitating contact between at least two parties based on an encounter between the two parties comprising: a computer adapted to process and store data, and to connect to and communicatc over a network to one or more remote interfaces, a storage device in or remote to the computer, wherein the computer is 5 programmed to: retrospectively receive first information specifying the encounter over a network, the first information identifying at least one party to the encounter, at least the time and location of the encounter and a tolerance, identifying from the storage device retrospectively received second information specifying an encounter, the second information identifying at least one party to the encounter and at least the time and location of the encounter, facilitating contact between the two 10 parties if the second information correlates to the first information within the tolerance.

Preferably the computer is programmed to, prior to checking for stored second information, retrospectively receive second information specifying the encounter.

Preferably the first and second information is associated with and/or received from respective parties to the encounter.

Preferably the computer is programmed to transferring contact information to facilitate contact between the two parties via the network.

Preferably the first and/or second information is received via a one or more remote interfaces being one or more of: a website interface, a mobile device interface.

Preferably the first and /or second information identifying the location of the encounter is received 25 via a graphical interface on the remote interface depicting geographical locations.

Preferably the second information correlates to the first information within the tolerance if one or more of the time, location and/or party specified by both the first and second information matches to within the tolerance.

Preferably the first information and the second information may or may not specify the same encounter.

Preferably the computer is programmed to identify further correlation between the first and/or 35 second information to determine if they specify the same encounter.

RECEIVED at IPONZ on 05 November 2009 561111 Preferably the first and/or second information identify a range of times and/or locations that encompass the encounter, wherein the first information correlates to the second information if one or more of the locations and/or times specified by the ranges match to within die tolerance.

Preferably the range of times and/or locations that encompass the encounter identified by the first and/or second information define the tolerance.

Preferably the first and or second information comprises a codc for specifying the location.

Preferably the tolerance is specified using a slider on a graphical interface on the remote interface (s).

Preferably the remote interface(s) provide a slider on a graphical interface to receive input specifying a range of times and/or locations.

Preferably the first and or second information are received via text messaging or email.

In another aspect the present invention may be said to consist in a method of obtaining contact information on a third party you have previously met in person comprising the steps of: providing graphical interface in the form of a map that allows a user to enter details of a meeting that took 20 place; storing information on the meeting including the location on the map and the time of the meeting; searching on a storage device for a similar meeting and presents matches to users.

Preferably the meeting details comprise a security question known to the users who entered the meeting details.

Preferably the method comprises providing details of the other matched party.

Preferably the method comprises obtaining permission from the parties to swap details.

Preferably the meeting details are received via a SMS, web interface and/or email.

In another aspect the present invention may be said to consist in a contact information system comprising: an interface, including a map allowing details of a meeting to be entered; storage for storing said entered information on the meeting including the location on the map and the time of 35 the meeting; means for searching for a similar meeting; and an interface to presents matches to users.

RECEIVED at IPONZ on 05 November 2009 561111 Preferably the meeting details include a security question known to the users who entered the meeting details.

Preferably the system provides details of the other matchcd party.

Preferably the system comprises an interface to obtain permission of the parties to swap details.

Preferably the system comprises an SMS gateway and the system may receive meeting details via SMS.

Preferably the system comprises at least one communication interface selected from a web interface, an email server interface and an SMS gateway interface and said system communicates with system users via at least one of said communication interfaces.

In another aspect the present invention may be said to consist in a method of facilitating contact between at least two parties based on an encounter between the two parties comprising: retrospectively receiving first information at an input interface specifying the encounter, the first information identifying at least the time and location of the encounter and a tolerance, identifying stored second information retrospectively received at an input interface, the second information 20 specifying an encounter and identifying at least the time and location of the encounter, facilitating contact between two parties associated with the information if the second information correlates to the first information within the tolerance.

In this specification where reference has been made to patent specifications, other external 25 documents, or other sources of information, this is generally for the purpose of providing a context for discussing the features of the invention. Unless specifically stated otherwise, reference to such external documents is not to be construed as an admission that such documents, or such sources of information, in any jurisdiction, are prior art, or form part of the common general knowledge in the art The term "comprising" as used in this specification means "consisting at least in part of'. Related terms such as "comprise" and "comprised" are to be interpreted in the same manner.

To those skilled in the art to which the invention relates, many changes in construction and widely 35 differing embodiments and applications of the invention will suggest themselves without departing RECEIVED at IPONZ on 05 November 2009 561111 from the scopc of the invention as defined in the appended claims. The disclosures and the descriptions herein are purely illustrative and are not intended to be in any sense limiting BRIEF DESCRIPTION OF THE DRAWINGS Disclosed embodiments and methods of utilizing the invention will be further described, with reference to the accompanying figures, by way of example only and without intending to be limiting, wherein; Figure 1 is a diagram of a system according to one embodiment, Figure 2 is a flow chart of a method implemented by the system, Figure 3 is a diagram of a software structure implemented by the system, Figures 4, 5 is a flow chart depicting methods for entering encounter information and storing it, Figure 6 is a flow chart depicting a method for finding matching encounters, Figures 7 to 13a show screen shots of a user intcrfacc of one embodiment of the system, Figure 13b is a flow chart depicting a method for finding a matching encounter, Figures 14 to 18 show screen shots of a user interface of one embodiment of the system, Figure 19 is a flow chart depicting a method for conducting a broadcast function, Figure 20 is a diagram of the graphical data entry screen showing a number of existing entries, Figure 21, is a diagram of the graphical data entry interface of the present invention, Figure 22 is a graphical data entry interface of the present invention illustrating a meeting being entered, Figure 23, is a graphical data entry interface of the present invention illustrating a meeting being entered and the user being prompted for a secret code, Figure 24, is a graphical data entry interface of the present invention illustrating a match being 25 displayed, Figure 25 is a graphical data entry interface of the present invention illustrating the information on a match being displayed, Figure 26 is a graphical data entry interface of the present invention illustrating the display of information that there are too many matches, Figure 27 is an example email from the system requesting a shared secret question be answered, Figure 28 is an example email from the system confirming a match, Figure 29 is an example email from the system including the match information, Figure 30 is an example email from the system notifying the user that a match has not been found, Figure 31 is an example email from the system notifying the user that too many matches have been 35 found, Figure 32 is an example SMS screen that a user could submit, RECEIVED at IPONZ on 05 November 2009 561111 Figure 33 is an example SMS screen requesting the secret question answer from the user, Figure 34 is an example SMS screen confirming a match to a user, Figure 35 is an example SMS screen passing details of the other party onto a user, Figure 36 is an example SMS screen that a user would receive when too many matches are identified, 5 and Figure 37 is a flow diagram of the process of the present invention.

DETAILED DESCRIPTION OF THE INVENTION Definitions In this specification the following terms are used: "encounter" relates to any event where two or more parties encounter each other in some manner, either physically or otherwise. This may take form of a coincidence chance meeting at a location, although is not restricted to just that event. "met" means "to come upon, to come into the presence of' and "meet" has a corresponding meaning. "encounter information" relates to information provided by a party that can identify/specify/define 20 an associated encounter. Encounter information will comprise at least time and location information of the encounter. It can optionally further comprise additional information such as: identification of the parties to the encounter, distinguishing information, or the like. A particular "bundle" of encounter information that specifies an encounter can be termed an instance of encounter information. "source encounter information" is encounter information that is used as the basis for finding matching encounter information. Source encounter information can also be reciprocal encounter information in different circumstances. "reciprocal encounter information" is encounter information that matches source information and relates to the same encounter as the source encounter information. Reciprocal encounter information can also be source encounter information in different circumstances. "associated party" is an entity that was a party to an encounter specified by some encounter 35 information. In most cases, an associated party will be a person who was actually at the encounter specified by the encounter information. However, the associated party possibly could be another RECEIVED at IPONZ on 05 November 2009 561111 related person where this may assist contact between parties. Encounter information comprises information identifying an associated party. The encounter information may be entered into the system by the associated party, or any other third party who may or may not have been involved in the encounter.

A "match" is where some encounter information is found that correlates to some source encounter information. The information correlates if the time and location specified by both sets of encounter information are the same to within a specified tolerance. Matched encounter information might be reciprocal encounter information, although this is not necessarily the case.

The term "comprising" as used in this specification means "consisting at least in part of'. When interpreting each statement in this specification that includes the term "comprising", features other than that or those prefaced by the term may also be present. Related terms such as "comprise" and "comprises" are to be interpreted in the same manner.

As used herein the term "and/or" means "and" or "or", or both.

Overview of preferred embodiments The present invention relates to a system, method and/or software applications (including websites) for facilitating contact between two parties. Contact is established or re-established based on time and location of an encounter between the parties. It is preferably used in a situation where the parties may previously have been friends or acquaintances and have lost contact. At some subsequent time, they might have a chance meeting or encounter, but the encounter was such that they were unable to swap contact details. However, the encounter triggered the desire to reestablish contact. The invention may be used for a variety of other scenarios also, where it is desired to establish or re-establish contact between two parties, For example, the invention could also be used in an instance where people who do not know each other have an encounter, and may wish to contact each other for a new relationship. This would be particularly useful as a means for dating.

It might also cover the situation where the parties to the encounter are not actually the people that want to establish contact, but are in some way associated with people who might want to make contact.

Figure 1 shows in general form an overview of one embodiment of a system that could be used to implement the invention. The system implements the method and software applications of the invention. It will be appreciated that the invention might also be considered to comprise just some 35 of the system shown. The invention might comprise portions of the system and/or the relevant method and/or software implemented by those portions.

RECEIVED at IPONZ on 05 November 2009 561111 The systeml comprises a server 10 stationed at an appropriate location. The server comprises a web server 10a, application server 10b, database server 10c, email server and interface lOd, and sms server and interface lOe. Together these form the server that provide the system functionality. The server 10 can also comprise other suitable additional interfaces for communication with parties 5 accessing the system remotely. The server is coupled to a wide area network, such as the internet via a local ISP 11. Users (usually subscribers or registered users of the system) of the system can access the functionality (services) provided by the server through the internet or other wide area network.

Typically, users will access the server 10 through a remote PC 13 using an internet browser, which 10 enables them to access the services provided by the server. Alternatively, users could access the server via a mobile device, such as a mobile telephone 14. This could be done through text messaging via an sms gateway 12 that interacts with the server 10 through the internet 11. Alternatively, the interaction could take place with the server via a suitable communication protocol over a GSM, GPRS or any other mobile communications network. Other remote devices and 15 computers could be also used to access and interact with the services provided by the server, and those mentioned here should not be considered limiting.

The system allows two parties to establish or re-establish contact based on time and location information. Preferably, the time and location information will relate to respective the time and 20 location of the parties when they have an encounter, or people associated with them have an encounter. An encounter, for example, could be a chance meeting on the street. The invention is not restricted to establishing contact based on time and location information of physical encounters. Time and location of any type of encounter event could be utilised, The system 1 either allows or facilitates communication between the two parties via a communications service. This could be one or more of: chat rooms, instant messaging, email, text messaging or the like. The server alternatively, or additionally, also aHows for transfer of contact details between the two parties so they can make their contact via alternative communication means independently from the system. Security/identification confirmation methods are preferably 30 undertaken before the server transfers contact details or allows contact. However, this is not essential.

As an example, the system 1 may implement a method via software in website that operates in the following manner. Two parties, who used to know each other, may have a chance encounter at a 35 location, like an airport. They may have only seen each other at a distance, and therefore could not exchange contact details. If both parties were interested in re-establishing contact, they could utilise RECEIVED at IPONZ on 05 November 2009 561111 the system. They could both independendy enter the time and location of the encounter into the system through a PC 13, mobile device 14 or the like. This information is received, processed and stored by the server 10.

The server 10 can be triggered to perform a match on time and location details. For example, if first party to the encounter enters the time and location details (termed "encounter information") of the encounter, they can then request the server to search for any other instances of encounter information it has received from another party that specifies the same time and location (to within a suitable tolerance). If the server 10 locates such other encounter information, and the subsequent 10 security/identification confirmations are successful, the server will alert one or both the parties who entered the corresponding encounter information. They can then be put in contact via the server communications services, or the server can transfer contact information between the two.

In practice, the server 10 will receive numerous separate entries (or instances) of encounter 15 information over time, each encounter information instance being received from one of a number of users. Each instance will relate to an encounter. For any particular instance of encounter information, the server might have received (or in the future might receive) one or more reciprocal instances of encounter information from one or more other users. A reciprocal instance of encounter information is information that relates to the same encounter. Such reciprocal instances 20 of encounter information will specify the same time and location (to within the required tolerance) of the encounter in question. However, for any particular instance of encounter information, the server might not have any reciprocal instances of encounter information. This could be because the other party to the encounter does not use the system, or did not enter the information for some reason.

When triggered to do a match on a "source" instance of encounter information, the server will attempt to determine one or more matching reciprocal instances of encounter information from a large number of instances of encounter information. The server also might match instances of encounter information that specify the same time and location of the base encounter information, 30 yet those instances might not be reciprocal, i.e. they might not relate to the same encounter as the base encounter information. The encounter information might relate to a different encounter with a coincidentally similar time and location. In this case, further filtering can be done by the server and/or users to determine the reciprocal instances of encounter information (and therefore whether communication can be established) RECEIVED at IPONZ on 05 November 2009 561111 Tt will also be appreciated that a reciprocal instance of encounter information might be entered at a later time. Therefore an encounter information match may only occur at a later date when the second party enters information.

The system also allows "broadcasting" of encounter information. This is where only one party enters encounter information and broadcasts it to all users to see if someone wants to respond.

Some examples of use of the system are as follows: 1. Two people who have lost contact see each other at an airport, but cannot swap details.

They both enter their encounter information on the system at a later time. The system matches it and they are put in contact. 2. A similar scenario might occur as above, except the two people do not enter the information 15 personally. They might have friends who use the system, and the friends enter the encounter information and make the match on their behalf. 3. Two people meet who do not want to make contact, but have common acquaintances who they know want to get in touch. The parties to the encounter can use the system to get in contact after which they assist their acquaintances to get in contact. Or, the system could be used to get the acquaintances in contact directly.

. Someone sees and old friend over the road, but the old friend does not see them. They enter cncountcr information, and broadcast this on the system in case the old friend on TV sees the broadcast, and gets in contact. 6. Someone sees and old friend on TV. They can use the broadcast function as per 5 above. Alternatively, both the viewer and the person on TV enter the TV information (e.g. time and programme name) as an "encounter" and make contact. This demonstrates that an encounter need not be physical.

The above is just a brief overview, and many alternatives and other forms of operation are possible which will become evident to those skilled in the art from the preferred embodiments described below.

RECEIVED at IPONZ on 05 November 2009 561111 First embodiment of a system and its operation The system 1 and its operation will be described here with reference to Figure 2. Operation from the user's perspective will be described with reference to the two examples that follow later.

As described above, the server uses the web server to provide an access point to the functionality/services of the server 10 via the internet 11 and web browsers running on remote machines 13, 14. The sewer also has email server lOd and sms server lOe and other interfaces for providing access to the server functionalities through other remote interface devices such as mobile telephones, devices and the like. The application server 10b, which forms part of the server, 10 implements the services provided by the server though software. The application server operates in conjunction with the interface servers. The interface severs' operation will be known to those skilled in the art.

The application server 10b is adapted to receive encounter information from users of the system via 15 any of the interface means, step 20. It will receive this encounter information via the appropriate interfaces as and when users of the system desire to use the system. Upon receiving an instance of encounter information, the application server 10b will store the encounter information in a database, step 21.

The encounter information will comprise location of the corresponding encounter (which may be a geographical location, specified in any suitable text, visual, ID code or other form) and time information. The geographical location information specifies the geographical location of the encounter. The time comprises the time of the encounter or the date of the encounter or both the time and date of the encounter. The term "time" can therefore broadly be considered to cover time 25 and date where appropriate. It will be appreciated that the time and location information received from the user will be based on the user's perception of the encounter, and therefore may not be entirely accurate.

The received encounter information will also comprise information identifying an associated party, 30 being a party to the encounter. This may or may not be the same as the entity actually providing the information that is received by the server. For example, a third party might enter encounter information for an encounter experienced by another party. Typically, the encounter information will be related to the information experienced by one of the parties to the encounter. Information received from one or more other parties to the encounter may be similar but not exactly the same, 35 due to differing experiences or perceptions of the time, location and other information of the encounter.

RECEIVED at IPONZ on 05 November 2009 561111 The cncountcr information may optionally comprise other identifying information, such as the name of the person, details of the encounter, activities that occurred during the encounter, clothes or „ other distinguishing features of the parties, security questions and any other suitable information.

Any of the encounter information may be specified as an exact portion of data, or a range of data.

For example, the time and location might be entered as a range to allow for tolerance or inaccuracies. The time might be specified as 9:30-9:45 am, and/or the location might be Queen street/Vulcan lane. The location might be specified as a suburb or region or other area, to allow for an easier match. Or, it could be specific to a house, building business or other location. For business, bars and the like, an ID location code could be used. For example, and particular 10 restaurant might have an office ID location code for use with the system. This means a user does not need to know the actual address.

Instances of encounter information will be received bv the server in an ad hoc manner, as and when j 7 parties to encounters decide to enter the corresponding encounter information. When an instance 15 of encounter information is received, the reciprocal instance of encounter information may not yet have been received — and may ultimately not be received at all. At this point, the server is simply receiving encounter information and storing it for later processing.

The server can be triggered by a user to find a match to source instance of encounter information, 20 step 22. This may be an encounter that the user has personally been involved in as a party, or some other encounter that they have an association with. Triggering a search to find reciprocal encounter information could happen in any suitable manner. It may happen at the time of the user entering the encounter information, or it may happen at a later time, and may form part of the encounter information entry process or as a separate process. It should be noted that at the time of entering 25 encounter information, the reciprocal encounter information from one or more other users may not yet have been entered, so any attempt to find that reciprocal encounter information may not be successful at that point in time. Therefore, it may be necessary to instigate a search at a later stage when such information may have been entered.

Upon receiving an instruction from a user to carry out a match, the server 10 does the following to find matching information, step 23. First, it identifies the relevant encounter information for the party triggers the match process — this will be the information they entered. This becomes the source encounter information. It then searches through its database for any previously received encounter information from other users that may match the source encounter information. An 35 instance of encounter information in the database matches the source encounter information if there is some correlation between the two. The correlation might occur, for example, when the times and RECEIVED at IPONZ on 05 November 2009 561111 location of specified by both instances of encounter information (source and potential match) match to within a degree of tolerance (or cxactly) depending on settings. A match might only require correlation between the key bits of information, such as location and time, or alternatively, all the encounter information.

When an instance of encounter information in the database is determined to match or correlate with the source encounter information, the instance is flagged up as a possible match. That is, the instance found in the database may be reciprocal encounter information to the source encounter information. This does not necessarily mean that the party associated with that flagged encounter 10 information is the person or associated party to the encounter in question. It could be that the matched encounter information specifies an unrelated encounter, but by coincidence had a similar time and location. The server will find all encounter information matches, irrespective of whether they are an instance of reciprocal encounter information or not. These are conveyed to the user initiating the match process, step 25. A filter process either by the application server and/or actions 15 by the user can reduce the matched encounter information to those that are or are more likely to be related to the encounter in question, step 24. Alternatively, all the potential matches might be provided and the user can determine through other means which are relevant.

The server 10 can then receive input from the user indicating which of the instances of matched 20 encounter information might actually relate to the encounter in question. At that point the server can facilitate contact between the associated parties to the selected encounter information, step 26. This can either be directly through the server, for example through chat rooms or the like, or alternatively and/or by facilitating transfer of contact information.

The application server 1 Od runs software (see Figure 3) that provides the services and functionality of the system 1. In particular it provides for the interaction and transfer of data between a remote user and the server, and the backing processing for matching encounter information. Referring to Figure 3, the software comprises a user interface layer. This comprises a service to download email messages 30, a web service 31 for integration with the internet, a website user interface 32 that 30 provides for interaction with a user over a pc and browser. It also comprises a geo-coding service/http/xml functionality 33. The software also comprises a business logic layer. This comprises the following objects/modules: static objects 34, error handling 36, session handlers 35 , global helper functions 37, moments (encounter information) 38, members 39 and a geo-transform 27. In a data-access layer, the software comprises a data access module 28 and an SQL database 29. 35 This is where the encounter information is stored.

RECEIVED at IPONZ on 05 November 2009 561111 Figure 4 shows the method for receiving information at the server from a remote PC running a browser connected to the server via the internet. The browser will open up a session between a i, ,. server and download information from the server to provide a user interface for interaction with the server, step 40. Through this interface, the user can create logins, enter encounter information and 5 trigger the matching process.

The encounter information is entered on a form, step 41, and upon submission, step 42, this information is transferred over the internet and received by the server application. The information is retrieved and processed by the server application, step 43. The encounter information defines a 10 "moment" (which is the encounter). If the location is specified by a location ID code, then the moment is created directly, step 45 and the encounter information defining that moment is stored, step 51. If, alternatively, the location is specified by an address or other geographical information, then the details are reverse geo-coded, step 44. If this results in a single result then the location information is stored along with the other encounter information, steps 47, 51. If multiple results 15 are found, geographical location options are created and conveyed to the user over the internet, via email, step 49, via text message, step 48, or via any other suitable means, step 46. A selection can then be made by the user either through text or email, step 50, and the selected location along with the other encounter information is stored, step 51.

In another alternative, the information could be received by a text message or sms gateway process from a mobile telephone in Figure 5. The encounter information is sent via a text message and comprises a location (either as an address, a location ID or geographical indication) and the time, step 52. This encounter information is received via a gateway, step 53, and then the information or data is processed and sent via email to the server, step 54. The server retrieves the email and 25 processes this information, step 55.

If the location is specified by a location ID code, then the moment is created directly, step 45, and the encounter information defining that moment is stored, step 51. If, alternatively, the location is specified by an address or geographical indication, then the details arc reverse geo-coded, step 44. If 30 this results in a single result, step 47, then the location information is stored along with the other encounter information, step 51. If multiple results are found, geographical location options are created and conveyed to the user over the internet, via email, step 46, via text message, step 48. or via any other suitable means. A selection can then be made by the user, step 50, and the selected location along with the other encounter information is stored, step 51.

RECEIVED at IPONZ on 05 November 2009 561111 Figure 6 shows one possible matching process that occurs to identify encounter information instances that correlate to the encounter information forming the basis of the match. In a preferred embodiment, the matching process occurs immediately after encounter information is entered, although this is not essential. It could happen at another time upon trigger from the user, step 60. 5 On receiving notice of the source encounter information, the server application will search the database, step 61, for matches being encounter information instances that specify a location and time that is within 15 minutes and 500 metres radius of the basis encounter information, step 62.

Any suitable algorithm could be used to make this match. For example, the algorithm might involve 10 searching for all encounter information instances which have times that fall within the specified tolerance (in this case 15 minutes), and then of those, searching for encounter information instances in which the location is within a 500 metre radius. The reverse could be done, wherein the filter via the location radius is done first. Any other suitable tolerances and/or algorithms could be used, and matching could be done on other information in addition.

If an instance of encounter information correlates to the source information, it is flagged as a match, step 63. If not, it is discarded as not relevant, step 64. The system then processes/parses the next instance of encounter information in the database, if there is any further such information, step 65.

This process is done until all encounter information is parsed. The flagged matches are then 20 conveyed to the user, step 66. From here they can select appropriate matches and the contact facilitation process can occur.

First embodiment from a user perspective A first embodiment of the invention will be described from a user perspective as shown in Figures 25 7-19. The embodiment will be described with reference to an example encounter. This example will relate to an encounter between Jack and Matt; two people who used to work together but have lost contact. They briefly saw each other across the street in Downtown Auckland on the morning of 22 August 2008.

The user accesses the system via a user interface on a PC. First a user can register on the system (if they have not already done so) by providing their contact details 70 as shown in Figure 7. Details are shown for a new user "Jack". Once they have registered, a summary page 80 shows all the encounters entered by the user, Figure 8. In this case there are none. The user, Jack, can then enter encounter information specifying an encounter ("moment") at any appropriate time. They do this 35 by clicking on the "new moment" icon 81 in the encounter summary page. At this point they will be shown a screen 90 (see Figure 9) that comprises a map 91 or other representation of a relevant RECEIVED at IPONZ on 05 November 2009 561111 geographical area. The map can be manipulated (by panning and/or zooming) to display the relevant area of the encounter. The user Jack can then put a flag 92 at the location of the encounter along with the time in the appropriate fields 93. In this case, the location is "Queen Street" and the time (that is, date and time) is 22 August 2008 at 9:15 am.

Jack can then enter further information 95 relating to the encounter as shown in Figure 10. He can indicate what he was wearing (a baseball cap), what Matt was wearing (a t-shirt), and the type of relationship they are looking for (in this case business). Other useful information could also be entered, for example a situation quote. A security/identification/challenge question can also be 10 entered as shown along with the answer. Here, Jack has asked where they used to work, the answer being "Post Office". The security question will assist in ensuring the system only facilitates contact between people who genuinely were part of the encounter. The information will then be stored in the server database. The information entered in the screens on Figures 9, 10 constitutes encounter information. When the encounter information is stored, Jack will be recorded as the associated 15 party to the encounter information.

The server application will then automatically search for other instances of encounter information that match Jack's encounter information just entered. The default situation is that the server will search for any other encounter information that has a location within 500 metres of Jack's entered location and within 15 minutes of his entered time. A screen is then displayed 110, as shown in Figure 11, that indicates any instances of encounter information that match Jack's encounter information. As can be seen there are no matches. This is because Matt has not yet entered his reciprocal encounter information, and also because there are no other unrelated instances of encounter information matching Jack's that have been previously entered by parties. As can be seen in Figure 11, a slider 111 is shown that enables the matching tolerance for the time of encounter to be extended or contracted from the default of 15 minutes. This enables Jack to extend or contract the time tolerance to capture more or fewer potential matches. For example, if Jack was unsure of the specific time his encounter took place with Matt, he might decide to increase the slider so as to match times further out from his stated time of 9:15 am.

Once the encounter information is entered, a summary of the encounter as specified by the encounter information is displayed on the encounter summary screen 120 for the user, as shown in Figure 12.

At some later time, Matt then enters his encounter information for the same encounter. The method he carries out will be described with reference to Figures 13a-19 and the flow chart in RECEIVED at IPONZ on 05 November 2009 561111 Figure 13b. Matt is already registered as a user. Matt then creates an encounter moment, step 130. He does the following to do so. As shown in Figure 13a, he opens the encounter creation screen 90 and enters the time 93 (22 August 2008, 9:35am) of the encounter, and also indicates the location 97 on the map 91. The zoom and pan of the map may also be increased to capture more or fewer 5 locations by expanding the radius shown on the screen. It will noted in this case Matt enters the time of 9.35am, which is 20 minutes after jack's entered time. This might not be unusual as both parties might not be entirely aware or may not have an accurate recollection of the time of meeting.

As shown in Figure 14, Matt can then also enter encounter information 95 relating to what he was 10 wearing, what Jack was wearing and a situation quote which is "I passed you on the other side of the street". He enters a security question, which is in essence the same as Jack's although it does not necessarily have to be.

Upon entering the encounter information the system is automatically triggered to look for matches, 15 step 131. Initially a screen will be shown but no match will be found. This is because Matt's entered time and Jack's entered time differ by more than the default 15 minutes. But, matt can manipulate the matching criteria, step 134. If Matt adjusts the time slider as shown in Figure 15 to 21 minutes this will extend the time search back to 9.14am. Jack's entered time will therefore fall within this range of times. At this point, the server is receiving information on the relevant locations and 20 triangulating the results and displaying the on the map, steps 135, 136. As can be seen in Figure 15, Jack's reciprocal instance of encounter information 92 is now marked on the map. In general, all "rough" matches will be displayed, step 132. These can be filtered by the user and /or system, for example by manipulating the map / slider, step 134, as described above. Optionally, any "close" matches can be sent via an opt in email to other waiting users, step 133.

It should be noted that while the encounter matching is triggered upon entering the encounter information, this is not necessary. The encounter matching could be triggered at some other time by a separate process.

Once Jack's encounter is conveyed to Matt as shown in Figure 15, Matt can then click on the flag icon and obtain further details of Jack and the encounter, step 137. At this point, he might not be entirely sure that the indicated encounter information actually relates to Jack and his encounter with him. Matt can click an icon and obtain further information, as shown in Figure 16, 160. To do so, Matt might be required to answer the security question before he is allowed to obtain further 35 information, steps 138, 140. In some cases, a challenge question might not be used, step 139. Upon answering the security information he can enter an instant messaging or other chat scenario with RECEIVED at IPONZ on 05 November 2009 561111 Jack as shown in Figures 17a, 17b, step 141. Jack will be alerted to the contact and can reply accordingly. He can be alerted .by email, text, instant message or any other means or combination of - ^ means, step 142. Alternatively, or in addition, he may also be provided with contact information.

As shown in Figure 18, Matt's entered encounter information is shown on his summary page 180.

When viewing the matches, other instances of encounter information corresponding to unrelated encounters might appear. These will be encounters with similar encounter information. These can be filtered out or captured by altering the time slider default time range and/or the zoom/pan of the 10 map to capture more or fewer geographical locations.

To demonstrate this, for example say that another user "Clarkie" had entered some encounter information relating to an entirely different encounter not associated with Jack or Matt. In this case he had a chance meeting with someone on Queen Street at 9.45am. This is within 45 minutes of 15 Jack's entered encounter time. By coincidence, the encounter information entered by Clarkie was similar in time and location to that of Jack's and Matt's. When jack does his search he might increase the slider to for example 50 minutes to capture a large time range to ensure that he does not miss a potentially relevant encounter information instance. However, in doing so, while he captures Matt's encounter information, he also captures Clarkie's encounter information instance which is 20 irrelevant to him.

To distinguish which information may or may not relate to the instance for his encounter, Jack he can review the encounter information details. Here, he will see quite clearly that Matt's encounter information relates to the relevant encounter. Clarkie's information will indicate that this is not 25 relevant to Jack. The number of encounter information matches that appear on the geographical map can be reduced by manipulating the slider to reduce the number of "hits" therefore making the review of the encounter information easier. Alternatively, or in addition, the number of encounter hits could be reduced by reducing the search area by manipulating the zoom/pan on the map.

The embodiment of the invention shown with respect to Figures 7-18 utilises a graphical user interface on a web browser. It will be appreciated that this could be provided at any suitable manner, for example on a PC or via a suitably adapted mobile telephone or other mobile device. Alternatively, the information could be provided in text or graphical form via a mobile phone using some other suitable type of protocol, such as text messaging, GPRS or the like.

RECEIVED at IPONZ on 05 November 2009 561111 The system might also be adapted to provide a broadcast function, as shown in Figure 19. This function is useful where, for example a person may have seen someone they wish to contact, but it is unlikely that that person will not have rccognised or known the first person and therefore is unlikely to enter encounter information. Therefore, the first person can broadcast to see if that person 5 might decide to make contact, or a person who knows them might pass on the message to make contact.

Flere a user creates an encounter information instance (moment), step 190, and then chooses the broadcast functionality, step 191. It can also specify a window or tolerance of time, a radius of 10 search and also a message, step 192, Upon entering the moment, matches are found of people who have entered encounter information instances that match that moment, step 193. The system then broadcasts to those people. This can be done by either sending an email message, step 195, to those who have opted in to the broadcast function, or a text message, step 196 or some other suitable means. If the user who receives the email, text or other message is the person in question 15 being sought then that user can respond to a link, step 198, or respond with a text message, step 199, to create a match, step 200, and then be put in contact. Alternatively, that person may forward the message, step 194 or step 197, to someone who they believe is the person being sought. That person might say we received the email or text can respond in the suitable manner.

It is not essential for the broadcast to be sent only to those who have entered encounter information that matches the source encounter information. Alternatively, the plead may be sent to all those who have opted in to this functionality, irrespective of whether they have entered encounter information that is relevant or not.

Second embodiment from a user perspective A second embodiment of the invention will now be described. The server uses a graphical interface 100 illustrated in Figure 1 to allow a user to enter information on a person or persons they have met. It is assumed that users using the system have created an account using known online account creation systems. Other features such as address verification may be used. Users may be charged 30 for the service offered by the present system.

The user interface 100 presented to a user on a web browser is an adaptation of known graphical mapping software such as Google earth, AA road mapping, or Wises Street mapping. When a user enters information using the interface 100 the server 1701 stores records according to x and y 35 coordinates with a time range as a third 'coordinate'. This combination of data enables the system RECEIVED at IPONZ on 05 November 2009 561111 to display graphical maps 102 with the addition of event data 101. This display can be refined according to a specific date or date range as seen in Figure 21 Once the server 1701 has authenticated the user against stored registration data the authenticated 5 user may enter a meeting or contact, the server 1701 presents the user with graphical maps 102 as illustrated in Figure 21 and Figure 20. The server 1701 then provides navigation tools so the user can select the location that a meeting took place. Once a user has selected a location on the map 102 the server 1701 records this location. In cases where the mapping software is not sufficiently granular such that the exact location cannot be pinpointed, the server 1701 creates a location range 10 as selected by the user or according to pre-defined system defaults. The server 1701 then prompts the user to input a date and time range and records the input.

The server 1701 adjusts the length of this range according to pre-defined defaults. Figure 22 illustrates a user interface screen showing the location 202. The server 1701 then prompts the user 15 for miscellaneous data 205 that further defines the uniqueness of the meeting and records the input. The server 1701 prompts the user for an optional secret question 204 and answer. The secret question and answer is ideally information both parties would know or have agreed. The server 1701 then displays a marker 101 on the graphic/map 102 of the selected location. This marker contains the time range and the miscellaneous data entered.

Optionally the server 1701 can prompt the user to select whether this marker will be visible to all users or only to those who subsequently enter corresponding time and location data and, optionally, corresponding miscellaneous information, such as a password or the answer to the secret question known to both parties. Once the record is complete the server 1701 rccords and stores the 25 selection. Optionally the number of days 201 the record is stored for is received from the user.

On entry of each new record the server 1701 compares the data to data that it has captured and stored previously and, where the location (latitude and longitude range) and time range correspond, displays the corresponding data in the form of a marker 101 containing the miscellaneous data.

Each user is then able to review this marker 101 and miscellaneous data and, should they wish to proceed with an exchange of contact details, click on the marker. Markers 101 are illustrated in Figure 20 and Figure 21. The server 1701 then records the match and sends notification to the corresponding user that it has captured matching data.

The server 1701 sends this notification via that users preferred contact means, this may be email, SMS or any other means. If the server 1701 matches more records than a predefined limit, then the RECEIVED at IPONZ on 05 November 2009 561111 server 1701 will notify the user and request that they enter further data to refine the search. If the server 1701 finds matching data where the user has specified a secret question then the server 1701 will prompt for a correct answer before proceeding further. Prompts 308 for the answer to the secret question by be sent via email as seen in Figure 27, by SMS as seen in Figure 33 or displayed 5 on the web interface as seen in Figure 23.

When the corresponding user then visits the web site the server 1701 will display both markers, as seen in Figure 24. . The corresponding user authorises 403 an exchange of contact details by clicking the corresponding markers. The server 1701 records this and sends each user the others 10 contact details via the users preferred means. The matching data 401, 402 can be displayed on the graphical user interface as seen in Figure 24, via an email as seen in Figure 29 or via SMS as seen in Figure 34. For a user who had previously authorised a contact and was awaiting authorisation from the other party the data 502,503 will be displayed as illustrated in Figure 25 on the web interface. Alternatively or additionally the data may be sent via email as illustrated in Figure 29, or SMS as 15 illustrated in Figure 35.

The server 1701 can display graphical maps according to a user specified, or system defaulted time range. The server 1701 will display markers containing user specified information corresponding to a specific location and time range where the user has specified that it may be displayed to all users. 20 The server 1701 records where users have specified that markers may only be viewed by other users who have entered data for corresponding locations and time ranges.

SMS Input A user many also use a mobile telephone to interface with the present invention. Registration in the 25 case of a user using a mobile telephone may be via the web site or via a registration agent. Users may use both the mobile and web interface of the present invention.

Subsequent to registration, mobile phone users send SMS messages containing authentication and meeting data, including location, time and miscellaneous data, to a predefined number which diverts the data to an SMS gateway. An example SMS message 1201 can be seen in Figure 32. The server 30 1701 receives this data via the SMS gateway or via an interface file and authenticates the sender by comparing the data to stored registration data. Authentication may be via the mobile number of the mobile device identification number. Upon authentication, the server 1701 parses the data.

From the parsed data the server 1701 extracts a time range. The time range may be adjusted by the 35 server 1701 according to pre-defined defaults and, where only one time is found within the data, the server 1701 will use that time to create a time range according to predefined defaults. The server RECEIVED at IPONZ on 05 November 2009 561111 1701 also extracts location and miscellaneous data to create a unique meeting record which is stored for a period of time according to predefined defaults.

When searching the server 1701 then compares this record to previously created records. Whenever the server 1701 matches records based on time range, location and miscellaneous data, the server 5 1701 creates a match record and assigns a unique match code. If the server 1701 finds more than a predefined number of matching records then the server 1701 will generate a text message 1601 illustrated in Figure 36 to inform the user to resend their meeting data with more miscellaneous data or a shorter time range.

If a match is found the server 1701 generates an SMS message 1401 as illustrated in Figure 34 for 10 each user that has input matching data. This message contains both sets of location and miscellaneous data and the unique match code.

In order for the user to confirm the meeting and to authorise for their contact details to be exchanged, they reply with a message containing the unique match code. The server 1701 receives 15 this confirmation message via a SMS gateway or interface file and upon receipt from both users, generates an SMS message as illustrated in Figure 35 with corresponding contact details 1501 which the server 1701 then sends to each user.

As previously discussed users input registration data including, name, address, preferred contact 20 details, username, password and payment means directly into the website form. The server 1701 receives and stores this registration data.

Subsequent to registration, users visit the website and input authentication data. The server 1701 receives this data and authenticates the sender by comparing the data to stored registration data.

Searching to Identify Matches Where location data has been entered via a graphical interface, the server 1701 stores it and the data is searched according to latitude and longitude extracted from the graphical software. The system searches within a range as different users may not select the exact same latitude and longitude 30 position.

Where location data has been entered via free form text, the system defines each word as a meta-tag and the record is stored and searched by these meta-tags.

In order to cross-scarch graphical records with those entered via SMS, users entering data via the web interface are provided with an option to enter free form key word data to describe the location RECEIVED at IPONZ on 05 November 2009 561111 203 specifically to match SMS entries. This will allow the server to match the meta-tags. In an . .. .alternative embodiment the server may provide suggested key words based oil the location selected by the user.

The flow of entry and matching is illustrated in Figure 38 in steps 1801 to 1806.

This invention may also be said broadly to consist in the parts, elements and features referred to or indicated in the specification of the application, individually or collectively, and any or all combinations of any two or more of said parts, elements or features, and where specific integers are mentioned herein which have known equivalents in the art to which this invention relates, such 10 loiown equivalents are deemed to be incorporated herein as if individually set forth.

RECEIVED at IPONZ on 05 November 2009 561111

Claims (43)

1. A method of facilitating contact between at least two parties based on an encounter between the two parties comprising: retrospectively receiving at an input interface first information specifying the encounter, the 5 first information identifying at least one party to the encounter, at least the time and location of the encounter and a tolerance, identifying stored second information retrospectively received at an input interface, the second information specifying an encounterand identifying at least one party to the encounter and at least the time and location of the encounter, 10 facilitating contact between the two parties if the second information correlates to the first information within the tolerance.

2. A method according to claim 1 further comprising, prior to identifying stored second information, retrospectively receiving second information specifying an encounter. 15

3. A method according to claim 1 or 2 wherein the first and second information is associated with and/or received from respective parties to the encounter.

4. A method according to any preceding claim wherein the method comprises transferring 20 contact information to facilitate contact between the two parties.

5. A method according to any preceding claim wherein the input interface(s) is/are one or more of: a website interface, 25 a mobile device interface.

6. A method according to any preceding claim wherein the input interface comprises a graphical interface depicting geographical locations. 30

7. A method according to any preceding claim wherein the second information correlates to the first information within the tolerance if one or more of the time, location and/or party specified by both the first and second information matches to within the tolerance.

8. A method according to any preceding claim wherein the first information and the second 35 information may or may not specify the same encounter. - 26 - RECEIVED at IPONZ on 05 November 2009 561111

9. A method according to any preceding claim comprising identifying further correlation .between the first and/or second information to determine if they specify the same encounter.

10. A method according to any preceding claim wherein the first and/or second information 5 identify a range of times and/or locations that encompass the encounter, wherein the first information correlates to the second information if one or more of the locations and/or times specified by the ranges match to within the tolerance.

11. A method according to any preceding claim wherein the first and or second information 10 comprises a code for specifying the location.

12. A method according to any preceding claim wherein a range of times and/or locations are specified using a slider on a graphical interface. 15

13. A method according to any preceding claim wherein the first and or second information are received via text messaging or email.

14. A method of facilitating contact between at least two parties based on an encounter between the two parties comprising retrospectively receiving information on a plurality of 20 encounters at one or more input interfaces, each information specifying the time and location of an encounter and a tolerance, receiving a request for a match to an encounter, searching to identify information specifying one or more encounters that correlate to that encounter to within the tolerance, and conveying the identified information. 25 15. A system for facilitating contact between at least two parties based on an encounter between the two parties comprising: a computer adapted to process and store data, and to connect to and communicate over a network to one or more remote interfaces, a storage device in or remote to the computer, 30 wherein the computer is programmed to: retrospectively receive first information specifying the encounter over a network, the first information identifying at least one party to the encounter, at least the time and location of the encounter and a tolerance, identifying from the storage device retrospectively received second information specifying 35 an encounter, the second information identifying at least one party to the encounter and at least the time and location of the encounter, -27-

RECEIVED at IPONZ on 05 November 2009 561111 facilitating contact between the two patties if the second information correlates to the first information within the tolerance.

16. A system according to claim 15 wherein the computer is programmed to, prior to 5 identifying stored second information, retrospectively receive second information specifying the encounter.

17. A system according to claim 15 or 16 wherein the first and second information is associated with and/or received from respective parties to the encounter. 10

18. A system according to any one of claims 15 to 17 wherein the computer is programmed to transferring contact information to facilitate contact between the two parties via the network.

19. A system according to any one of claims 15 to 18 wherein the first and/or second 15 information is received via a one or more remote interfaces being one or more of: a website interface, a mobile device interface.

20. A system according to any one of claims 15 to 19 wherein the first and/or second 20 information identifying the location of the encounter is received via a graphical interface on the remote interface depicting geographical locations.

21. A system according to any one of claims 15 to 20 wherein the second information correlates to the first information within the tolerance if one or more of the time, location and/or party 25 specified by both the first and second information matches to within the tolerance.

22. A system according to any one of claims 15 to 21 wherein the first information and the second information may or may not specify' the same encounter. 30

23. A system according to any one of claims 15 to 22 wherein the computer is programmed to identify further correlation between the first and/or second information to determine if they specify the same encounter.

24. A system according to any one of claims 15 to 23 wherein the first and/or second 35 information identify a range of times and/or locations that encompass the encounter, wherein the -28- RECEIVED at IPONZ on 05 November 2009 561111 first information correlates to the second information if one or more of the locations and/or times specified by the ranges match to within the tolerance. ,,

25. A system according to any one of claims 15 to 24 wherein the first and or second 5 information comprises a code for specifying the location.

26. A system according to any one of claims 15 to 25 wherein the remote interface(s) provide a slider on a graphical interface to receive input specifying a range of times and/or locations. 10

27. A system according to any one of claims 15 to 26 wherein the first and or second information are received via text messaging or email.

28. A method of obtaining contact information on a third party you have previously met in person comprising the steps of: 15 providing graphical interface in the form of a map that allows a user to enter details of a meeting that took place; storing information on the meeting including the location on the map and the time of the meeting; searching on a storage dcvice for a similar meeting and presenting matches to users. 20

29. A method according to claim 28 wherein the meeting details comprise a security question known to the users who entered the meeting details.

30. A method according to claim 28 or 29 comprising providing details of the other matched 25 party.

31. A method according to any one of claims 28 to 30 comprising obtaining permission from the parties to swap details. 30

32. A method according to any one of claims 28 to 31 wherein the meeting details are received via a SMS, web interface and/or email.

33. A contact information system comprising: an interface, including a map allowing details of a meeting to be entered; 35 storage for storing said entered information on the meeting including the location on the map and the time of the meeting; -29- RECEIVED at IPONZ on 11 January 2010 561111 means for searching for a similar meeting; and an interface to presents matches to users.

34. A system according to claim 33 wherein the meeting details include a security question 5 known to the users who entered the meeting details.

35. A system according to claim 33 or 34 wherein the system provides details of the other matched party. 10

36. A system according to one of claims 33 to 35 further comprising an interface to obtain permission of the parties to swap details.

37. A system according to one of claims 33 to 36 further comprising an SMS gateway and the system may receive meeting details via SMS. 15

38. A system according to one of claims 33 to 37 further comprising at least one communication interface selected from a web interface, an email server interface and an SMS gateway interface and said system communicates with system usets via at least one of said communication interfaces. 20

39. A method of facilitating contact between at least two parties based on an encounter between the two parties comprising: retrospectively receiving first information at an input interface specifying the encounter, the first information identifying at least the time and location of the encounter and a tolerance, identifying stored second information retrospectively received at an input interface the 25 second information specifying an encounter and identifying at least the time and location of the encounter, facilitating contact between two parties associated with the information if the second information correlates to the first information within the tolerance. 30

40. A method according to claim 10 wherein the range of times and/or locations that encompass the encounter identified by the first and/or second information define the tolerance.

41. A method according to claim 1 or 40 wherein the tolerance is specified using a slider on a graphical interface. 35 -30- RECEIVED at IPONZ on 11 January 2010 561111

42. A system according to claim 24 wherein the range of times and/or locations that encompass the encounter identified by the first and/or second information define the tolerance.

43. A system according to claim 15 or 42 wherein the tolerance is specified using a slider on a 5 graphical interface on the remote interface(s). -31 -