WO2018161105A1

WO2018161105A1 - Shared contextual data transfer between preconfigured location devices

Info

Publication number: WO2018161105A1
Application number: PCT/AU2018/000032
Authority: WO
Inventors: Paul David Lomas; Janette Diane FLYNN
Original assignee: Paul David Lomas; Flynn Janette Diane
Priority date: 2017-03-10
Filing date: 2018-03-09
Publication date: 2018-09-13

Abstract

A data sharing system 10 comprising, five computerised location devices (11, 12, 13, 14 and 15) which all share contextual data in order to bring them within the group of five. 16 represents a geographic boundary but also an event boundary in place and time and optionally named. Users may view an attendance list while at an event. Data servers record in the background historical attendance data and this is displayed on a user's device as a list of other users and a number corresponding to mutual events attended. Users may use this number to visually filter and prioritise the list, access profile and event information for other users from the list and send and receive contact invitations.

Description

SHARED CONTEXTUAL DATA TRANSFER BETWEEN PRECONFIGURED LOCATION

DEVICES

TECHNICAL FIELD

[0001] THIS INVENTION relates to shared contextual data transfer between location devices in a social networking environment and in particular but not limited to a system for data sharing sharing based on convergent location based data due to physical presence of a location device within a predetermined vicinity of a second location device.

BACKGROUND

[0002] Social networking has become endemic with FACEBOOK™ and Linkedln™ being examples of Internet based social networking platforms in the digital space. Notwithstanding the digital space, traditional face-to-face networking remains a method of networking that is engaged in by persons, particularly in business with the usual exchange of business cards still being used. It appears that there may in fact be a resurgence in face-to-face networking since the digital space can be somewhat overwhelming and impersonal. Nevertheless, there is a need to enable networkers to integrate their digital experience and their non-digital networking opportunities. Since face-to-face networking opportunities are often limited to the number of people that an attendee at an event can meet and exchange business cards with there are missed opportunities. Moreover, business cards, while exchanged are often discarded unless someone makes a special effort to record the contact details and then even after this any systematic follow up has to be made in a deliberate manual manner. This represents lost data and lost opportunity. It would be desirable to provide a system and apparatus that enables capture of this lost data.

OUTLINE

[0003] It is an object of the present invention to ascertain location devices in a shared contextual environment based on convergent data elements being a trigger of a changed physical effect and then enable data transfer of data relevant to those devices. In one embodiment the location devices are self locating computer devices, typically mobile phones and the convergent data comprises historical location data.

[0004] In one aspect therefore there is provided in a data sharing system comprising at least a first and a second location device, each location device having at least shared location data within a predetermined range and at least one other shared contextual data element, the location data and the other contextual data element identifying the location devices as target devices in a defined group for automated data transfer or prospective data transfer and subsequently transfer of data between the devices or databases associated with the devices following a data transfer signal initialised by at least one of the first or second devices.

[0005] The location data could include direct data as in GPS or could be inferred as in an expectation of multiple registered devices being present at a particular time and place.

[0006] Typically, devices that are within the vicinity will not be recognised unless they share the same context. The context may include physical location within a defined range as defined by GPS or cellular phone network triangulation or dead reckoning based on the last known location and proximity of other location devices which share the relevant contextual data. In one preferred embodiment the second element of contextual data is a common event scheduled for that location.

[0007] Typically the contextual data is convergent contextual data so the location devices converge physically to cross an imaginary boundary and the convergence of the contextual data triggers actual data sharing or a data sharing option when these coincide. The location may be subject to a user verification.

[0008] Actual independently generated data could be used or if one data element was unavailable then expectation data could be inferred. This would indirectly verify by expectation the satisfaction of the prospective data event. Thus, expectation could trigger a search or polling sequence of expected devices at a particular location and time in the event direct location data is temporarily unavailable. Thus, if multiple devices come within range of each other at a particular time then they must be at the event location. [0009] Alternatively, in the situation where events are public or are registered with a social network such as Facebook then the GPS and public event coincidence of the multiple users at that event location and running the App will give rise to the shared context for attendees. This can then generate a list of attendees which can be sorted or otherwise matched via a remote server. The list can then be displayed to all contextually positive users. The server may maintain an historical record for later display and use by the users.

