Method, apparatus and system for social networking

ES 2 670 331 T3

DESCRIPTION

Procedure, apparatus and system for establishing social networks

COUNTRYSIDE

The present invention relates generally to telecommunications and, more specifically, relates to a method, apparatus and system for establishing social networks.

BACKGROUND

The proliferation of mobile devices is changing the way people interact. Mobile devices are also increasing in power, sophistication and features and changing the way people interact. The establishment of social networks is in application of how such interaction is evolving.

One area of ​​evolution is matching algorithms, including ad hoc matching algorithms. The prior art indicates that the most available ad hoc matching algorithms are primarily designed for infrastructure-based distributed systems and do not necessarily address the low-power and volatile characteristics required for ad hoc networks. An example of such prior art (although it does not even address matching algorithms) is the document deA. K. Dey, GD Abowd & D. Salbe A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications Human-Computer Interaction, Vol. 16, No. 2, 3 & 4, pp. 97-166, 2001. (Dey) Dey provides a conceptual framework for building context-aware generic applications. Dey presents a context toolkit and discusses how such a toolkit can be customized for different scenarios from a smart tour guide to a conference assistant. Separating the sensory networks from the semantics of the applications, interfaces and information aggregators are created as middleware. Also the type of location sensors can be changed to various technologies without changing the logic of the applications. This provides programmers with the ability to build context-aware applications and customize them with relatively little modification. However, in Dey, the location is the prominent context and the ability of the system to deal with more complex contexts and its scalability is not currently demonstrated.

US patent publication US 2007 / 0008905A1 by Berger et al (Berger) discloses a method that groups a plurality of users in a mobile network according to a specific profile. Data relating to the user is assigned to each user. Data is exchanged between at least two users as soon as said users are located in a predefined communication range in order to locate users with profiles that have a given content. Berger does not meaningfully address how match prioritization is done. Berger also does not significantly address the process of making contact between the nodes. Although Berger suggests that the proposed grouping model is possible through both WiFi and Bluetooth, these protocols have different schemes in peer pairing (hands-on) and pairing usually occurs through the sharing of a key. If the pairing is aborted or disabled, there are security issues. Berger also does not meaningfully describe how users access the same search templates, suggesting that perhaps Berger intends that the solution in Berger is hard-coded on devices and lacks customization capabilities. Berger also does not discuss how data is exchanged and propagated between nodes. The propagation of messages in an ad hoc network must follow certain principles and protocols, but Berger does not refer to any standard of how such interaction can happen. Also noteworthy is that in Bluetooth communications, each master device can only connect to up to a limited number of devices at the same time. Berger does not discuss how planning is done when the number of nodes increases. Also, Berger does not analyze planning models when building and connecting mesh networks. This means that if the data offered is not within the discovery scope of the protocol, then no matching will occur.

US Patent US 6,542,749 to Tanaka et al (Tanaka) provides a method and system for connecting telecommunications units located in the vicinity. The method and system can be used in a location sensitive telecommunications system that can determine the location of a telecommunications unit (TU) that is used within the system. A user can connect to one or more other users when they have compatible attributes and when they are located within a predetermined distance from each other. The connection can be established between the UTs of two or more users, based on the attribute and distance information maintained by a server computer, following the request of the UT of an initiating user.

Tanaka can be used for passive information processing but Tanaka does not significantly disclose real-time information processing. Tanaka, unlike Berger, is also based on a centralized framework, and relies on a pre-existing communications infrastructure such as a core mobile network such as

ES 2 670 331 T3 a Global System for Mobile Communications (GSM) network, or a Code Division Multiple Access (CDMA) network, or the Universal Mobile Telecommunications Service (UMTs). Other types of mobile network indication infrastructures will occur to those skilled in the art. Tanaka can potentially suffer from high network latency as any point of failure in the core mobile network can impact communication performance. Another aspect of Tanaka is that the mobile locations are determined by the telecommunications base stations, which can have an impact on the granularity of the locations. Column 9, lines 45 to 65 of Tanaka provides the general description of the matching algorithm that is used in any networking system but such algorithm can be expanded further. Tanaka also focuses on a scoring model that is based on degrees of separations but the inventors believe that there is a need for different scoring models.

US Patent US 5,086,394 to Shapira (Shapira) provides an introduction system for participating users, including for each user a personal device that is subject to remote paging activation. Each user also has a memory device that contains personal data that defines the user by personal characteristics such as traits and interests, a local control unit receives personal data from a plurality of user memory devices and using computer means compares the personal data of each user with the personal data of other users who have entered their personal data within the same period of time within of the local control unit by means of their respective memory devices. Pairs that are matched to standards by computer comparison are automatically alerted via their personal devices and an introduction is provided.

Like much of the prior art, Shapira is based on a centralized infrastructure model, which means it can suffer from the same point-of-failure issues as Tanaka. Tanaka may have somewhat limited flexibility as Shapira focuses more on a hardware / device design rather than a software solution. Shapira also focuses on a dating scene that prevents customization for other contexts. For Shapira, the data and profiles are entered into a central server before the meeting time (they are not ad hoc and spontaneous communications). The attributes are not stored in nodes / devices themselves, but are retrieved from the server.