[0010] The location devices may be mobile phones which co-ordinate with the mobile phone network and GPS and the remote server via the internet. A third party event manager which would generally comprise published events which may be co-ordinated with GPS either directly or indirectly. In this embodiment there are generally two co-ordinating factors namely the presence of multiple users with their the location devices within the range of the published event and within the range of each other and the presence of the associated data for those those location devices in the database at the data server.

[0011] Each location device has a suitable user interface that enables users to request and make contact with each other, share their profile data that is stored in the server and retrieve and review historical data in order to see how many events they have in common as

co-attendees. The user interface is typically a display screen.

[0012] The process of establishing a user profile, attending an event and associating with another user involves installing the app on a device, the user then registers his or her identity, then the user details are captured, completing the user set up and establishing an account this data is, at this time also recorded, in the data server.

[0013] Upon attending an event or GPS location the App is waiting for check-in at that event or GPS location. When a user checks in this automatically generates a list of attendees which is displayed to all users who have also checked in, some the users may already be a contact from a previous event, others will be new, users can send contact requests, perhaps after viewing profile details of others retrieved from the data server. Each user will send and receive requests which can be accepted or rejected. [0014] As will be appreciated over time the server will accumulate historical data where trends will appear so that attendees will be able to review historical attendances and users may be matched. The history can be retrieved and displayed. The server may have a database that separately records this data so that in one preferred application of the present invention there is provided a method comprising: accessing, via a self locating computing device comprising at least one processor, profiles for a plurality of users who are attendees at an event:, each user having a corresponding self locating computing device comprising at least one processor; the profiles including user specified information and a device identifier enabling each computing device to be associated with a user; each computing device having a display screen; automatically determining, via the computing devices, the location of the computing devices; enabling, via each users computing device verification of the location as corresponding to the event; a server computing device having at least one processor and an associated database of historical location data of verified locations of events attended by the users; automatically determining via the computer devices and the database information regarding shared attendance history of the users and generating a shared attendance number for each pair of attendees at the event; communicating, via the users' computing devices the shared attendance numbers; each self locating computing device being configured to display on the screen a summary listing of the other users at the event and additionally being configured to display on the screen adjacent each other user the shared attendance number for the listed user relative to the user of the computer device upon which the numbers are being displayed; and the method additionally comprising enabling said accessing of said user profiles from the list.

[0015] Preferably, the method further comprises a server computing device having at least one processor and an associated profile database and the step of accessing of said user profiles from the summary listing comprises: selecting a profile via the user's computing device;

subsequently retrieving profile data from the server; and

displaying the profile data on the user's display screen.

[0016] Preferably, the method further comprises: selecting via the user's computing device an attendee from said summary listing; and sending an invite to share profile data and contact details.

[0017] Preferably, the method further comprises a server computing device having at least one processor and an associated profile database and the step of accessing of said user profiles from the summary listing comprises: selecting a profile via the user's computing device;

subsequently retrieving profile data from the server;

displaying the profile data on the user's display screen; and

sending an invite to share profile data and contact details.

[0018] Preferably, the method further comprises a separate user accessible profile database and a separate user inaccessible database of historical location data and users may establish multiple profiles and the method further comprises selecting one of said profiles to be shared at the event.

[0019] Preferably, the method included the further steps wherein, there is provided via a remote computer having at least one processor a dedicated event organiser to provide location data or a database having calendar data for retrieval to co-ordinate users events or, the method includes drawing event data from a third party event manager and enabling, via each users computing device verification of the location as corresponding to the event,

[0020] Preferably, the method included the further steps wherein there is provided via a remote computer having at least one processor published events which may be co-ordinated with GPS either directly or indirectly and enabling, via each users computing device verification of the location as corresponding to the event.

[0021] Preferably, the method included the further steps wherein a user's computing device comprises a mobile phone having a mobile phone number, and via each users computing device the user registers his or her identity employing the mobile phone number.

[0022] Preferably, the method included the further steps wherein a user who is registered in the database at the server and who has checked in is duly filtered and simultaneously receives a full list of other members who are also in attendance at the same event.