The current literature study indicates that the most available ad hoc matching algorithms are primarily designed for infrastructure-based distributed systems and do not necessarily address the low-power and volatile characteristics required for ad hoc networks. PeopleNet (in peopleNet: wireless virtual social network. In the minutes of 11^er Annual International Congress on Mobile Computing and Networking (Cologne, Germany, August 28 - September 2, 2005) suggests that a potentially successful social network is location, community and time specific. They provide a comparative analysis of candidate algorithms to design parameters and produce valid results. Despite the fact that the network architecture and propagation paradigms are well defined, the practicalities of network / user interactions are overlooked. PeopleNet does not take into account the multi-stage authentication of authentication protocols like Bluetooth and its resulting complications in building efficient spontaneous social networks. The framework proposed in PeopleNet also ignores the limited battery capacity of nodes by introducing an always-on power management policy.

The inventors responsible for the present specification would like to mitigate or obviate at least one of the disadvantages of the prior art.

RESUME

The present specification provides a method, system and apparatus for social networking. The procedure, system and apparatus can be invoked in real time and can be spontaneous.

In one aspect, this present specification provides a social networking method, system and apparatus that creates awareness in an ad hoc environment without the need for location awareness. An architecture is provided that can allow custom search and retrieval in different scenarios and can offer the user the ability to switch contexts from one environment to another. The ability to switch contexts can be automatic, whereby the device owned by the user automatically detects a given service area and invokes the appropriate profile template. This awareness can enhance current location-based services, which most suffer from inaccurate location, not by offering a more exact location, but by offering supportive context in identifying loci. As an example,

ES 2 670 331 T3 the locus can be a diffuse radius with additional information such as color, shape and other attributes related to that radius. Proximity information can, in certain circumstances, be as valuable as information retrieved from a centralized system such as search engines. The method, system and apparatus for social networking may provide the ability to generate real-time and useful semantics in the vicinity of users.

In the proposed architecture, providers such as conference organizers, social clubs or academic institutions can create scenario-based profiles using the provided web service. These profile templates can then be made available to mobile users either from websites or using available wireless data networks. As indicated above, the profile template for a particular service area can be automatically loaded into the relevant device. The matching engine on the handheld can be configured in a generic way and can be customized based on whatever scenario is sent to you. Furthermore, the user is able to switch between scenarios depending on the context. For example, the user can activate the social profile in a social gathering and later activate a particular conference profile to find a person with a particular research interest in a conference environment.

The provided system can be changed from various social scenarios to other potential scenarios such as autonomous non-centralized landmine detection operations in military and national security settings.

In other aspects, a framework and algorithm are provided for generating and interpreting contexts in dynamic ad hoc networks. Multiple criteria and priority matching schemes are provided. A visualization engine is also provided attached to the framework for improved representation of semantics in ad hoc networks. The system provided can enable social context awareness in ad hoc networks and facilitate additional communications to the end user, ultimately reducing the user's dependency on restrictive networks (eg, operator data networks).

Patent document WO 03/073304 A1 discloses a wireless mobile terminal containing apparatus for creating, editing and storing custom user profiles for access by interrogating terminals in a short-range communication system. The wireless mobile terminal contains databases for storing standardized format profiles containing user contact information, standardized format profiles of user interests, and user- or manufacturer-defined profiles. Custom profiles are stored in a single record in a service discovery protocol database. The screen display apparatus in the mobile terminal displays indexes and contents of the profiles for user access when creating, editing and storing user profiles. The mobile terminal includes the apparatus that responds to SDP interrogations from interrogating terminals regarding access to and acquisition of user-defined personalized profiles.

US 2005/17 4975 A1 patent document discloses a communication system and methods that include a wireless communication method comprising, in a first wireless device, receiving one or more wireless device identifications associated with one or more other wireless devices, and transmitting at least one of the one or more wireless device identifications from the first wireless device to a remote computer system, and at the remote computing system, receiving the at least one wireless device identification, and accessing information associated with the at least one wireless device identification. The embodiments described therein can be used for electronic dating, social networking, and other communication applications.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a system for establishing social networks.

Figure 2 shows a schematic representation of one of the mobile devices of the system of Figure 1 Figure 3 shows an architectural framework for the system of Figure 1

Figure 4 shows a flow chart representing a procedure for a social network that can be implemented using the system of Figure 1.

Figure 5 shows an example of a profile schematic generator.

Figure 6 shows an example of a display graph that can be generated on the screen of a mobile device of the system of Figure 1.

Figure 7 shows a further example of a display chart.

Figure 8 shows a further example of a display chart and additional data that can be displayed on the mobile device of the system of Figure 1.

Figure 9 shows a graph representing a score against people compared for a person of

ES 2 670 331 T3 according to a practical case.

Figure 10 shows a graph representing a score against people compared for another person according to the practical case.

Figure 11 shows a graph representing a score against people compared for another person according to the practical case.

Figure 12 shows a flow chart representing another social network procedure that can be implemented using the system of Figure 1.

DETAILED DESCRIPTION OF THE REALIZATIONS

Referring now to Figure 1, a system for a social network is generally indicated at (50). The system (50) comprises a network (54) at its core that interconnects a plurality of base stations (58-1), (58-2) and an administrative server (62). (Base stations 58-1, 58-2 are collectively referred to as base stations 58 and generically referred to as base station 58. This nomenclature is used elsewhere in this document.) Each base station (58) has a respective service area (66), and each service area (66) includes a plurality of mobile devices (70), each mobile device managed by a respective user U. Each mobile device (70 ) can be connected to its respective base station (58) via a respective first wireless link (74). Each mobile device (70) also connects on a peer-to-peer basis with each of the other mobile devices (70) via a second wireless link (78).

As will be explained in more detail later, each service area (66) may represent any area where a plurality of users U with devices (70) may wish to establish a social network. Thus, within the service area (66-1), it is contemplated that the users (U-1), (U-2), (U-3) with respect to the devices (70-1), (70-2 ) and (703) may wish to establish a social network. Likewise, within the service area (66-2), it is contemplated that the users (U-4), (U-5), (U-6) with respect to the devices (70-4), (70-5 ) and (70-6) may wish to establish a social network.

What defines a given service area (66) is not particularly limited. For example, the service area (66-1) may comprise the useful surface of an academic context congress where users (U-1), (U-2) and (U-3) may wish to locate other academics from equal mindset and interests. This means that the templates generated by the server (62) for the service area (66-1) are based on attributes such as the research area and affiliations while in another example, the service area (66-2) can comprise the useful area of ​​a nightclub where users (U-4), (U-5) and (U-6) can be singles who want to meet potential partners of the same mindset and interests and the templates generated by the server (62) are based on attributes such as gender, age and type of relationship. The network 54 may be based on the Internet, an internet, the public switched telephone network, a packet switched network, or combinations of any of the above. The network (54) links the base stations (58) and the server (62) via any backhaul network, be it wired or wireless.

Server 62 can be based on any desired computing environment consisting of any combination of hardware, firmware, operating systems, and software. Exemplary servers include any of the servers offered under the Sun Fire ™ product line from Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, CA 95054 USA, or any other computing environment comprising one or more central processing units that interconnect random access memory (or other volatile storage medium), read-only memory (or other non-volatile storage medium), hard drives (or other persistent storage medium), network interfaces, input device and output devices via a bus. The network interface allows the server (62) to connect to the network (54).

The server (62) is configured to maintain at least one instance of a template application (64), which is configured to interact with the devices (70) in order to assist in the provision of social networking functionality between users. devices (70) within a given service area (66). In a present embodiment, the server (62) maintains a first template application (64-1) regarding the service area (66-1) and a second template application (64-2) regarding the service area (66- two). The application (or applications) (64) will be discussed in more detail later.

Each device (70) is based on the functionality of an enhanced mobile electronic device that includes at least data capabilities and would typically also include voice capabilities. Many well-known cell phone models, or variants thereof, are suitable for the present embodiment. Referring now to Figure 2, a schematic block diagram of each device (70) is shown. It should be emphasized that the structure of Figure 2 is merely exemplary, and contemplates a device that is used for both wireless voice (eg, telephony) and wireless data (eg, email, communications) communications.

ES 2 670 331 T3 web browsing, text). The device (70) includes a plurality of input devices, which in a present embodiment includes a keyboard (100) and a microphone (104). Other input devices, such as a touch screen, are also contemplated. The input from the keyboard (100) and the microphone (104) is received by a processor (108), which in turn communicates with a non-volatile storage unit (112) (for example, read-only memory). memory (ROM)), Erase Electronic Programmable Read Only Memory (EEPROM), Flash memory), and a volatile storage unit (116) (for example, random access memory (RAM))). The programming instructions that implement the functional teachings of the device (70) as described herein are normally persistently maintained in the non-volatile storage unit (112) and are used by the processor (108), which makes a proper utilization of the volatile storage medium (116) during the execution of such programming instructions. Variants of device 70 may include a laptop computer equipped with wireless capabilities.

The processor (108) in turn is also configured to send an output to a speaker (120) and a screen (124). Processor 108 also contains a first radio 128 and a second radio 132. Conceptually, the first radio (128) and the second radio (132) can be considered as network interfaces. The first radio (128) is configured for communication via link (74), while the second radio (132) is configured for communication via link (78). Thus, in a present embodiment each device (70) is a hybrid device that can communicate over link (74) and / or link (78). However, in other embodiments, it is contemplated that the first radio (128) may be omitted from the device (54) so ​​that the device (54) can only communicate via the link (78). It should be understood that, in general, a wide variety of configurations are contemplated for device (70).

In a present embodiment, the first radio (128) and link (74) are based on an area network topology, such as the Institute of Electronic Engineers (IEEE) 802.11 standard or its variants; or Bluetooth ™, or are based on a core mobile phone network topology such as GSM, General Packet Radio Service (GPRS), or Code Division Multiple Access (CDMA )) or similar. It is contemplated that the link (74) may carry data packets between the device (70) and the server (62). Therefore, it will be appreciated that if the link 74 is based on the IEEE 802.11 standard, then each base station 58 will also be a station conforming to the IEEE 802.11 standard. Also, if the link (74) is based on the central mobile telephone network infrastructure, then the base stations (58) will correspond in the same way.

In a present embodiment the second radio 132 and link 78 are based on a peer-to-peer network topology, such as Bluetooth ™, but other peer-to-peer topologies are contemplated, including peer-to-peer variants of the IEEE 802.11 standard.

Also in a present embodiment, each of the devices (70) maintains a copy of a peer-to-peer identification application (136) on the non-volatile storage medium (112). The peer match identification application (136) can be loaded into the volatile storage medium (116) and executed on the processor (108). The peer-to-peer matching application (136) on one device (70) is configured to interact with other peer-to-peer matching applications (136) on other devices (70) that are in range over the link (78). The peer match identification application (136) is also configured to access templates generated by the template application (64). Each device (70) can access such templates from the server (62), whereby the device (70) accesses the server (62) via the base station (58). The peer match identification application 136 will be discussed in more detail later.

Also in a present embodiment, the devices (70) each maintain a display engine (138) that is also maintained on the non-volatile storage medium (112) that can take the results of the social match and generate a visual representation of those results on the screen (120). The display engine (138) will be discussed in more detail later.

Referring now to Figure 3, a conceptual architecture for implementation on each device (70) in the system (50) as indicated at (150). The architecture (150) includes four layers including: 1) a communications framework layer (154); 2) a matching engine layer (158); 3) a profile processing layer (162) and 4) a profile scheme layer (166).

The architecture (150): a) is based on a free and peer-to-peer communications protocol; 2) you have the ability to create a customizable matching engine that can parse templates for adaptation; 3) has the ability to model a service-based algorithm that enables search and retrieval without excessive