[0023] Preferably, the method included the further steps wherein a user, via the user's computing device retrieves a filtered list of historical event attendance records to display on the screen a summary listing of the other users and additionally being configured to display on the screen adjacent each other user the shared attendance number for the listed user relative to the user of the computer device upon which the numbers are being displayed; and the method additionally comprising enabling accessing of historical event details from the filtered list.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order that the present improvements may be more readily understood and put into practical effect reference will now be made to the accompanying drawings which illustrate preferred embodiments of the invention and wherein:-

Figure 1 is a schematic diagram illustrating multiple location devices interchanging data either directly or via a proxy device, Internet or cloud based interchange;

Figure 2 is a diagram illustrating a user arrangement for setting up a location device for use in the present invention;

Figure 3 is a is a diagram illustrating a typical arrangement of shared context databases accessible by contextually related location devices and their associated databases;

Figure 4 is a process diagram showing a device setup;

Figure 5 is a process diagram showing a device operation following setup;

Figure 6 is a diagram illustrating typical examples of shared contextual data for location devices;

Figure 7 is a flow and block diagram illustrating a second embodiment of the present invention;

Figure 8 is a flowchart showing the process applicable to the embodiment of Figure 7;

Figure 9 is a flowchart illustrating application of the present invention to recordation and storage of historical data in order to enable correlation of the correlation of users that have attended the same events over time;

Figure 10 is a block diagram and chart illustrating retrieval of historical data for users attending an event;

Figure 11 is a typical hardware setup suitable for implementing the process of Figures 7 through 10; and

Figures 12 to 27 are screenshots showing the user interface by which the present invention is typically used to input and retrieve data concerning events attended by reason of the shared location data generated by an attendee's location device entering the geographical region via a planned event..

METHOD OF PERFORMANCE

[0025] Referring to the drawings and initially to Figure 1 there is illustrated a data sharing system 10 comprising, in this example, five computerised location devices 11 , 12, 13, 14 and 15 which all share contextual data in order to bring them within the group of five. Other devices that are within the vicinity will not be recognised. In the present example the context is physical location within a defined range as defined by GPS or cellular phone network triangulation or dead reckoning based on the last known location and proximity of other location devices which share the relevant contextual data. The second element of contextual data is a common event scheduled for that location, for example a business networking event. The dotted outline at 16 not only represents a geographic boundary but also an event boundary in place and time and optionally named. [0026] Thus in one preferred embodiment the contextual data is convergent contextual data so the location devices converge physically to cross an imaginary boundary at the right time for the event and the convergence triggers actual data sharing or a data sharing option when these coincide. User input to sensed location data is used to confirm the location. Users may view an attendance list while at an event. Data servers record in the background historical attendance data and this is displayed on a user's device as a list of other users and a number

corresponding to mutual events attended. Users may use this number to visually filter and prioritise the list, access profile and event information for other users from the list and send and receive contact invitations.

[0027] Thus in one prefered embodiment of a mobile phone to be described below, upon activation of a common APP, on each location device, the APP tests for the convergent contextual data which then initiates a data transfer of predefined data or initiates a permission sequence so that users of the location devices may initiate the data transfer or share sequence. In another embodiment data is held in a server database and accessed from the database.

[0028] As depicted in Figure 1 there are multiple possible wireless communication options between the devices. The devices may be configured to automatically set up an ad-hoc mesh network once the convergent contextual data elements are present. Alternatively, LAN, WAN or Internet or other proxy relationships may be used for indirect communication, or the location device may simply trigger a share in remote servers to update user databases rather than data on the devices. Where the location is determined by GPS, in the event a GPS signal is lost, the cellular phone network, may be used to triangulate a position or an approximate position may be "dead reckoned" from a previous known position. This would be particularly useful if the location device was proximate to a source of the second contextual data element as in say outside a scheduled event. The location device could use local RF or a local wireless network to poll for other devices that it is intended to converge with. This would indirectly verify by expectation the satisfaction of the prospective data event. Thus, expectation could trigger a search or polling sequence of expected devices in the event direct location data is temporarily unavailable.

[0029] The boxes 11 , 12, 13, 14, and 15 in Figure 1 are used to depict dedicated location devices as may be used in the present invention for low power/low data sharing and might include wearable devices, handheld devices, implanted devices or any device that may respond in like manner.