ES 2 670 331 T3 user involvement and 4) uses a local storage medium to reduce or obviate the need for a centralized arbiter.

In general, each layer will be discussed in more detail later. However, at this point it can be seen that while Figure 1 labels frame layer 154 as a Bluetooth frame layer, other communication protocols including ZigBee, IEEE 802.11, and the like are contemplated. It can also be seen that the profile processing layer 162 can be based on a variety of different models including linear or fuzzy scoring or other scoring methodologies.

In a present embodiment, free and peer-to-peer communications use Bluetooth and include a 24/7 real-time search scheme to increase the ease of use of such Bluetooth devices in dynamic environments. In order to achieve ease of use, a present embodiment uses a matching process with minimal user intervention. Since Bluetooth typically has a pairing process that requires the user to continuously approve connections, the present embodiment therefore implements a modified Bluetooth pairing process to make the pairing process substantially seamless and communication substantially secure. In a present exemplary embodiment, searching (so that, for example, device 70-1 can search and locate device 70-2 or device 70-3) involves the use of L2CAP (such as as discussed in C. J. Hsu, YJ Joung, An ns-based Bluetooth Topology Construction Simulation Environment, Proceedings of the 36th Annual ANSS Simulation Symposium '03 pp. 145, 2003 (L2CAp)) as the physical layer. Also, a combination of SDP (as defined in R. Bruno, M. Conti, E. Gregori, Wireless access to internet via Bluetooth: performance evaluation of the EDC scheduling algorithm, Proceedings of the first workshop on wireless mobile Internet WMI '01 pp.43-49, 2001) is used in combination with the Transport Control Protocol over Internet Protocol (TCP / IP) for the upper layers. A conceptual mechanism of seamless pairing is discussed in general, not specific, terms in H. Rahnama, A. Sadeghian, and A. Madni, Social Context Awareness in Ad Hoc System of Systems, Proceedings of the 2007 IEEE International Congress on Systems Systems, April 18-20, 2007.

Figure 4 shows a social networking procedure represented in the form of a flow chart indicated at reference (180). The procedure (180) generally reflects the functionality of the match identification application (136). The procedure (180) can be implemented by enhancing the existing Bluetooth service discovery layer or the Service Discovery Protocol (SDP) by working in conjunction with the Logical Link Adaptation and Control Protocol (L2CAP) layer. Logical Link Control and Adaptation Protocol) as defined in the Bluetooth technical specification, which can be obtained from http://www.bluetooth.com/Bluetooth/ Technology / Building / Specifications. Note, however, that procedure (180) does not have to be implemented in this way.

Procedure (180) is a peer-to-peer procedure whereby one device (70) acts as a conceptual client while one or more other devices (70) act as a conceptual server. The blocks on the left side of Figure 4 thus reflect the functionality within the match identification application (136), which causes a particular device (70) to act as the conceptual client, while the blocks on the right side of Figure 4 thus reflects the functionality within the peer-to-peer identification application (136) in a second device (70) to act as a conceptual server. In Figure 4, as a specific non-limiting example, device 70-1 is the conceptual client while device 70-2 is the conceptual server. Figure 4 assumes that a template application template (64-1) has been obtained by the first device (70-1) and the second device (70-2).

The search request is initialized by a first device 70 (the example given in FIG. 4 being device 70-1) using a flow-based technique indicated generally as procedure 180 in FIG. 4. Communication interactions can be divided into interactions between the first device (70-1) and a second device (70-2). Procedure 180 begins at block 184, at which point device 70 initiates a search. The search initiated in the block (184) can be performed by configuring the device (70) to call a procedure that is incorporated within the functionality associated with the radio (132) of each device (70) that searches for other devices (70) to those that can be reached.

In block 188 a determination is made as to whether a profile associated with user U of device 70 has been completed by user U. Such profile generally refers to some criteria or other information that identifies user U and it can be used in matching that particular user U with other users U within the same service area. Such a profile will have been previously entered by the user U in the device (70) and stored within the volatile storage medium (116) and / or the non-volatile storage medium (112) of the device (70).

ES 2 670 331 T3

In a present embodiment the profile will correspond to a template obtained from the template application (64-1). The profiles will be discussed in more detail later. If the profile has not been completed, then procedure 180 may be configured to wait at block 188 until such options are completed.

At block 192, a list of available devices is received. Block 192 can be performed, for example, by device 70-1 engaging in a typical Bluetooth discovery process and discovery device 70-2. (It will now be appreciated that all devices 70 in system 50 can also discover each other when those other devices 70 are in range.)

In block (196), a shared key is sent to the other devices (70). The shared key is maintained within the peer-to-peer identification application (136), and is therefore known to all devices (70) that have the match identification application (136) loaded into them. In this way, each device (70) can verify that all other devices within a given service area (66) also maintain the peer-to-peer identification application (136) and therefore wish to participate in a set-up function. social networks.

Also as part of block 196, the shared key is sent to device 70-2.

In block (200), the shared key that is sent in block (216) is parsed by device (70-2) in order to verify that the key matches the copy of the key that is kept in the device (702).

At block 204, a determination is made as to whether the profile is complete. Block 204 is analogous to block 188 in that if device 70-2 has an incomplete profile, then the result of the determination in block 204 may be, for example, an exception. where an error message is returned to device (70-2) (and / or device (70-1)) and procedure (180) is terminated.

If the determination at block 204 is yes, then procedure 180 advances to block 208 and a response key is sent back to device 70-1. The response key, once received by device (70-1), allows devices (70-1) and (70-2) to actually pair with each other for the purpose of satisfying the described social networking functions. in this document. In block (212) the device (70-1) waits to receive the response key from the device (70-2). If the response key is not received, then a pairing with device 70-2 is considered to have failed and then, in block 216, the connection to it is closed. (As a specific performance example of block 212, suppose device 70-1 is performing block 212 and waiting to receive a response key relative to device 702. If none is received Answer key thus in block (216) the device (70-1) will close the connection with the device (70-2) terminating the link (78-2)).

However, suppose that in block (212) the determination is yes because a response key was received from device (70-2), then the procedure (180) advances from block (212) to block (220) . In block 220, device 70-1 will search for requests from device 70-2 (or other relevant device 70). (As a specific example of the performance of the block (220), suppose that the device (70-1) has received the response key from the device (70-2) that confirms the possibility of connection with the device (70-2). In this case, in the block (220) the links (78-2) will be active and the device (70-1) will be listening for requests from the device (70-2)).

In block 224, when a request is received, the device 70-1 that receives the request will read its own profile and send that profile to device 70-2. (The profile referenced in block (224) is the same profile referenced in block (188)). Thus, in block (224), the profile entered by the user U and stored within the volatile storage medium (116) and / or the non-volatile storage medium (112) of the device (70-1) will be read by the processor (108) from device (70-1) and sent to device (70-2).

In block (228), device (70-2) will make a call in order to obtain the profile stored in device (70-2).

At block 232, device 70-2 will implement a match operation. A currently preferred matching operation will be discussed in more detail later and involves determining a conceptual distance between each U-user within a particular service area (66) based on the profile for each U-user. In the specific example of Figure 4, the conceptual distance will be made based on the completed profile that is obtained from the device (70-1) in relation to the profile stored within the device (70-2).

ES 2 670 331 T3

At block 236, a determination is made whether there has been a match as a result of the performance of block 232. If the determination at block 236 is no, then at block 240, as desired, the connection to the relevant device 70-1 can be closed. However, suppose a yes determination is made at block 236, then at block 244 an acceptance key is sent back to device 70-1. The acceptance key that device (70-2) has matched and ultimately signals to device (70-1) that device (70-2) is open to accept the maintenance of a chat dialogue ( or other communication) between their respective devices (70).

In block (248) (which assumes that a match has been made with device (70-2)) a user U of device (70-1) can invoke a chat function or other communication function with device (70 -two).

It should now be apparent that the procedure (180) is presented in a simplified form. It is interesting that in a typical implementation the device (70-1) would also carry out its own version of the blocks (232), (236) and (244) in order to develop conceptual distances between the device (70-1) and the device (70-2) from the perspective of the user of the device (70-1). It should now also be understood that the interactions in procedure (180) can be extrapolated to reflect interactions between multiple devices (70) within the same service area (66). In such multi-interaction cases, there may be a single device (eg, device 70-2) that is designated to act as the conceptual server, while the remaining devices act as the conceptual clients. Any suitable selection process may be invoked to select which of the devices (70) will be the conceptual server.

It will now be apparent that procedure (180) can be varied and, likewise, that many specific design choices can be made regarding how to implement various blocks in procedure (180). For example, as discussed above, block 232 refers to the performance of a match operation. Block 232 also corresponds to matching engine layer 158 of architecture 150. An existing match operation that can be used for block 232 includes an appropriate modified version of the match operations discussed in the M document. Paolucci, T. Kawmura, T. Payne, and K. Sycara, Semantic Matching of Web Services Capabilities, First International Semantic Web Congress, pp.333-347, 2002. However, a more preferred match operation today is a protocol of novel coincidence described later.

A currently preferred match operation is performed by processing attribute-weighted profiles. These profiles include attributes that are predefined by the web service and stored on devices as Extended Markup Language (XML) schemas. Profile selection or rejection is done using a linear scoring model between assigned attributes. Table I represents an example of a simple profile created for a social interaction scenario. The user creates search criteria and a scoring model is entered to rank the selections.

TABLE I. SOCIAL COINCIDENCE SCENARIO

<td colspan="7">User profile</td>

<td>Name</td><td colspan="2">Gender</td><td>Age group</td><td colspan="2">Hobbies</td><td>Picture</td>

<td>John</td><td colspan="2">M</td><td> 18-24</td><td colspan="2">A, B, C</td><td>Image of John</td>

<td></td><td colspan="2"></td><td></td><td colspan="2"></td><td></td>

<td colspan="7">Search criteria</td>

<td colspan="2">Gender</td><td colspan="3">Age group</td><td colspan="2">Hobbies</td>

<td colspan="2">Woman</td><td colspan="3"> 18-24</td><td colspan="2">A, B, C. D</td>

A profile allows each communicating node to calculate a numerical measure called the conceptual distance (DC). This is a score related to common elements in user profiles, the higher the conceptual distance, the more these nodes have in common. The calculation of the conceptual distance is the result of the multiplication of the weight matrix (W) and the profile matrix (P). The weight matrix is ​​the importance of each attribute in that particular analysis, for example considering a comparison of dating profiles, finding a person of the opposite gender is more significant than finding someone of a similar age band, therefore the The weight matrix will reflect that with a higher weight associated with gender than age. This is demonstrated in Equation 1, which will solve for a conceptual distance for any combination of profile matrix if the elements of P or W are static or variable.

ES 2 670 331 T3

Equation 1

<td>I, 'cd₂X</td><td>₌</td><td>Y, $</td><td>Pu P₂₂</td><td>θ θ</td><td>P_im~ A.M</td><td> •</td><td>h23 jg ' _I</td>

<td></td><td></td><td>Λ</td><td>P „2</td><td>θ</td><td>P nm ~</td><td></td><td></td>