[0030] While the devices may be dedicated, they may share other capabilities. For example, the ubiquitous mobile telephone may be used as the location device and the following description will be directed to this example.

[0031] Figure 2 illustrates a location device in the form of a GPS activated mobile phone 17 as part of an integrated system. This mobile phone is enabled with the present invention as are other similar phones (as in 11 , 12, 13, 14, and 15) of other users although only one is described here it is understood that the arrangement is replicated for the others. Each mobile phone user may have completely separate systems so that they only interact when converged or they may share some cloud based storage and web servers etc. " Thus "converged" as herein used means the minimum two data elements of physical location and a time for the presence of at least two devices associated with that location are present.

[0032] The following example deals with a business networking event where multiple mobile phones and their users are attending a common event at a specific physical location and the convergent events are arrival at the location and the identity of that location at that time as an "event" that they are all attending.

[0033] As shown in Figure 2 the device 17 is connected to the Internet as are desktop and laptop computers 18 and 19 with cloud based resources at 20 that enable a location device user to "register" for the event. This may involve a dedicated "synced" "Networker Server" 21 or other platform that is connected by subscription service to many event booking sites so that the Networker Server may administer the system of the present invention and coordinate the communication and transfer of data once the mobile location devices have "converged".

[0034] The invention may be implemented using dedicated ROM or EPROM loaded software on the location devices and capable electronics or in the case of an ANDROID or IOS phone a downloadable APP that may utilise installed hardware including GPS, accelero meters, RF, bluetooth or other sensors to implement the present invention.

[0035] In the case of this networking event example users may just want to exchange basic contact data so the "Networker Event and Relationship Database" may contain a minimum amount of information akin to the information held on a business card. On the other hand the present invention has the capacity to provide much more useful information and to filter that information and store it accordingly to a user's predetermined preference depending upon the converged data. E.g. business, sporting, family etc. Moreover, the users may set preferences to share portraits, etc. This would be very useful in a business sense to "put a face to a name". The present invention is much more than an exchange of business cards or the content of business cards. As shown in the example of Figure 2 the system may integrate, sync or otherwise retrieve shareable data from social media 23 including FACEBOOK™, Linkedln™ and the like if suitable permissions are granted or there may be a default profile set through the APP and stored at 24 or using a web based interface at 18 or 19.

[0036] The convergent event data including location and event details may be input directly to the system by direct GPS at the time the APP is initiated or via event registration or may be indirectly sourced as in for example from the user's cloud based calendar at 25 or via a

FACEBOOK™ "checkin" of location or via setting Google maps navigation destination at 26. Thus if GPS were lost the system would default to see if navigation was being used and an destination set, this would be predictive but would only result in convergence if a second data element was present. Since time is not of the essence in these circumstances a sharing action would not be initiated unless it could be reliably concluded that the device was physically at the event. So if 100 people were registered for the event, then the presence of 60 devices in the one place at the prescribed time may be enough to initiate a share sequence. In this case the contextual data would be device ID and number of devices. It would then be inferred that the registrants were at the event.

[0037] Figure 3 is a schematic showing the outline of the database 22 which may be edited directly or in the case of the "History" section may be automatically updated. Since a member at 23 may be a member of different networking organisations 24 the member data will appear linked to multiple organisations while the "Events" 25 will be unique in terms of time and location. The Event database may be synced with event booking websites and with the "Member" calendar so that an "Event" will automatically enter the "Event Organiser" as soon as a Member registers. The Event organiser will robotically source all relevant data for that Event as a minimum required record for the system to operate. In the present case that could be recorded as

Name: Unknown Event (not required)

Location: required

Date/time: required

[0038] The system would then at that location, date and time activate and once a user data had "converged" so that the location device has arrived, set up that sharing sequence by identity and communication with other "arrived" devices.

[0039] Figure 4 illustrates in detail the setup of an APP based version on a mobile phone. Once the APP is set up in accord with Figure 4, its operation is governed by the process of Figure 5.

[0040] Figure 6 is a diagram showing examples of the types of data sharing depending upon predetermined relationships between users.

[0041] Referring to Figure 7 there is illustrated a second embodiment of the present invention 100 which differs from the previous embodiment in terms of some of the data elements utilised. The location devices in this case remain mobile phones 11 and 12 which co-ordinate with the mobile phone network 110 and GPS 111 and the app data server 112 via the internet. This could be through the mobile network in the usual way or where there is wireless connection directly to the internet. Unlike the previous embodiment where there was a dedicated networker event organiser 25 in Figure 3, or calendar data could be retrieved at particular times to co-ordinate users at "private events", in this case in addition to these option or an alternative to these in the embodiment of Figure 7 is a third party event manager 113 is employed.

[0042] This would generally comprise published events which may be co-ordinated with GPS either directly or indirectly. So in the present embodiment there are generally two co-ordinating factors namely the presence of the location devices 11 and 12 within the range of the published event and within the range of each other and the presence of data for those location devices in the data server 112.

[0043] Now it may be the case that each of the location devices 11 and 12 with their associated user profile held in the server 112 have not been personally associated. In which case the users may, by reviewing attendees who are automatically generated on the user's interface as being commonly held in the data server and find each other and send or receive contact requests. Thus the users of the location devices 11 and 12 will be able to immediately see users that they are not currently associated with as well as users who have attended other events in the past who the user became associated with in the past.

[0044] The process of establishing a user, attending an event and associating with another user is illustrated in Figure 8. This process firstly involves installing the app on a device.

Implementation of the arrangement of Figure 7 is illustrated in Figure 8 where in the first case the app is installed on a smart device such as a mobile phone at 114, the user then registers his or her identity typically employing the mobile phone number at 115 then the user details are entered. These may be imported from a third party app such as Facebook 116 or manually entered at 117. This then completes the user account set up and this data is, at this time also recorded, in the data server 112.

[0045] The app then in its normal operation at 119 which involves waiting for check-in at an event location or user selected options which we will describe below in greater detail. It is noted that normal operation can occur anywhere at any time but if the location device is not in range of a registered event or other users at check in then a negative result will follow.

[0046] When a user checks in, an event location at 120 which could be via GPS check-in or via a published event then automatically the app generates a list of attendees retrieved from the data server and displays these at 121. Therefore, each attendee who is registered in the database at the data server and who has checked in is duly filtered and simultaneously receives a full list of other members who are also in attendance at the same event. [0047] Users may then send or receive contact requests and their association as having been at that same event is recorded in the server database. Naturally over time some users more often than others may attend similar events and the system may identify users who have attended a threshold number of events in their history and this may be flagged to a user or alternatively a user may simply tag a contact and then view any common history in the view history at 123.

[0048] Other features include management of contacts at 124 and any editing of the user profile at 125.

[0049] Figure 9 illustrates the profiling/filtering process which checks the relationship between an attendee at an event. Firstly identifying them as a registered user at 126, verifying joint check in at 127 and if so updating the history. Third party event check in via options 130 and 131 results in the same history update.

[0050] Once the history is updated at 128 and the user is made visible, then the historical event attendance records and relationship between two attendees may be revealed from this data. This is illustrated in Figure 10. Thus the user event history which is available in the database may be retrieved at 132 enabling a user to select a particular event at 133. This in turn retrieves a list of attendees at that event at 134 and the user may select a particular attendee at 135 and a history of previous events where there was co-attendance is revealed at 136. It may be that those attendees never attended any previous events in which case since they did not co-attend any events then it would come up blank. However there may be a situation where the user and the selected attendee have many events in common which may indicate to the user that it is worthwhile sending a contact request if they are not already a contact in which case this is checked at 137 and a contact request can be sent at 138. Alternatively if they were already a contact it may not have been recognised by either of them that they had so much in common in which case other contact options may be explored at 139. In relation to the previous events co-attended at 136 any of these events may be selected to view the time, date and location of that event. [0051] Figure 11 illustrates the structure of the server 112 which in general terms employs a profile database 132 which may contain personal information 133, social media information 134, and registered contacts 135. This database may be mirrored by a separate database which contains business information. The history database 136 contains a full record of all attendees 137, all events whether third party or GPS events at 138 and 139 and these databases are relational through the user ID contained in the profile database and against the attendee, the contacts and those contacts are naturally a subset of the attendees at 137 and those are in turn all associated through the respective events, thus it is possible to retrieve the historical data for any attendee who is also in the contact list for any user in the profile database. To the extent that a user in the profile database 132 has also entered business information in relation to that user, that information would also be retrievable through that user's details in addition to their personal information.