The matching is done by processing profiles with weighted attributes. These profiles include attributes that are predefined by the web service and are stored on devices as Extended Labeling Language (XML) schemas. Selection or rejection of profiles is done using the relevant attributes of those profiles. These can be in many forms, including numerical, descriptive, or abstract. Each attribute falls into a number of categories defined during the generation of the profile. This is shown in Table II.

TABLE II. NODAL CATEGORIES

<td>Category</td><td>Example</td><td>Description</td>

<td>Numerical</td><td>1,2,3 .. Etc.</td><td>Numeric manipulation based on a single value is performed</td>

<td>Interval numeric</td><td>1 -20 21 -23 etc.</td><td>Numeric manipulation is performed based on a range of values</td>

<td>Ready</td><td>Dancing, climbing, etc.</td><td>Similarities of a flexible list of traits are compared</td>

<td>Exclusive list</td><td>Man or woman</td><td>Opposite similarities of a predefined list of traits are compared</td>

Profile selection is an important part of the process as it involves explicitly defining the importance of each context with respect to the global system and defining the weights for the W matrix (see equation 1). Each context that affects the systems decision is considered. If some factors are ignored or not included, then the system ignores them as not applicable when making a determination.

The matrix P is solved by comparing each node profile with all other nodes present in the system using algorithms defined in the profile. These cover a wide range of comparisons in order to calculate the conceptual distance effectively for use in a generic distributed system. Each attribute that is applied to the system is associated with a comparison algorithm that is necessary to generate the matrix of system profiles (Table

III).

TABLE III. COMPARISON ALGORITHMS

<td></td><td>Kind</td><td>Comparison algorithm</td>

<td>TO</td><td>Numeric</td><td>fs</td>

<td>B</td><td>numeric interval</td><td>N</td>

<td>C</td><td>Exclusive list</td><td>C (t) = Cn (t) ± c4t)</td>

<td>D</td><td>Ready</td><td>Ώ (/) -1 ^{Λ = ι}N</td>

A (t) is the final score of two numerical values, a_n(t) already_m(t). to_n(t) is the principal value, which is used to divide to_n(t) 25 - a_m(t), and obtain the relative difference. The absolute value is then subtracted from one, to obtain a percentage of the similarity, compared to the main value a_n(t). B (t) is the final score of two numerical values, defined by their

ES 2 670 331 T3 index in a predetermined range of numerical values. The index of the first value (bn) is subtracted from the index of the second value (bm). N is the total number of partitions in the interval. Each index (b¡) will be [0 &lt;bi &lt;N-1]. The relative difference and the percentage are calculated similar to A (t). C (t) is the score of two Boolean values, with a default score of opposite sign. C (t) calculations return the absolute value of the difference between the two values, based on their score representations. In our example below, we choose the values ​​0.5 for male and -0.5 for female, resulting in a score of one for opposite values, and a score of zero for matching values. D (t) is a direct comparison of string elements. The score is a result of the count of how many elements (dn) elements of the primary list exist in the secondary list (dm). The relative difference is calculated by dividing the number of matches by the number of items in the primary list. The final score is produced as shown by Equation (1), multiplying each individual score by its predetermined weight, and added together.

Table IV shows the definitions associated with the attribute of each profile. The column in matrix P is converted to a calculation based on the type defined for it. For example, if the first weight W1 was an age comparison, the profile would define it as a numeric type or numeric interval, therefore the results of the matrix P for column one would be the results of the equation A (t) or B (t) where as if W2 were a gender comparison the second column of the matrix P would be the results of C (t).

TABLE IV. DEFINITIONS

<td colspan="2">Definitions</td><td>Example</td>

<td>an</td><td>It is the numeric value or function associated with the attribute</td><td>for example, Age = 12</td>

<td>bn</td><td>It is a numeric value associated with the set of intervals that populates the numeric value</td><td>{0to20} {21ío30} {31to40} b = 0 b 1 h-2</td>

<td rowspan="4">cn</td><td rowspan="4">It is a single value tied to a binary comparison</td><td>Male = 0.5</td>

<td>Woman = -0.5 or</td>

<td>Mobile = 0.5</td>

<td>Stationary = -0.5</td>

<td>dn</td><td>is an interval of skills / tastes associated with the node</td><td>for example Hobbies,</td>

<td>N</td><td>This is the number of objects in the dataset</td><td>for example, the numeric range above has an N = 2 while the skill range for the example DN = 3</td>

<td>n</td><td>It is the node that makes the comparison</td><td></td>

<td>m</td><td>It is the node that is compared with n</td><td></td>

Referring back to Figure 4, remember that prior to the performance of procedure (180) it was assumed that a profile had been created for user U, and that in block (188) a check was made as to whether that profile had been completed. (Note also that profile schemes conceptually refer to profile scheme layer (166) in architecture (150)). Profile scenarios, which can be used to create profiles by individual users U, can be created using any appropriate or desired interface. In a currently preferred embodiment a web interface (300) shown in Figure 5 is used by administrator A operating server (62) to create various profile schemes. (Note that profile schema creation refers conceptually to the profile processing layer (162) in architecture (150)).

The web interface (300) comprises a plurality of fields including the attribute (304), the type (308), the category (312), the weight (316) and the filter (320). An add attribute button (324) allows administrator A to add additional attributes under attribute (304). Corresponding to each attribute (304), a type (308), a category (312), a weight (316) and a filter (320) can be associated. An upload image dialog box (324) may also be included so that a user U can provide an image of himself. The output of the web interface (300) is an XML file (328), which represents the particular profile schema that has been generated using the interface (300).

A different profile scheme can be created for the service area (66-1) and a second one for the service area (66-2). It is the different profile schemes that conceptually separate the match server application (64-1) from the match server application (64-2). Thus, for example, scenario providers