[0052] While the previous block diagrams and flow diagrams illustrate the back end operation of the present invention, Figures 12 through 27 illustrate the user interface once the app has been downloaded and initiated for the first time on a mobile phone.

[0053] Figure 12 shows the open screen shot which gives a potential user the option to swipe through multiple images, as shown in image 141 , that give them an overview of the App. The user can create an account at any time by clicking the create account button. If they are already a user they simply swipe the image 141 on the screen to the right to move to the next screen. This then enables them to check-in to an event or location.

[0054] Where the user has tapped "create an account" they move to the screen Figure 13 which enables them to enter mobile phone number at 142 and select the country location from the drop down list at 143. They can then tap "create account" at 144. The mobile phone number is the device identifier associated with the user. They then have to enter their verification code at 114 which they have received by ext or SMS which verities the phone number, they tap "enter code" at 145 which takes them to the screen of Figure 15 where they enter the verification code at 146.

[0055] The user taps at 147 to continue with the creation of the account. User then in Figure 16 has the option of entering data manually at 148 or importing profile data from Facebook at 149, The Facebook profile may not include business information or may include different information that the user does not want to include in this particular app, so let's say the user selects "create personal profile" at 148, they move to the screen at Figure 7 where as can be seen, personal information may be entered and the user then taps "create profile" at 150.

[0056] In this embodiment the user is then given the option of creating a business profile in the screen Figure 18 and by tapping on 151 or importing a Linkedln profile at 152 a business profile may be created or alternatively if the user simply wants to use it based on the personal profile this may be skipped at 153.

[0057] Figure 19 is the entry form for the business profile and the user simply taps "create profile" after entering the required data.

[0058] Thus a profile is created and this is stored in the profile database referenced at 132 in Figure 11 and likewise the business profile would also be recorded in the database along with any other profile information which may be desirable from time to time. The user may then leave the app and at the next entry there will be no need for the user to enter or create an account but will simply swipe right on the image on the screen illustrated in Figure 12 at 141 to check in to an event or location.

[0059] Check-in selection drives the app to the screen Figure 20 where, as an aid to check in, the user can see a map image in the vicinity of the user. The user can then use GPS check-in at 155, which allows the user to be visible to all other users with a similar GPS location.

Alternatively, tapping on the Facebook event check-in at 156, allows the user to see Facebook events in the vicinity of the user's location and check in to one of these. Once checked in, the user is visible to all other users that have the same share context, that is "I am at the same event". Thus the context is established at that particular time and place. This can provide a context for future historical analysis.

[0060] Based on the history previous events that users have attended are flagged, in this example at 157, 158 and 159 with the number of registered users who have attended events at that location historically. In order to see what event that was, user may simply tap on the icon 157, 158 or 159 to see exactly what event occurred that user had attended at that location in the user's history.

[0061] Other events that were not attended by the user are shown and highlighted. Also highlighted as hot spots of multiple events that need to be expanded to be seen are at 160 and 161. In the present case 160 and 161 are highlighting a circumstance where multiple events are current at that location or registered at that location in the database and the user may tap on these to expand the view which will reveal the actual events in more detail including those events which may be events which the user has attended in the past and these will show up in similar fashion with numbers as shown in icons 157, 158 and 159. The user can then tap on these in turn to reveal more detail.

[0062] By GPS check-in at 155 or the Facebook event check-in at 156 or tapping on events at 162 and then checking in at a named event will result in all contextual positive users being identified to each other in two selectable lists, one a list of those who are already contacts and a list or new users to whom contact requests may be sent. As a result of the check-in all the registered users of the app are then revealed on the screen of Figure 21 and can be scrolled through. These are listed alphabetically by surname. These are in two selectable groups, Those that are already connected to the user are shown by tapping on the heading "Stonked" at 163. This also shows number of associated users that the current user and that user shares in common at 164. Tapping on the second label at 165 users who are not currently associated are shown and the user may tap on these and send a connection request but first may click on a name to expand the contact card to full screen to see if it is a person that they may wish to add to their contacts.

[0063] Figure 22 is the screen which shows up when one taps the events calendar. Contact requests are shown as received in Figure 23, the number of mutual connections is shown next to each user's details in a black circle. The user can swipe right to accept the connection request or swipe left to pass. User can also click a name to expand their contact card to full screen. If accepted their contact card is added to the user's server database and mobile phone address book records. [0064] Figure 24 illustrates the event history that may be shared with a particular contact, when an event is clicked the user sees a list of other users at that event. Settings may be changed in the settings screen at Figure 25.

[0065] Figure 26 illustrates step by step process as described previously to view the common history and Figure 27 illustrates the check-in at an event, the process where the viewer is able to choose attendees not yet connected with, view attendees who they are connected with and manage those contact requests as previously described.

[0066] Whilst the above has been given by way of illustrative example many variations and modifications will be apparent to those skilled in the art without departing from the broad ambit and scope of the invention as set out in the appended claims.

Claims

1. A method comprising: accessing, via a self locating computing device comprising at least one processor, profiles for a plurality of users who are attendees at an event:, each user having a corresponding self locating computing device comprising at least one processor; the profiles including user specified information and a device identifier enabling each computing device to be associated with a user; each computing device having a display screen; automatically determining, via the computing devices, the location of the computing devices; enabling, via each users computing device verification of the location as corresponding to the event; a server computing device having at least one processor and an associated database of historical location data of verified locations of events attended by the users; automatically determining via the computer devices and the database information regarding shared attendance history of the users and generating a shared attendance number for each pair of attendees at the event; communicating, via the users' computing devices the shared attendance numbers; each self locating computing device being configured to display on the screen a summary listing of the other users at the event and additionally being configured to display on the screen adjacent each other user the shared attendance number for the listed user relative to the user of the computer device upon which the numbers are being displayed; and the method additionally comprising enabling said accessing of said user profiles from the list.

2. The method of claim 1 further comprising a server computing device having at least one processor and an associated profile database and the step of accessing of said user profiles from the summary listing comprises: selecting a profile via the user's computing device;

subsequently retrieving profile data from the server; and

displaying the profile data on the user's display screen.

3. The method of claim 1 further comprising: selecting via the user's computing device an attendee from said summary listing; and sending an invite to share profile data and contact details.

4. The method of claim 1 further comprising a server computing device having at least one processor and an associated profile database and the step of accessing of said user profiles from the summary listing comprises: selecting a profile via the user's computing device;

subsequently retrieving profile data from the server;

displaying the profile data on the user's display screen; and

sending an invite to share profile data and contact details.

5. The method of claim 1 further comprising a separate user accessible profile database and a separate user inaccessible database of historical location data and users may establish multiple profiles and the method further comprises selecting one of said profiles to be shared at the event.

6. The method according to any one of the preceding claims wherein, there is provided via a remote computer having at least one processor a dedicated event organiser to provide location data or a database having calendar data for retrieval to co-ordinate users events or, the method includes drawing event data from a third party event manager and enabling, via each users computing device verification of the location as corresponding to the event.

7. The method according to any one of the preceding claims wherein there is provided via a remote computer having at least one processor published events which may be co-ordinated with GPS either directly or indirectly and enabling, via each users computing device verification of the location as corresponding to the event.

8. The method according to any one of the preceding claims wherein a user's computing device comprises a mobile phone having a mobile phone number, and via each users computing device the user registers his or her identity employing the mobile phone number.

9. The method according to any one of the preceding claims wherein a user who is registered in the database at the server and who has checked in is duly filtered and simultaneously receives a full list of other members who are also in attendance at the same event.

10. The method according to any one of the preceding claims wherein a user, via the user's computing device retrieves a filtered list of historical event attendance records to display on the screen a summary listing of the other users and additionally being configured to display on the screen adjacent each other user the shared attendance number for the listed user relative to the user of the computer device upon which the numbers are being displayed; and the method additionally comprising enabling accessing of historical event details from the filtered list.