ES 2 670 331 T3 such as conference organizers can use this web interface (300) to create profile schemas, produced in the form of XML file (328). The XML file (328) can then be sent to each device (70) in order to create a questionnaire that is completed by each user U to ultimately create a profile for that user U which is then stored in the respective device (70 ). (Alternatively, the XML file (328) can be sent to another device that is used by user U to generate the profile and then the generated profile can be downloaded to his device (70)).

Another embodiment provides the display engine (138) so that the results of the social match can be more easily displayed and analyzed by each user U. The display engine (138) is configured to calculate the match scores of the nodes present in the surroundings and create a social map that includes the conceptual distances between the nodes. Such social maps can be created and updated dynamically, spontaneously and in real time. The display engine (138) may be based on any vector graphics engine currently known or contemplated in the future including Java JSR226, openGL, DirectX, and other 3D generator graphics engine. A simplified example of possible outputs of the display engine (138) on the screen (120) of the device (70-1) operated by the user (U-1) is shown in Figure 6. In the screen (120) of figure 6, a node representing the user (U-1) is shown in the center, representing the user (U-1). A second node representing the user (U-2) is shown connected to the user (U-1) and a third node representing the user (U-3) is shown connected to the user (U-3). Note that in figure 6 the third node representing the user (U-3) is further away from the node representing the user (U-1) than the second node representing the user (U-2). This indicates that user (U-2) is a closer conceptual match to user (U-1) than user (U3). Figure 7 shows a more complex example than Figure 6, where there are ten users within the relevant service area (66) instead of just the three in Figure 6. Figure 8 shows a more complex example than figure 7, where ten users are shown within the relevant service area (66), and also the profile of the user U that has the best match with the user (U-1) Device (70-1) is shown as a twenty-five-year-old male, completed with an image and a list of hobbies that best match user U.

Enhancements to the various inputs that can be created using the display engine (138) are contemplated. For example, the output may be configured to indicate which users U are themselves searching for other users. The output can be configured to indicate that certain users are conceptually matched to each other, while at the same time indicating which of those same users are wanting to be contacted or addressed.

Various practical cases have been implemented using the teachings in this document. The cases involved in the studies were calculated using a platform that implements the matching algorithms described above. The match profiles using the four key data types and score calculations were sufficient to satisfy a social match scenario, and they successfully identify compatible profiles. This will provide the user with social context awareness about the surrounding people and indicates how far or close a user is to other nodes in terms of what they like or dislike.

Java-enabled mobile phone prototype user interfaces have been developed and is shown in Figure 8. The screen (120) is divided into two dynamic areas. The upper section generates a social map by interrogating adjacent nodes every five minutes (or another suitable period of time) using scalable vector graphics libraries available on the JavaME platform. In the current version of the prototype shown in Figure 8, the highest possible match in the social environment is displayed at the bottom of the screen and the user has to press a button (Next) to see the next highest match. For the study, an environment with ten profiles based on gender who prefer heterosexual matches, and focused on two men and a woman who are constantly questioning other profiles for a match. Current prototype user interfaces can be ported across mobile platforms including Symbian, Research in Motion Inc.'s Blackberry ™, and, as mentioned above, Java phones, and it should be understood that the teachings in this document are not phone-specific. enabled for Java. In Java, three main JSRs are used including JS82 for Bluetooth, JSR226 for graphics, JSR 177 for security, and JSR172 for web services

Tables V-VII and Graphs I-III (shown in figures 9, 10 and 11 respectively) show three weighted search criteria (age, hobbies and gender) used to calculate the final conceptual distance in a social environment of ten people. . (Note that users are referred to as persons or people in Tables VVII and Figures I-III). A score of zero indicates the least desirable node. The sum of all the weights identifies the maximum score of one hundred and fifty, which indicates a perfect match. The graphs show high scores between opposite genders and low scores between the same genders. Such scores are the rudiments to generate the social graphs and represent the distances between the nodes.

ES 2 670 331 T3

Although Gender with a high weight of seventy-five was the main criterion when obtaining the conceptual distances in scenarios defined in Tables V-VII, it is not the only coincidence factor. Age weighing fifty and Hobbies weighing twenty-five are subsequent factors in providing a more exact match according to the search criteria. For example, in Table V, the best match for Person 1 is Person 3 with a high concept distance of 144.4 and the least desirable match is Person 9 with a low concept distance of 38.9. These conceptual distances are playing the key role when viewing the social maps shown in figure 5. It is important to note that the default weight for each attribute is defined by the web service shown in figure 3. In order to further customize the search, the user also has the ability to change the default weight values ​​on the handheld to customize the 10 search criteria. For example, in Table VI, the user can decrease the weight assigned to Genre and increase the weight assigned to Hobbies to prioritize the search to find people with hobby D.

<td colspan="3">Table V - Search space and scores</td><td colspan="2">for person 1</td>

<td></td><td>Age</td><td>Hobbies</td><td>Gender</td><td>Punctuation</td>

<td>Pesos</td><td> 50</td><td> 25</td><td> 75</td><td></td>

<td>Person 1</td><td>25 (desired)</td><td>A, B (desired)</td><td>M</td><td></td>

<td> 2</td><td> 30</td><td>C, D</td><td>M</td><td> 44,4</td>

<td> 3</td><td> 33</td><td>A, B</td><td>F</td><td> 144,4</td>

<td> 4</td><td> 23</td><td>D</td><td>M</td><td> 50</td>

<td> 5</td><td> 29</td><td>B, C</td><td>F</td><td> 131,9</td>

<td> 6</td><td> 15</td><td>A, D</td><td>F</td><td> 126,4</td>

<td> 7</td><td> 40</td><td>A, B, C, D</td><td>M</td><td> 58,3</td>

<td> 8</td><td> 45</td><td>TO</td><td>F</td><td> 120,8</td>

<td> 9</td><td> 39</td><td>C</td><td>M</td><td> 38,9</td>

<td> 10</td><td> 21</td><td>B</td><td>F</td><td> 131,9</td>

_Table VI - Search space and scores for person 4

<td></td><td>Age</td><td>Hobbies</td><td>Gender</td><td>Punctuation</td>

<td>Pesos</td><td> 50</td><td> 25</td><td> 75</td><td></td>

<td>Person 4</td><td>30 (desired)</td><td>D (desired)</td><td>M</td><td></td>

<td> 1</td><td> 25</td><td>A, B</td><td>M</td><td> 44,4</td>

<td> 2</td><td> 30</td><td>C, D</td><td>M</td><td> 75</td>

<td> 3</td><td> 33</td><td>A, B</td><td>F</td><td> 125</td>

<td> 5</td><td> 29</td><td>B, C</td><td>F</td><td> 125</td>

<td> 6</td><td> 15</td><td>A, D</td><td>F</td><td> 133,3</td>

<td> 7</td><td> 40</td><td>A, B, C, D</td><td>M</td><td> 63,9</td>

<td> 8</td><td> 45</td><td>TO</td><td>F</td><td> 113,9</td>

<td> 9</td><td> 39</td><td>C</td><td>M</td><td> 44,4</td>

<td> 10</td><td> 21</td><td>B</td><td>F</td><td> 113,9</td>

Table VII - Search space and scores for person 8

<td></td><td>Age</td><td>Hobbies</td><td>Gender</td><td>Punctuation</td>

<td>Pesos</td><td> 50</td><td> 25</td><td> 75</td><td></td>

<td>Person 8</td><td>45 (desired)</td><td>A (desired)</td><td>F</td><td></td>

<td> 1</td><td> 25</td><td>A, B</td><td>M</td><td> 133,3</td>

<td> 2</td><td> 30</td><td>C, D</td><td>M</td><td> 113,9</td>

<td> 3</td><td> 33</td><td>A, B</td><td>F</td><td> 63,9</td>

<td> 4</td><td> 23</td><td>D</td><td>M</td><td> 108,3</td>

<td> 5</td><td> 29</td><td>B, C</td><td>F</td><td> 38,9</td>

<td> 6</td><td> 15</td><td>A, D</td><td>F</td><td> 47,9</td>

<td> 7</td><td> 40</td><td>A, B, C, D</td><td>M</td><td> 150</td>

<td> 9</td><td> 39</td><td>C</td><td>M</td><td> 119,4</td>

<td> 10</td><td> 21</td><td>B</td><td>F</td><td> 27,8</td>

The user interface of our prototype is developed on a Java-enabled mobile phone and is shown in Figure 5 (b). The screen is divided into two dynamic areas. The upper section generates a social map by polling adjacent nodes every 5 minutes using scalable vector graphics libraries available on the JavaME platform.

ES 2 670 331 T3

In the current version of the prototype, the highest possible match in the social environment is displayed at the Bottom of the screen and the user has to press a button (Next) to see the next highest match (figure 5 (b)) . For our study, we established an environment with 10 profiles based on gender who prefer heterosexual matches, and centered on 2 men and 1 woman who constantly interrogate other profiles about a match.

To provide more perspective and detail, Figure 12 shows a social networking procedure depicted in the form of a flow chart and indicated at reference (400). Procedure (400) is performed using system (50). The blocks in procedure (400), except block (410), are performed by devices (70) using their copies of local matching applications (136) and display engines (138). Block (410) in procedure (400) is performed by server (62), which generates a regular expression to generate common keys that are used between devices (70). The keys referenced in block 410 correspond to the keys referenced in blocks 196, 200, 206 and 244 of procedure 180.

Block (405) represents the search activity of all nearby devices (70) for each device (70). Block 405 generally corresponds to blocks 184 and 192 of procedure 180.

Block (415) represents shared key exchange activity by each discovered device (70) to verify the existence of matching applications (136) on each discovered device (70). It will now be appreciated that in system (50), devices (70-1), (70-2) and (70-3) will discover each other, and that devices (70-4), (70-5) and (70-6) will discover each other. Block 415 generally corresponds to blocks 196, 200, 208, and 212 of method 180.

Block (420) represents the formal override of the traditional Bluetooth pairing process between devices (70), in favor of allowing the functionality of the matching identification application (136) to use the Bluetooth stack in order to satisfy the functions of social networking as described in this document. Block (425) is invoked to the extent that each device (70) does not locate the match identification application (136) on another device (70). Block 425 enforces the traditional Bluetooth pairing process between devices, in accordance with known Bluetooth pairing procedures according to the prior art.

The block (430) represents the exchange of profiles between all the devices (70), which are in communication with each other and which have verified with each other that each of them is executing the matching identification application (136). Block (430) corresponds in general to blocks (220) and (224) of procedure (180)

The block (435) represents the determination of a conceptual distance between the devices (70) that have exchanged profiles with each other. The block (435) can be made by each individual device (70). Block 435 generally corresponds to blocks 228 and 232 of procedure 180.

The block (440) represents the indication of the display engine (138) in order to create a social map of the type shown in Figures 6, 7 and 8.

It can be seen that in procedure 400, once block 440 is completed, procedure 400 cycles back to block 405 and thus the social map is continuously updated.

Although the foregoing describes certain embodiments, it will now be apparent that combinations, subsets, and / or variations of those embodiments are contemplated.