WO2020033611A1 - System and method for socializing and playing games involving personal meetings with mobile computing devices - Google Patents

Abstract

To facilitate socializing and playing computer games, a first user, interacting with a distributed computing process, specifies a social event which they are organizing. In a preferred embodiment, other users attending the event bring smartphones on which they can see the profile pictures of other users attending the event. Users attending the event are enabled to start games in the distributed computing process, which the other users can conveniently join.

Description

SYSTEM AND METHOD FOR SOCIALIZING AND PLAYING GAMES INVOLVING PERSONAL MEETINGS WITH MOBILE COMPUTING

DEVICES

The field of the invention is computer-assisted socializing and game-playing, or alternatively computer-assisted personal introduction and game-playing.

SECTION 0 -- Editorial note for the reader

This description is divided into the following sections which should be read in order:

Section 1 contains an overview, with a non-technical description of a few preferred embodiments. The issue of usefulness is also covered.

Section 2 Contains more detailed description of many more possibilities for embodying the invention.

Use is made of text bracketing of the form:

[/BEGIN something]

Some Text

[/END something]

The line with "/BEGIN" above is an opening bracket for a bracket pair containing "Some Text"; the line with "/END" is the matching closing bracket of the bracket pair containing "Some Text". This system allows the text enclosed to be clearly set apart and referred to later as the 'something' and there will be no ambiguity about text boundaries in which the something was defined. This system makes this description readable without ambiguity even if reduced to ASCII text.

Apart from bracketing, only paragraphing and section numbers, such as SECTION 1.1, 2.S. etc formally delineate text. Section breaks are defined with SECTION in all caps, and sections are referred to as 'Section'.

Capitalization is sometimes used to indicate a word has a special meaning; for example, Event shall mean an organized social event or activity, as organized using this invention.

Note on language use: throughout the description, the word 'potentially' should be regarded as meaning exactly 'potentially, in some embodiments of the invention'. Instead of using phrases like 'one user' and 'another user', we usually use phrases like 'user A' and 'user B' for greater clarity. Generally such use of 'user A' and 'user B' should be regarded as meaning 'any user A (in the specified context)' and 'any user B (in the specified context)'.

SECTION 1— Overview

The invention facilitates dating, in particular the business of meeting and making a connection with a partner.

Two preferred embodiments will be described in this section. To avoid repetition, a common set-up scenario for the embodiments discussed in Section 1 will be called the Common Scenario. The Common Scenario contains largely only prior art. (Technical note: arguably what we call the Common Scenario is a set of scenarios, but it is easier to refer to it as a scenario for our purposes; therefore anything represented as being in the context of the Common Scenario should be regarded as having been presented in the context of any of the set of scenarios represented by the description of the Common Scenario.). The Common Scenario is as follows:

[/BEGIN Common Scenario Description]

There is what we can loosely term a 'social media' website, and it is owned or controlled by a party we shall call the Provider. A criterion sufficient for our purposes to define it as a social media website is as follows: that users of the website sign up, sign in, and that associated with user's accounts are profiles, with most profiles usually including a photograph of the user; and that the Provider in some way facilitates the communication and socializing of users with other users through the website.

Some users are called 'Organizers'. They are Organizers by virtue of the fact that they are enabled by the Provider to define and register on the website social events or social activities, and specify on the website their physical time and place, along with descriptions of the social events or activities. Such an Event is potentially a gathering around a topic of interest. It can also be simply a dance, or a meeting in a pub, or a hiking trip. Such specific social events or activities, defined and registered on the website in this way by Organizers, shall be called Events, spelt with a capital 'E'. The area in which those attending the Event are expected to be while attending it, we shall term the 'Attendance Area' of the Event.

Normally the Provider by some means makes information regarding any given Event of any Organizer available to other users of the website; this information is available potentially in that the Organizer can share such information with the Organizer's friends and anyone who receives the information can potentially also share it with their friends; or the Organizer pays the Provider for advertising such information about the Event; or potentially the Provider allows users to search for Events near them which they find appealing, using a potentially advanced search which includes terms in the topic of interest or nature of the event. Potentially an event can be unrestricted and any user of the Provider's website can come; potentially an Organizer can through the website configure an Event such that registration of attendance is required in advance. Potentially, sometimes an Organizer keeps an Event private and 'invitation only', sending the invitations through the website, and only invited people can register.

Users can register themselves on the Provider's website as going to a specific given Event which has been organized by a specific Organizer, which is a step potentially requiring the Organizer's approval.

Assume now a specific Organizer which we shall simply call 'the Organizer', and a specific Event which we shall call 'the Event'.

Associated with the Provider's website is the Provider's related web app which we shall simply call 'the app'. Many users going to a given event bring a smartphone which has the app installed. By some means they 'check in', meaning indicate themselves to the app as attending the event, or potentially check-in is done automatically by the app if their physical location is in in the Attendance Area, if the app is able to receive their physical location from a GPS or other positioning device in their phone.

At the time of the Event, the users attending it, meet at the place for the Event as designated by the Organizer. For a user attending an Event and signed into the app, the app can potentially display for user A, photographs of user B, where user B is any other user who is attending the Event.

User A can potentially see on the app on their smartphone, in addition to the photograph of user B, additional information about user B, which user B has provided; this information about user B, in conjunction with the photograph of user B, we shall refer to as user B's 'Event Profile'. This is potentially B's long-term social media profile in its entirety, or it is potentially part of that which B has made available for this Event; or it potentially contains information which B has set specifically for this event. It is not necessarily exclusively information about B which we can say has a long life (meaning remains accurate for some time, like where they live) but could be very short-term, like even a mood that B is in. It could be in the form of a command or proposal, designed to B to break the ice, such as 'ask me about my funny story about my trip to Nepal'. (Note: for our purposes, this command does qualify as information about B: it informs people that B is making that particular proposal.)

The photographs and Event Profiles which a given user can see of other users attending the Event are potentially narrowed as configured on the app by the Organizer, such as, for example, men can see only women or vice versa.

The photographs a given user can see are potentially narrowed further by the user, if the Organizer allows it, and/or the user instructs the app to highlight users satisfying a criterion which the user specifies to the app. [This will be called Search, described later.]

By means of a photograph a user A sees of user B on the app, in conjunction with user A's ability to recognize a physical person they see as being a match for a photograph, user A can indicate user B to the app as one particular person they meet who is attending the Event, by in some way interacting with the photograph of that user B on the app through the app's interface.

In what follows, interpret 'the users' as users attending the Event.

Generally if 'user' is used without qualification in what follows, it should be regarded as a user attending an Event; if it is a user is to be regarded as an Organizer of an Event, it will be made explicit.

[/END Common Scenario Description]

SECTION 1 1 - Embodiment 1 - ('MOST^')

[/BEGIN Embodiment 1 Description]

[ [

Assume all of the conditions of the Common Scenario described above apply, and all of the terminological conventions established in the Common Scenario apply. If in any doubt, substitute this text between the double square brackets with the Common Scenario Description text.

ADDITIONALLY: -

]]

Assume there are two users at the event, user A and user B. While at the Event, user A sees user B and is interested in remaining in communication. At a quiet moment, user A looks on their app through the individual pictures that the app provides of those users attending the event (to which potentially may or may not be attached names and profiles). User A finds the profile picture of user B. User A taps on this profile picture and a menu appears of reasons why A might want to remain in communication with B, that is, for what relationship aim or goal. One of the reasons available to A is 'Remain in communication with possible goal of long-term relationship', and this is the one A selects.

Only if user B likewise expresses an interest, through the app, in user A which is also of type 'Remain in communication with possible goal of long term relationship', they are both notified of their common interest by the app, and of their matching reasons to remain in contact (that is, for a long-term relationship in this case). If necessary, the app takes additional steps to enable them to remain in communication. If B does not express such an interest in user A, B is not informed that user A expressed an interest in B. Note that if B expresses an interest in A but the goal is 'short-term relationship', (and A did not additionally express an interest in B with the goal 'short-term relationship'), neither are informed of their showings of interest in each other.

We have not specified when the users are informed by the app of the match if it exists. Potentially it is the next day after the meeting, but it could be at the meeting also. Potentially the time at which they are informed is configured by the Organizer. The organizer can potentially also allow users to express users' interest in each other through the app for some Organizer-configured time after the Event.

[/END Embodiment 1 Description]

A note regarding interfaces: generally we are not concerned in this invention with specific interface, for example, that by which user A selects user B. The important thing is that User A can do it based on the combination of the photograph of user B, and their ability to match it with their own sight of user B.

The above embodiment presents tremendous advantages on a number of levels.

The business of expressing interest can be fraught with barriers and awkwardness. If one party shows interest in the other, and the other is not interested, the first one can suffer embarrassment, deflation, or disappointment. Further, the party who is being approached and asked, for example, for contact details, may find it unpleasant to refuse, and may sometimes give contact details when they really did not want to show an interest. All of these problems are exacerbated when other people are watching. In many cases in real life, an approach which would have been successful is not made.

The above embodiment has the advantage of solving all these problems, by making the show of interest 'mutual only' because no interest is revealed unless it is mutual and matching. It provides what we will call a 'Mutual Only Show of Interest' which is abbreviated as MOSI throughout this description.

The following is the definition of a MOSI:

[/BEGIN informal definition of MOSI]

A MOSI is a show of interest from Person A to Person B, the interest being related to a particular goal that A has expressed regarding a desired relationship with B, and such interest that A has in B is only revealed to B only if B shows an interest in A with a matching goal.

[/END informal definition of MOSI]

A MOSI cannot be carried out by two people alone without tools or an intermediary: they require the help of a trusted intermediary, human or technological, to execute properly. In this invention, the trusted intermediary is the networked computer system of which the website and the user's smartphone apps are part (in more precise and general terminology used later, the intermediary 'distributed application' of which the website and the user's smartphone apps are front ends).

In practice, for a MOSI to be useful of course, it is presumed that there will be means for A and B to remain in communication with each other, and that it will be provided by the intermediary if required.

We shall now make a more precise definition of MOSI.

[/BEGIN formal definition of MOSI] Person A conveys in a manner unseen to Person B, to an intermediary X, the information that A is interested in B, the interest being related to a particular goal that A has regarding A's desired relationship with B; and if only if B also conveys to the intermediary X an interest in A with a matching goal, the information is revealed to both A and B that they have this mutual interest, and the matching goals revealed; and we shall say that the two MOSIs in question matched: alternatively we will say that they were 'successful'. This process of revealing to A and B the said information of their mutual interest and matching goals we shall term 'MOSI notification'.

We will say that A has 'directed' or 'initiated' a MOSI towards B (with an associated goal), with X as intermediary. B will be described as A's 'target' in the MOSI. We shall say that X has offered a 'MOSI service' to A and B if X has given them the opportunity to use X as an intermediary in this way. We shall say that X has 'executed' a specific MOSI for A if it has carried out all the expected steps of the MOSI service of a given MOSI which A has initiated.

[/END formal definition of MOSI]

Generally, X, the intermediary of the MOSI, in this invention is the app.

Note that the proper execution of a MOSI sometimes entails doing nothing that A or B can see, but it involves checking information to determine whether or not something should be done which A or B can see. A properly executed MOSI can produce a null result for A and B.

Note that matching of goals may most often mean that those goals are the same. For example, a goal of 'long-term relationship' matches with another goal of 'long-term relationship', and a goal of 'casual relationship' matches with a goal of 'casual relationship'.

But some relationship goals match with other distinct goals, and not with themselves. For example, consider a goal of a 'long-term relationship with me as the psychologically dominant partner'. This does not match with itself, this matches with the goal 'long-term relationship with me as the psychologically submissive partner'.

SECTION 1 2 Special Advantages of Embodiment 1

There are additional advantages to this embodiment, which derives from the specific details of the scenario, and the specific way in which the MOSI service is carried out

technologically.

Observe that the Organizer is now providing an important element of a dating service, specifically a MOSI service (by merely offering the event on the website), but can be entirely passive in the provision of this service at the Event. The Organizer by no means even needs to attend the Event to supply the MOSI service there.

(Editorial note: 'organizer' is intentionally used without capitals in the next paragraph below to denote a general organizer of an event, not one in the context of this invention, which would have been spelled with a capital Ό'.]

Face-to-face organized dating services are in use, and often a non-technological MOSI service is offered by its organizer, but there are disadvantages to the usual cases: generally the organizer has to use additional and often disadvantageous means to provide the MOSI service. A common means is simply to offer people sheets of paper to indicate the people they are interested in. The organizer has then to be there, and afterwards to do the clerical labour of checking who matches with whom, and informing the people who match; this process is not only time-consuming and therefore expensive, but it is also error-prone, and deprives people of their privacy, as the organizer can see who expressed an interest in whom. It is also indiscreet to provide the sheets of paper and it takes away from the optics of the event, and if there are people at the place who are not participation in the Event, it can make it visible to these people who is participating, which intrudes somewhat on the privacy of those participating.

This embodiment takes away all of the disadvantages mentioned in the last paragraph: specifically an Event Organizer can provide a MOSI service entirely passively and does not even have to attend; user's privacy is preserved from the Organizer; the optics of the events are not damaged, as there is nothing indiscreet about working on one's smartphone; and, the privacy of users who are participating in a MOSI-enabled event is not diminished by other people in the same premises potentially seeing sheets on which people are marking their persons of interest. An additional great advantage is that billing for the MOSI service can be handled in an entirely automated technological way by the provider.

There are many useful fee models in which users are charged fees for MOSIs, and the billing for these can be carried out in an automated manner, 'online' so to speak, by the Provider. The Organizer potentially chooses what fee model will apply to a particular Event they organize.

One simple useful fee model we shall call 'Pay-per-match'. In this model, people only pay for successful matches and pay nothing for MOSIs they made which were unsuccessful. Pay- per-match is particularly useful for an Organizer of an event which is not necessarily strongly focused on dating; for example, an Organizer simply gathers many people together for a hiking trip. Only people who make successful matches on that trip pay for those successful matches. That Organizer potentially does not even charge for the hiking trip, and revenue is gathered only from people who have matching MOSIs. Potentially the Organizer configures the app to charge different fees for matches with different goals at a given Event.

Another useful fee model at the other extreme we shall call 'All-matches-included'.

Potentially the same Organizer, organizing a different Event more specifically focussed on dating, offers 'All-matches-included'. In this case, the users will generally pay a fee for the Event which covers the 'All-matches-included' deal and there will be no extra charge regardless of how many matches are made.

There are many useful fee models under which the Provider charges the Organizer of the Event for providing the MOSI service. One is simple proportional revenue-sharing, for example, the Provider keeps a flat 30% of the fees the users paid for the MOSIs, and gives the rest to the Organizer.

There are potential security advantages. As is discussed in Section 2, there are potentially what we call 'Conditional MOSIs' which can mean user A expressing interest in a person user B which can be revealed to that person only provided that they have some attribute which may be unknown to A, and/or are certified in some way to the Provider.

SECTION 1.3 - Embodiment 2 - ('Proximity Search^')

[/BEGIN Embodiment 2 Description]

[ [

Assume that all the conditions of the Common Scenario described above apply, and all of the terminological conventions established in the Common Scenario apply. If in any doubt, substitute this text between the double square brackets with the Common Scenario

Description text.

ADDITIONALLY: -

]]

[/END Embodiment 2 Description]

The enhancement described in Embodiment 2 is particularly useful for Events in which the participants congregate in a large area, such as, for example, covering an entire organized fair or festival, such as a music festival.

It is useful for people who have a GPS in their mobile phones (or any related device which can provide their current co-ordinate to apps running in the phone) and the Provider's app is authorized by the user to read their current position and that of other users attending the Event.

The app has a means to highlight for the user, the photographs of people who are physically nearby. Potentially a user specifies to the app a radius, and users at the Event which the app can determine to be in that radius are highlighted on the app.

The word 'Highlight' should be interpreted here in the broadest sense: any means by which the the photographs of other specific people are more prominent on a given user's display is regarded as 'highlighting', including, for example, an option to display only the photographs of the highlighted people. Potentially also, as a form of highlighting of those nearby, photographs of other users are presented to a user on their app in the order of their distance from the user.

SECTION 2

This section presents potential variations of the invention. They can be assumed (i) to be variations of the invention in the context of the Common Scenario, and also, in some cases, (ii) variations of the Common Scenario, which therefore provide variations on all embodiments related to the Common Scenario. This description will make no formal distinction between (i) and (ii), as it will not be necessary. It should be assumed that all variations apply to all others, except where they contradict each other. SECTION 2.1 - Meaning of 'the spp knows'

It is arguably already a term of art in software development to say 'the application knows'; such a phrase is commonly used, at the very least informally, but possibly also formally as well these days, by software developers. Our meaning of 'the app knows X' is exactly that the app is holding information which, if a programmer who understand the app had, would allow that programmer to know X. The phrase is not meant to imply that the app is conscious.

SECTION 2.2 - The user

lent is not necessarily a martphone; server not necessarily a website

Up to now in the description, an effort was made to make the description maximally accessible to those who do not have skill in the art of distributed software development. The description of the embodiments were confined to the cases when the user at an Event is interacting with an app on a smartphone. And the app described so far was a web app, essentially or at least usually representing, in a sense, a website.

In order to achieve the due generality, we need to become more technical in our

descriptions.

Wherever we have described a user interacting with the app on the smartphone, the following should be considered as alternatives:

• The user interacts with the website of the Provider on a smartphone

• The user interacts with the website of the Provider on a PC.

• Etc.

In all cases the user is in fact interacting with a Distributed Application owned by the Provider. A Distributed Application is by definition: a software application that is executed or run on multiple computers within a network.

Distributed applications are most usually run in a client-server architecture, but there can be cases when they are not in a client-server architecture: clients and servers, while often distinct in a distributed application, in some cases are not distinct. Generally when the distinction is clear, they are distinguished as follows: the server is resource-heavy, holds most of the processing power, most or even all of the permanent data, and is not interacted with directly by end-users; the server shares data with clients over the network who do not share stored data with each other; and users interact with clients.

This usual distinction breaks down in systems such as blockchain computation, which can be on nodes, many of which can be regarded as both clients and servers.. For generality we do not confine our definition of distributed application to an implementation on client-server systems.

For further generality, whenever we have described a user interacting with the app on the smartphone, the possibility of the user interacting in any way with the 'distributed application run by the Provider' should be considered a potential alternative embodiment of the invention. Further, in what follows, we will, for simplicity, just say 'the app does this or that' rather than saying that the 'distributed application does this or that'; saying that 'the app' does it is not meant to imply that it all happens on the smartphone itself and it may be happening on the server.

When we talk about a user's GPS location, it is presumed to be supplied to the app by a device in their smartphone. The invention should be regarded as generalizable to any such location service which is available to the app from the device, not necessarily just GPS per se.

SECTION 2 3 Goals for MQS!s and their customization by Organizers

A 'goal' for a MOSI is a reason for the two parties' getting together and it can generally be characterized as Ά relationship or interaction, in which _ ', where the blank is filled with a sentence, particularly containing T, 'you' and 'me', and possibly 'we'.

Theoretically, potential MOSI goals are therefore as varied as natural human language can vary such sentences. Two simple example of such sentences are 'you and I are in a long term relationship', or even, 'you and I get married'.

Potentially, a provider could offer capability to receive MOSI goals in a natural language.

In most likely embodiments however In the recent future, the MOSI goals are customized by the Organiser: the Organizer of an Event offers, in one way or another, a selection of what we will call 'pre-set' MOSI goals which that Organizer allows for that event. Such pre-set MOSI goals would similarly naturally be specified as sentences. For shorthand, though, since many such sentences have much in common, often a short phrase will be enough, where these short phrases can be understood to be filling blanks in longer standard sentences, such as, for example:

MOSI GOAL: Ά relationship or interaction in which you and I are in a _ relationship or interaction'.

Many MOSI Goals can be identified as simply phrases which fill in the above blank.

The Organizer potentially configures a set of pre-set MOSI goals for the Event, defined by such phrases. Such phrases become natural 'names' for the pre-set MOSI goals. Naming the set of pre-set MOSI Goals is not enough: the Organizer must specify what goal matches with what, for example, by specifying matching pairs. Most goals simply match with themselves, such as 'long-term relationship' or 'short-term relationship', but 'long Term Relationship, with me psychologically dominant' matches 'long Term Relationship, with you

psychologically dominant'.

Ultimately the Provider as owner of the website and the functionality of the app, has full control over what goals can be used for MOSIs on the app. A Provider is in a position to be restrictive or offer freedom to the Organizers determine the available MOSI goals at their Events.

For example, potentially a Provider offers just a few pre-set MOSI goals, and the organizers can choose only from these pre-set goals and offer the chosen ones to the users at the Events they organize. A less restrictive Provider can configure the app to allow the Organizer to customize their own available MOSI goals as they choose.

As a simple but possibly overly restrictive example, the Provider can potentially offer just three simple pre-set MOSIs characterized as 'long-term relationship', 'short-term

relationship', 'fling'. The Organizer may choose to narrow the list of available goals down to, for example, 'long-term relationship' at one particular Event, but keep the full list of three for another.

Potentially the Provider offers 'super-Organizer' functionality: super-Organizers are special users who own dating brands, such as 'Debby's Dates', and are users of the Provider's web service. A super-Organizer can authorize other Organizers ( called sub-Organizers to the given super-Organizer) to create Events under the super-Organizer's brand on the website. Potentially, the super-Organizer creates a restrictive set of pre-set MOSI goals and the Organizers who schedule Events under this super-Organizer's brand will not be able choose preset goals for such Events other than these, except possibly the capability to narrow them still further for users. This way, a super-Organizer has control of the character of Events run in their name.

Note that an Organizer could decide to create an intentionally-vague goal, like 'keep in touch'. The meaning of the goal could be implicit in the advertising of the particular Event they run.

While it is envisioned that potentially and usefully an Organizer names their pre-set goals with phrases, the app interface does not necessarily have to use such phrases to represent those goals. An Organizer, potentially associates their named goals with iconic pictures, and those pictures rather than the phrases are used to represent the goal on the app.

SECTION 2 4 - Logically Compounded MOSI goals

We assume the Organizer provides a set of specific MOSI goals for an Event, and will call them the pre-set MOSI goals for the Event.

When there are two distinct, useful MOSI goals X and Y, there are two other distinct, meaningful, and often or even usually useful MOSI goals which can be termed compound MOSI goals, and which will be termed the OR-compound and the AND-compound of those goals X and Y respectively;

Q = X _OR_ Y

R = X _AN D_ Y

This is true if either or both of X and Y are compound MOSI goals themselves, which means that goals compounded by expressions such as ((X _OR_ Y) _AND_ Z) which are also meaningful compound MOSI goals.

The desired functionality of a MOSI with a compound goal X _OR_ Y, may be intuitively grasped fairly well by considering someone making MOSIs with the following compound goal:

'a long-term relationship' _OR_ 'a short-term relationship' ( with user B) Similarly the desired functionality of a MOSI with a compound goal X _AND_ Y, may be intuitively grasped fairly well by considering someone making MOSIs with the following compound goal:

'a long-term relationship' _AND_ Ί am a psychologically submissive partner' (with user B)

Potentially the app can provide the user the option of compounding the MOSI goals from the goals the app offers, and using these as the goals of MOSIs.

We will define the desired behaviour of an OR-compounded goal of two goals X and Y simply in that the user A directs a MOSI with this compound goal towards user B, they want it to behave exactly, in terms of what information is revealed and under what conditions, as if A directed two separate MOSIs towards B, with goals X and Y respectively. The OR- compounding functionality is useful when User A may be interested in user B for more than one possible reason; for example, it could be for either a long term relationship OR a short term relationship.

Note that:

IF

A directs a MOSI towards B with goal X; and A also directs a second MOSI towards B with goal Y;

THEN:

If B directs no MOSI towards A, with goal X, and none with goal Y, the outcome is that nothing happens; A's MOSI towards B is unsuccessful.

If B directs only one MOSI towards A, and with goal matching X, the outcome is that they are both notified of the interest and in the MOSI notification only the goal X (and the goal needed to match it sent from B's side if it is different), is revealed to them both in the MOSI notification. (Note that it preserves A's privacy in that the interest in B with goal Y is not revealed).

If B directs only one MOSI towards A, and with goal matching Y, the outcome is that they are both notified of the interest and in the MOSI notification only the goal Y (and the goal needed to match it sent from B's side if it is different), is revealed to them both in the MOSI notification. (Note that it preserves A's privacy in that the interest in B with goal X is not revealed).

If B directs two MOSI towards A, one with goal matching X and another with goal matching Y, the outcome is that they are both notified of the interest and both X and Y are revealed to them both as common goals in the MOSI notification, and the goals matching X and Y coming from B also exposed if they are different (matching goals) to the corresponding ones coming from A. So effective OR-compounding of MOSI goals is automatically provided unless the software is programmed restrictively, to restrict one user to send only one MOSI to one given other user.

In contrast with the OR functionality for compounding MOSI Goals, if the Provider is to provide an AND functionality on available goals, they must write the software specifically to support it.

We will define the desired behaviour of an AND-compounded goal of two goals X and Y simply in that if the user A directs a MOSI with this compound goal towards user B, they want it to behave exactly as if A directed two separate MOSIs towards B, with goals X and Y respectively, with the caveat that these two MOSIs have to be both successful in order for either of them to be regarded as successful, in other words they are both successful and MOSI notification occurs for both; are both regarded as unsuccessful and no MOSI notification occurs for either: a MOSI with a compound goal is like two MOSIs, except that there is an all-or-nothing condition imposed on their success.

The AND-compounding functionality of goals X and Y is useful when User A may be interested in a relationship with B but with two distinct goals which must both apply to the relationship with B.

As with non-compound goals, compound goals often match with themselves, but not necessarily, for example, example the compound goal ( 'Long-term relationship' _AND_ 'me psychologically dominant' ) matches with the compound goal ('Long-term relationship' _AND_ 'me psychologically submissive').

In this paragraph using the word 'meaningful' in the theoretical sense, not the practical sense, all AND-compounded MOSI goals based on useful goals are meaningful, but not all are sensible and useful. If _AND_ functionality is offered, the Provider or Organizer should ideally also disable some combinations as having no use, such as the goal which is represented by 'a long-term relationship' _AND_ 'a short-term relationship'. This is meaningful in that it is expressing that the user wants a long-term relationship and a short term relationship with the other user, in no particular order. This is theoretically well- defined but it is not useful. Unless the Organizer disables such a goal, the user making a MOSI with such a goal will likely have made a mistake and it will only match with another user who has made exactly the same mistake; such a user would have likely confused the _AND_ and the _OR_ functionality of goal combination, and actually intended the _OR_ combination.

The app can potentially allow the user to create and name their compound goals, and the app will store them for the user under those names. The app can potentially allow a user to select one of their stored compound goals as as their default goal for the MOSIs they make.

A preset goal is regarded as a non-compound goal. Note that the distinction between compound and non-compound is a function of the Organizer's settings, and not an abstract property of the actual goals in a human sense. Earlier we presented a potential pre-set goal ('Long-term relationship with me psychologically submissive'); this is the same in meaning in a human sense as the compound goal ('Long-term relationship' _AND_ 'me psychologically submissive'), while one is compound and the other is not, just as an artefact of how the Organizer has configured things.

SECTION 2.5 - Conditional MGS is

If A is directing a MOSI towards B, the app can potentially have the functionality that A specifies, in addition to the MOSI goals, a condition applying to B, which if B does not satisfy, the MOSI will not be regarded as successful and no notifications will be sent. The condition which A applies to B is called a 'MOSI condition'. A MOSI in which a MOSI condition has been applied by the user we shall call a 'conditional MOSI'.

A 'MOSI condition' is quite different from a MOSI goal: the former is a condition which the target of the MOSI must satisfy; the latter is a goal for the desired relationship: a MOSI condition is defined as a condition on the target user; a MOSI goal is a goal/condition for the desired relationship with the target user.

A MOSI condition can usually be expressed with a sentence containing 'you', in which 'you' represents the target of the MOSI, for example, 'you are of Religion R'.

The functionality of a conditional MOSI is as follows: In the process of directing a MOSI towards B, A specifies a certain condition, the MOSI condition, that B has to satisfy, such as, for example, 'you are of Religion R'. The Provider has to be able to determine, based on information that it has about B, that B is of religion R, otherwise the MOSI will not be successful. If the Provider cannot do this, either by virtue of the fact that it does not have the information, or cannot legitimately use it in this way, the MOSI cannot be regarded as successful, and no MOSI notifications will be given to A and B related to it. In a sense the MOSI is quietly cancelled if the condition cannot be verified to be met (that is, cancelled without telling A).

The interface is not much of our concern, but in a simple but illustrative case, when making the MOSI, the user selects a checkbox titled 'you are of Religion R'.

Note that care must be taken in that in this case for example, if the MOSI is successful, when A receives the notification, A has been indirectly informed that B is of Religion R. This is not a problem if B allows it. But generally for privacy reasons, for a given user B, the MOSI condition of a conditional MOSI, which A has directed towards B, can only be evaluated as being satisfied by the Provider, using information which the Provider (i) has about B, and (ii) is authorized to reveal to A. If this information is private to B, potentially the revealing of this information requires some form of advance authorization from B, to release B's information under certain conditions. The scope and power of these 'advance

authorizations' will be discussed later in the section titled 'Enhanced Control of Privacy'. The conditions which B has imposed on the privacy of such information will therefore also have to be met if the MOSI is to be regarded as successful. Fortunately many people, with much of their information, would be happy to authorize it's being indirectly revealed through a successful conditional MOSI, especially a successful conditional MOSI where the goal is, say, 'long-term relationship'.

Just as with goals, the Organizer potentially provides 'pre-set conditions'. Potentially some things like pre-set conditions are provided by the Organizer except that they have parameters which the user must fill in, that is, instantiate; these we'll call pre-set proto- conditions. For example, a pre-set proto-condition could be 'age is greater than _ ', and the user making the MOSI with the condition fills the blank. A pre-set condition is meaningful already; and a proto-condition is meaningful when its parameters are instantiated, that is, when the blank is filled by the user. We shall define a noncompound condition as either a pre-set condition, or an instantiated pre-set proto-condition (for example 'age is greater than 50'; this is a condition which is already meaningful but is not a combination of noncompound conditions.

Just as with goals, there is are meaningful operators _OR_ and _AND_ which can take two conditions X and Y and make a meaningful compound condition, such as

Q = X _OR_ Y

R = X _AN D_ Y

This is true if either or both of X and Y are compound MOSI conditions themselves, which means that MOSI conditions compounded by expressions such as ((X _OR_ Y) _AND_ Z) are also meaningful compound MOSI conditions.

In contrast with compound MOSI goals, which required some elaboration in order for us to have perfect clarity, I believe that the meaning and desired functionality of logically- compound MOSI conditions are obvious and require no further elaboration.

An illustrative example of a potentially useful compound MOSI condition constructed from meaningful potential pre-set conditions is:

(( 'likes dogs' _OR_ 'can tolerate dogs') _AND_ 'likes hiking')

SECTION 2.6 - Direct-messaging between users attending an Event

Direct-messaging of user A towards user B is defined as A indicating B to the app as the desired recipient of a message A provides to send to B, and the Provider sending it to B, that is making it available to B through the app, and B can see on the app that it has come from user A in the context of the Event.

Potentially if user A can see user B's Event Profile, user A can direct-message user B.

Generally user A will indicate to the app that user B is the desired recipient of the message by interacting with the app using user B's photograph as displayed on the app. However, in the Section whose title begins 'Cloaked users', we explain that there is potential enhanced functionality where an exception is made to this means of A indicating user B to the app.

At some Events, as will be discussed under the heading ECP ('Enhanced Control of Privacy'), a user can potentially block users not satisfying a criterion from direct-messaging them.

Potentially, if user A sends a direct-message to user B, user B can automatically direct- message back in reply to A, regardless of whether user B would have been otherwise authorized to direct-message A.

As is discussed, the Organizer potentially can turn direct-messaging between users off at a given Event. SECTION 2.7 - Certification of information

We said that MOSI conditions on B will generally have to be evaluated based on information B has provided to the Provider. (At least I believe this will be true in most modern democratic countries with data protection laws.) For security reasons, to help prove that they are not an imposter, potentially B can apply to have certain information certified to the Provider by an authority. (This certification process would presumably be carried out using in part the co-operation, automated (through the web app) or otherwise, between the Provider, the user seeking the certification of their information, and the authority in question).

The advantage of certification is as follows. Without certification, if A directs a MOSI towards B with MOSI condition 'is of Religion R', this essentially translates to 'has represented themselves as being of Religion R', since B is themselves providing the information to the Provider. With certification in place, A can potentially place a condition which has, in contrast, a meaning like 'is certified as being of Religion R by The United Churches of R' which presents A with some security from imposters.

MOSI conditions that a user commonly applies can potentially be named by a user through the app and stored for them by the Provider. Potentially, one of these is set by the user as the default MOSI condition for any MOSIs they make.

SECTION 2 8 - Fee collection - 'Partial notification of match'

Many users potentially have an established fee-paying relationship with the Provider. The Provider may send them notifications of matches, assuming the fees will be paid, or will charge them against advanced payments that the users have made. Potentially there are users whom the Provider does not, or does not yet, trust to pay a fee for a MOSI.

The following fee-collection model we shall call 'Partial notification of match'. It has its special uses when the user is not, or not yet, trusted by the Provider, but it also has uses even for trusted users.

In the 'Partial notification of match' scenario, on notifying the users of a match, some but not all information regarding the match is revealed. The Provider withholds some which is necessary to make the match information useful to the user. We shall say that the match is partially 'covered', and has not yet been fully 'uncovered'.

An example of this in operation is that the app informs the user that a match has been made but will not show with whom; the app withholds (covers) the photograph. The user has to pay before it is revealed with whom the match is and on what goals. After payment is fully received the related MOSIs are completed and all information which should be revealed as part of the MOSI service is uncovered.

Another model is that photographs are revealed but contact information withheld, until the match is paid for. A fee to uncover the match may potentially have to be paid by both parties before the match is uncovered. If one pays the fee and the other does not, it is prudent for the Provider to return the fee of the one who has paid.

Requiring both parties to pay a fee has advantages of reducing insincere expressions of interest, which is a noted problem in online dating.

SECTION 2 9 -- Timing of users making the MOSi or direct-messages, and when notifications are sent

We are intentionally nonspecific about when MOSIs are initiated, and when, if two users direct matching (successful) MOSIs towards each other, they are notified of their mutual interest. The reason is that many different possibilities are useful, and it can be potentially configured by the Provider or by the Organizer.

Similarly we are intentionally nonspecific about when users can direct-message each other.

Potentially, people can only make MOSIs towards each other at the Event itself, if the Organizer has configured it this way. If an event is explicitly for dating, the organizer might have a rule that people do not exchange contact information without using a MOSI, so that the organizer gets revenue from matching. The organizer might potentially give them a time to make their MOSIs at the end of the event.

If people remember each other's faces, and the system allows it, they can potentially direct MOSIs towards each other the next day, and this could be potentially be done on the website, not just the web app. Note that MOSIs are still useful if people can still contact each other through the app.

Similarly with the timing of the availability of direct-messaging.

SECTION 2.10 -- Search, Advanced Search. Matching Function

The concept of 'search' is a term of art in computer applications and indeed it is in common use now with concepts such as web search, Google search etc.

A search has a scope. In a Google search, it is all documents which Google has cached, and ideally the entire useful worldwide web.

The scope of a Search of interest to us is perhaps most usually the Event Profiles of all users attending an Event; more specifically though it is the subset of Event Profiles of users which the Organizer makes available to a given user to see. As discussed in the Common Scenario, an Organizer could potentially block men from seeing the Event Profiles of other men, and women women at a given Event.

Generally in a Search, a user is specifying potentially-weighted (or implicitly weighted) criteria which they want to be met by those who show up in the search results. These potentially-weighted criteria we will call a 'search term'. Our use of the term 'term' here is abstract: the search term is not necessarily text, though it is useful for us to express it as text in natural language so it can be understood in this description. A search term can be a combination of interactions with certain widgets in a certain context, which has a meaning which can be potentially expressed as a search term in a certain search language.

Usually when a search term is evaluated, there is not just a sense of whether or not there was a match of the profile to that term but how well it matched. This means that matches can be given a score: 0 could represent no match, and a higher number a better match.

The Provider potentially provides simple and more 'advanced' searches to be made available to users. Such a feature would be particularly useful at a large Event.

To show the scope and meaning of advanced search, it is useful to simply imagine a particular advanced search which a user wants, to be specifable by the user to the app in natural language. And potentially, the app can indeed allow the user to specify it in a natural language, and wherever we discuss availability of a feature in a natural language, this can potentially be combined with voice recognition so that the language does not have to be typed but merely spoken.

So, potentially all of the following are available by advanced search, whether by natural language interface or other interface:

'show me all people of Religion X'

'show me all people of Religion X what are over BO'.

'show me all people of political views Y, who like dogs'.

'show me all of the people of Religion X that are over 30, sorted by the distance they live from me, closest first'

A user can potentially name and save their Search terms. The app could potentially allow them to save a search result in a particular Event also.

SECTION 2.11 Matching preference sets

Potentially the app offers a user A the ability to define what we will call a 'matching preference set' and name and store such preference sets. These 'preference sets' are a set of information on A's likes or wants in a partner. However the app software is coded and these matching preference set defined, the software of the app can calculate a score for how good a match B is for user A, as seen from A's perspective, based only on A's matching preference set, and B's information; the software essentially defines a global matching function, F_APP_GLOBAL(,) function such that:

B's score as a match for A = F_APP_GLOBAL ( A's preference set, B'sjnformation )

That is, F_APP_GLOBAL(,) is a function taking two parameters, one is A's (matching) preference set, the other is B's information, and it produces a score indicating how good a match B is from A's perspective. It is useful if the 'scale' for the score is such that 0 represents absolute hopelessness (no chance of a match) and larger numbers are better, and that is the presumption we shall make in the following illustrations. To make these abstract ideas more concrete, we will take a particular example of A's defining a particular matching preferences set. Assume A creates a matching preferences set which A will call "LONG_TERM", and in part of the process of defining this matching preference set, A specified, 'absolutely must like dogs'. Since this is an 'absolutely must' it essentially disqualifies anyone who does not like dogs s being a match for A. The global matching function, when instantiated in the first argument with A's preferences, is a function only on the second argument which is B's information,

F_match_for_A_Long_Term ( B's information) = (is defined as) =

F_APP_GLOBAL(A's matching preferences set called "LONG_TERM", B's information) and in this case this one argument function on B's information should give a score of 0 if B's information indicates that B does not like dogs. If A alternatively specified 'good if they like dogs', rather than 'absolutely must like dogs', and the programming was done properly, this function F_match_for_A_Long_Term( ) should not score everyone who does not like dogs as 0, but it should give a higher score to those who like dogs than to those who do not.

Matching preferences are stored in the app however it stores them; the invention is oblivious to implementation in this regard. They are not necessarily distinct

programmatically from stored search terms.

Potentially, the app, using artificial intelligence, asks a user many questions and leads them to give the answers which constructs a good matching preferences set for that user. It could also ask them to rate pictures of people in order to determine what that user finds attractive.

A named or otherwise specified matching preference can potentially be used as the criteria of a search, that a search term or instruction corresponding to the following is meaningful in the app:

'Show me people sorted in order of my matching preferences set which I named

LONG_TERM'.

SECTION 2 12 - The 'Default AH Search'

In our discussion of 'search' the 'Default All Search' has a meaning 'all and the amount of the Event Profiles which the Provider makes available by default'. In other words we take the view that the Event Profiles that the Organizer makes available by default are the result of a search, the Default All Search, even if the user does not regard it as a Search.

The reason we are expressing this is to achieve the proper generality for other features discussed: specifically, Enhanced Control of Privacy, expressed later as applying to Searches, applies apply also to the Default All Search.

SECTION 2 13 - Presentation of Search Results

Just as web pages are the matching items of a web search, Event Profiles are the matching items of a Search in our context. Potentially, just like a web search, the app presents search summary results, in which, say, only a photograph is termed and highlighted matching information from the Event Profile which the app has been programmed to present as likely of interest to the searcher. Most helpfully, they are presented in the order of score for the search, best first.

However, we use search in a general enough sense that a any form of highlighting of everyone, say, who is 'of Religion R', is in fact the presentation of a search result of a search 'show people of Religion R'. In other words, the mere highlighting of a subset of

photographs of the Default All Search, could be regarded as expressing a search result: anything which presents information of the results of the search is a search result for our purposes.

SECTION 2 14 - Suggested users of interest

The app can potentially offer 'suggested users of interest'. This is nothing more than the app presenting results of a search which the app believes (is programmed to behave as if believing) that the user would like to make.

SECTION 2.15 · Reflexive search

A user A can potentially identify a named matching preferences set they have created as their standard matching preferences set for a particular MOSI goal, such as 'Long-term relationship'.

The following then would be a meaningful search term specified by user A, which we are showing in natural language to illustrate it:

'Show me all people, sorted in order of my standard matching preference set for Long-term relationship, best first'.

The idea of reflexive search is that the Provider (with the required permission) takes into account the other user's preferences for the same goal when ranking the match. In other words, not just how much A likes B ( as the Provider's app sees according to A's standard matching preference set for 'Long-term Relationship') but how much B likes A is similarly taken into account when scoring the search: it will do this by looking at the standard matching preference set created by B that B has associated with goal 'Long-term

Relationship', and checking it against A's information.

A reflexive search can have a meaning illustrated bu:

'Show me all people, sorted in order of how well we match each other for a long-term relationship (according to the standard preference sets we specified for long-term relationships), best first'.

We are not specific about how exactly the score of how good a match B is for A and how good a match A is for B, are combined. They should just be combined meaningfully and usefully. In some cases, a simple additive combination of scores might be useful, but this is not perfect and the question of how they are combined requires careful design.

The presentation of the results of a Reflexive Search can potentially be done without actually revealing to A a score to represent how much B actually likes A (according to B's matching preference set): the scores are not necessarily revealed, but the results sorted (or highlighted) in the order of best-first. Potentially, by default or if configured so by the Organizer, the app presents the results the Default Search in the order that they would appear in a particular Reflexive Search, in which the matching is for what the Organizer specified as the 'main goal' of the Event.

SECTION 2.16 - Transposition of search results to photograph, digital map or live camera view

We have discussed before the presentation of Search results. There is an additional way to present Search results which is particularly useful for Large Attendance Area Events, for example, a large vacation resort, a large beach, or a large fair. This way is only useful when the users in the Search results are providing their current GPS location to the app.

The principle is to show the search results in a way which makes it easy for the searcher to find where people are. This is done by transposing search results onto:

1. A to-scale physical map including at least the Attendance Area

2. A schematic map of the Attendance Area provided to the app by the Organizer

S. A photograph of the scene on front of them at the Attendance Area supplied by the user A

4. A live camera view presented by the user.

We will define a 'live camera view' as the video which a live camera of a smartphone displays of what the camera currently sees.

We do not believe it is particularly difficult for those skilled in the relevant arts to figure out how to carry out any of the above. But we shall discuss them briefly.

Assume user A has carried out a search and wants results transposed to one of the above 4. Assume user B is one of user A's search results.

The implementation of number 1 is the most obvious: the distributed application receives user B's current location from the app on B's smartphone, which receives it from the GPS system on B's smartphone. The distributed application displays a mark on a digital version of a to-scale map of the Attendance Area, and displays that along with desired search results representing B. (This could include a small profile picture of B if it fits.) We are not specific about what this information is. It could have a number of stars added or other highlighting if the match seems to be good. Such map is presented to A on A's smartphone.

Generally we make no implementation distinction regarding where the related digital calculations and image processing such as those needed to carry out what was described in the above paragraph are done in the distributed application: it could be on client or server.

Implementation of number 2 above is similar except that the distributed application must have a mapping of physical GPS locations to locations on the schematic map. This would be potentially provided by the Organizer. A schematic map would be useful, say, in a cruise ship or other situations where it is not necessarily desirable that the map is to scale.

Implementation of number B above is similar too except that the distributed application must have a mapping of physical GPS locations to locations on the photograph. Many techniques are available for creating this mapping (and are in use in programs such as Pokemon Go) and involve digital recognition of what is presented in the photograph. The GPS location of user A when they took the photograph is useful; it is also very useful to have a sense of which direction the camera is pointing, which may be available from the smartphone. This can sometimes be inferred if A has walked in a straight line for a certain distance.

Implementation of number 4 above is essentially the same as number 3, with the video being regarded as a sequence of still photographs.

If user B who is a search result for user A are to be presented on a photograph or live camera view of the searching user A, and in that view or photograph, some obstacle, such as a building, is obstructing user B from user A, the app can potentially behave in an enhanced way, like by displaying an arrow to go around the obstruction, and with the search result representing B on the photograph or live view in question, being placed at the tail of that arrow. This way it shows A how to find user B when user B is not in view.

SECTION 2 17 - Enhanced Control of Privacy (ECP)

We shall term 'Enhanced Control of Privacy' (ECP) an extended functionality of user A to limit user B's access to user A or to their specific information through the app, in which A places conditions which the Provider must determine, from user B's information, that user B satisfies, before user B is allowed to access user A by MOSI, direct-message, or to a specific element of user A's information.

The full set of such conditions A places we shall call A's ECP set (for a given Event).

Recall that user A's appearing in any Search of user B (including the All Search) is by definition a revelation of information about user A to user B.

It is easy to understand the scope and power of an ECP by imagining user A being able to specify, by natural language, their ECP set.

Conceive of user B being able to restrict their information by instructing the app through making sentences of the following form where X is a criterion specified by the user that the Provider has to determine that the other user is satisfying:

[/BEGIN model ECP conditions]

1. Only people satisfying criterion X can direct-message me

2. Only people satisfying criterion X can have a successful MOSI towards me at all

B. Only people satisfying criterion X can have a successful MOSI towards me with goal Y

4. Only people satisfying criterion X can see me at all in the results of a Search

5. Only people satisfying criterion X can see my data Y in the results of a Search

6. Only people satisfying criterion X can have my data Y taken into account by the

Provider in determining if I pass a search filter, or where I rank in a search result.

7. Only people satisfying criterion X can have my data Y taken into account in

determining whether I pass a MOSI Condition of a MOSI they direct towards me. Each line of the 7 above model ECP conditions should be read entirely as if standing alone as regards the meanings of X and Y: in other words, X is not intended to be constrained to the same in any two lines above, and neither is Y.

[/END model ECP conditions]

A 'successful MOSI' is one in which MOSI notification is done. Note that condition 3 does not inhibit user A's directing a MOSI towards B on the interface of the app; it inhibits its being regarded as successful. The desired functionality is allowing the MOSI to be directed, but essentially quietly cancelling it if user A does not satisfy B's stated criterion X; if another user is blocked from making a MOSI towards B, this potentially reveals information about B, namely that B has somehow blocked a MOSI. This is another kind of condition which has to be satisfied before a MOSI is successful, but is not a 'MOSI Condition' as we defined it; a MOSI Condition is a condition that an initiator of a MOSI places on the target, which if not satisfied, the MOSI will not be successful. In this case, in their ECP settings, a user is quietly blocking all MOSIs other users send to them unless that user satisfies criterion X. The functionality indicated in Sample ECP Condition 3 is related to Conditional MOSIs, and works in a related way, but is specified in a different way.

Criterion X could be 'is over 50' ; 'is of Certified of Religion R by ...', etc.

Note number 4 above, 'Only people satisfying criterion X can see me at all in the results of a Search'. If user B cannot be seen in the results of a Search by user A, then user A cannot see user B on the app. We shall say then that user B is 'cloaked' (to user A) at the Event. (Recall that we regard the profiles which are displayed by default as merely the 'Default All Search'). If user B is cloaked to user A, user A does not know, from the app, that user B is even registered. And since user A interacts with the app generally with user B's photograph to send MOSIs and direct messages, unless there is special provision, user A has no way to direct a MOSI or direct a direct-message towards user B if user B is cloaked to user A.

However, we show in a later section, a very useful variation of the invention, in which user A can indeed direct a MOSI or send a direct-Message towards user B even if user B is cloaked to user A at a given Event.

In anything which the app supports, it has to uphold all ECP settings which it has allowed to users to set up. This has certain implications, some of which we touched on already in Conditional MOSIs. If user A places criterion X on user B, limiting user B's ability to take a certain successful action towards A for example by MOSI or direct-message, then, if the Provider allows such an action by B towards A to be successful, it reveals to user A that user B satisfies criterion X. It therefore reveals this information about user B to user A by allowing that action to be successful. Therefore, privacy preservation demands that an additional condition is placed on the success of that action, and that is that user B permits, under the circumstances, that it be revealed to user A that user B satisfies criterion X. SECTION 2 18 - Organizer limits available information, and limits ECP itself

The explanation of the nature of ECP was presented to show the power of variation in this invention. This does not mean at all that every Organizer will want to offer the full power of ECP to users attending any given Event.

For example, while a user might be happy remaining cloaked to certain users, this might be unacceptable to an Organizer of a particular Event. So potentially the Organizer makes rules about what must be available to other users at a given Event, and identifies them to the app. The Organizer in some embodiments could potentially do this through natural language.

If a user has ECP settings for an Event which are too restrictive and hide what an Organizer requires to be revealed at an Event, the app would potentially block that user's registering for the event, and even prompt them for what ECP settings they need to change for the Event in order to register for it.

SECTION 2 19 - Agreement for Mutual Accessibility of Information

First note that the scope of user A's 'information' which user A can limit the accessibility of through ECP potentially includes the information of user A's own ECP settings.

Assume that A has made an ECP setting which we can express in words as:

'Reveal that I am of status X, but only to other people of status X'.

Status X could be, for example 'is of Religion R'. Assume that user B is of status X. This setting determines that someone who represents themselves as being of Religion R can see that A is of Religion R. User A might not want prying from imposters who are not really of Religion R but are representing themselves as of Religion R. If, alternatively, 'status X' represents 'is certified as being of Religion R', then this privacy setting determines that only someone who is certified as being of Religion R can see that A is of Religion R.

A has revealed their information more selectively, but is still not immune from what they would regard as a form of prying, unless B has a similar privacy setting. B, while certified of Religion R, could potentially withhold their Religion R status entirely from A but still see that A is certified of Religion R. There is informational asymmetry here, and User A might not like this, and might only want to reveal their status of being of Religion R to others who are not just of Religion R, and who reveal to A that they are of Religion R.

There is a solution, and it is a privacy condition looks at the privacy settings of the other person and requires them to be satisfied before information is released. Expressed in words in natural language, the desired ECP setting is:

'The Provider is authorized to reveal the information that I am of status X, but only to other people also of status X, and only if their privacy settings are such that they allow the revealing to me that they are of status X'.

We can make a shorthand for this kind of ECP and call it 'mutual visibility' of status X: and with our language defined this way, the ECP is expressed as: Ί agree to mutual visibility of my being of status X'

The power of a potential ECP setting of 'mutual visibility' of information is shown.

SECTION 2 20 - Other uses of Certification

We discussed certification of information in the context of conditional MOSIs.

Certified information is a qualification of information, but it is just another kind of information. Therefore, it is potentially specified in a search as well, or any other conditions, like in ECP. Therefore 'show me all people of Religion R', and 'show me all people certified of Religion R by the United Church of R', bring potentially different results.

Potentially an Organizer though can set criteria for people who are allowed to register for an Event, and such criteria could be on certified information. Therefore, for example, and Organizer could specify that only people who are certified as being of Religion R by the United Church of R, can register for an Event. Similarly they can potentially narrow to whom it is advertised.

SECTION 2.21 - Event Checkin using barcode

We shall use the term 'barcode' to mean any kind of barcode, whether ID or 2D.

There are two distinct ways in which barcodes can potentially be used to facilitate the check-in of a user at an event. Case 1, is with a barcode identifying the Event (to the app of a user intending to check in) and another, Case 2, is with a barcode which identifies a user (to the app of a user who is accepting their checkin, generally another user who is checked in or the Organizer).

The meaning of 'a barcode identifying the Event to the app' is a barcode which can be scanned by the app, and the scanned barcode information used by the app to identify the Event. Similarly for the meaning of 'a barcode identifying a user to the app'.

In Case 1, a barcode, which can identify the event to the app, is potentially constructed by the app and is made available by the Organizer at the Event; such a barcode can potentially be exposed prominently by the organizer at the place of the Event; it could potentially be printed on paper by the Organizer, and left in a prominent place or places at the Event location; alternatively, it could be displayed on a screen or screens at the Event location; alternatively, the Organizer enables some or all users already checked-in to display the barcode for the event on their app.

In Case 1, a user, using the app, scans the barcode and this information is used in the web app to indicate that the user wishes to check-in to that specific Event.

In Case 2, a user A requests the app to generate and display a barcode, on their own smartphone, which identifies them to the app of someone else who scans it. Potentially in some cases, if the app is handling billing for the Event, the app would require the user A to pay in advance for the Event before such a barcode can be displayed by the user. Then, when that user goes to the Event, they go to some user B who is authorized by the

Organizer to 'check in' other users at the Event. B, through the app, scans user A's barcode on the display of user A's smartphone, which user A presents to user B. The app uses this scanned information to check user A into the Event.

Potentially, if the Organizer so configures the Event, any checked-in user can check another user in this way.

Case 1 and Case 2 have respective advantages. Case 1 allows a user to check in

independently, but it has a disadvantage of requiring a barcode to be displayed

prominently. Case 2 does not allow a user to check in independently, which is a

disadvantage, but requiring user interaction is also a potential advantage also. Case 2 has the additional advantage of requiring no prominent display of barcode.

SECTION 2.22 - Names, Nicknames ···· the indication of another user to the app, w i t h o u t p h of o g r a p h s

In preferred embodiments it would be assumed that the user A, indicating another user B to the app, through the interface, for the purpose of doing a MOSI for example, does this by interacting in some way with the profile photograph of B that the app is displaying on user A's smartphone. In these circumstances, user A is actually using their own human, biological, face-recognition capabilities, in conjunction with the profile photograph. The app 'knows' that this is a photograph of user B, because it placed it there as the profile photograph of user B.

However, a user A's indication of a user B, is potentially not done this way in all

embodiments.

One simple embodiment in which this is possible is one in which a user withholds their photograph from 'Event Profile', but they allow their name to be accessible; those who attend the Event would have to learn their name in order to be able to direct a MOSI towards them or direct-Message them.

Another possibility is that the Organizer presents some 'means to recognize' that the user B which user A meets, is to be indicated to the app by user A in a certain way at the event.

The Organizer could provide this capability to users who do not want to provide a photograph.

As an example, user B could choose their 'nickname' for the event, either one of their own making, or one from a selected set which the Organizer offers for the event, in the process of the Organizer's configuring the Event in the app. Potentially the user must make and wear their own name-tag on which their nickname is written clearly, which the organizer does or potentially does not check at the door for being correct; or potentially the Organizer gives the user the right name tag. Then, it would be through the nicknames written on the name tags, that a user indicates another user to the app, in the process of directing a MOSI towards that user. SECTION 2 23 - Events not necessarily limited in place and time.

We have presented many variations on the invention. We will now present some special variations.

The word 'Event' should not be confined to our common-language sense of event; anything configured in the app as an Event is an Event.

An Event, for our purposes, can have any Attendance Area, and in principle, that could be an entire nation, a group of nations, or indeed the entire planet earth.

An Event does not have to be short. Most usual Events are probably just a few hours in a day, or one eventing, but for our purposes, an Event as configured in the distributed application, could last a long time, and does not have to have an ending time. Potentially for example, a university could set up an Event with their entire Campus as the Attendance Area, and lasting a whole Semester, or even a whole year, or continuously. Potentially a starting time is set for an event on the app, but the ending time is specified by the Organizer when the Organizer chooses to specify it to the app, possibly just at the end.

The use of an Event with a large Attendance Area, such as a city or nation, has interesting applications in conjunction with the feature of being able to send MOSIs to cloaked users. People could direct MOSI's towards each other using photographs of the other, and hope that the match can be found, as discussed in the section on 'cloaked users'; this could be done over the whole city or nation.

Note also that the Provider and Organizer are not necessarily distinct person. While we envision usually the Provider allowing various Organizers to use their website and schedule Events, potentially in some cases the Provider gives themselves the sole Organizer role.

Note that such a Provider could potentially provide only one single continuous event if they wanted.

SECTION 2.24 - Cloaked users, and MOSI or direct-message directed, using

photograph,

towards user who is ^'cloaked'

As already explained, B is regarded as cloaked to A if A cannot see B on any of the Searches A carries out, or even on the Default All Search. In other words, the app does not represent B to A on A's smartphone as attending the Event.

B is potentially cloaked to A by an ECP setting which B made, and which the Organizer's settings for the Event accepted.

User A may or may not also be cloaked to user B. First we'll take the case when User A is not cloaked to user B.

There are various possible reasons why a user B might wish to remain cloaked. Such a user could be very private, for example. But user B might still be interested in participating in MOSIs (or direct-messages) during or after the Event, without revealing, at least to all users at the Event that they are registered users attending the Event. In other words they only reveal the fact that they are even registered, in successful MOSIs.

Suppose A has a strong affinity for B, and takes a guess that B is in fact a cloaked user.

Potentially the system supports A's directing a MOSI towards B. However, A is not enabled to indicate B to the app in the normal way, because the app is presenting no photograph of A to B, for B to interact with.

So, how does A indicate a user to the app, for which the user is not presenting a

photograph or other identifying information? Potentially, (and this is an addition to the invention), A simply supplies, or indicates, a photograph of B to the app, essentially saying 'this is the user to direct my MOSI to'. Note that this is not a photograph which the app has presented to user A as representing a user B who is checked in.

To do this, A must have access to a digital photograph of B. If the app supports it, potentially the app may access the camera of the smartphone, and user A may take a picture and identify on the picture which face represents B's face, therefore substantially presenting to the app, a digital photograph of B. (There is plenty of prior art which can highlight individual faces on images, with for example, squares and rectangles. If A were to select one of these squares, A is substantially supplying the app with a photograph of B.) Alternatively, A takes a photograph and uploads it to the app, which separates out the faces and A selects the face of B. Alternatively, the Organizer and publishes a single photo of everyone who attended the entire event. A can 'upload' this photo to the app in the same way, and indicate B in the same way.

Potentially if the app supports it, if an Organizer, or even potentially another person if they have permissions, uploads a photograph to the app afterwards and associates it with the Event (such as by 'posting' it on a page or post associated with the Event), functionality can be present which highlights individual faces on that photograph, and a user, provided registered as attending the Event, can direct a MOSI towards one of these photographs. In the case mentioned in this paragraph, the context of the particular Event is implicit, and will not have to be specified by the user.

The photograph which A uses to indicate B we will term the 'user-supplied photograph'. It is a photograph which A substantially supplies to the app as representing B. (Note that this term the 'user-supplied' photograph is intended to cover also the case when that photograph is already on the app, such as if an Organizer has posted a photograph of everyone to an Event page.)

The MOSI is processed by the app in the normal way, except that there are important additional steps to be carried out by the app (the Provider's service). When the app receives the instruction from A to send a MOSI to a user identified by a supplied photograph in the context of a particular Event, the distributed application uses facial recognition technology to match this supplied photograph with the Event Profile Information (and/or additional photographs the app has of users if the app is allowed to use them this way). To search for a match, the app need only search in the Profile photographs it has of users attending the Event. For a MOSI, it need only look through the photographs of users at the Event who have made MOSIs themselves.

Potentially, and this has value for very large Attendance Area Events, and even Unlimited Attendance Area Events, the GPS location of both users is additionally used to narrow down the set of photographs which the app has to look through.

Now, supposing that the app has found a solid match, in its own profile photograph or photographs of user B, for the photograph that A has supplied to indicate B. If B has not made a matching MOSI towards A, the MOSI can at this point be cancelled. If B has indeed made a matching MOSI towards A, an additional 'supplied photograph authentication' step is possible and perhaps prudent, and that is that B is asked first by the app to confirm that the supplied photograph is indeed a photograph of them. If it is confirmed, then MOSI notifications occur.

The case where both users are cloaked is easy to infer from the above: user B also supplies a photograph of user A, also it is matched by the app with the app's photographs of A; if such photograph match is also successful then the MOSIs are checked to match; and if they match then a potential prudent last step is supplied photograph authentication, to ask them both if the supplied photographs are respectively of each of them, before MOSI notification occurs.

The use of a supplied photograph as a means to indicate another user as a target of a Direct Message works in a similar way.

In fact there is here presented a general way here to indicate a user to the app in the context of an Event; to supply a photograph, which the app matches with photographs it has of users attending the Event.

The use of supplied photographs to indicate target users for MOSIs or direct messaging in Unlimited Attendance Area Events (and this applies even if they are unlimited in time) is not substantially different. However, the app may potentially narrow the prospective target users over whose profile photographs, to users who were at the same place and same time that the initiating user was when the photograph was taken, as determined by GPS readings: indeed, such narrowing may be desirable to the users for security reasons; even while cloaked, they wish to take MOSIs or direct messages from people whom they know were close to them.

Potentially in some cases of long-term, large Attendance Area Events, the app can provide an additional service. This might be useful in a higher-trust environment, such as at a University Campus, where the only people who can register as attending the Event are students, faculty or administrators. This service is to receive a photograph from a user A, and/or the user's identification of a particular face on the photograph, and match it with a profile photograph of another user at the Event, user B, and present that profile photograph to the user A on the app, which user A can now use to direct MOSIs or direct-messages towards that person. The potential functionality described with supplied digital photographs can of course potentially also be supported with live camera view instead of photograph.

SECTION 2.25 - Integrated Games at Events

The Common Scenario presents great technological opportunity for what we will call Integrated Games to be played at the Event. Most advantageously, all users at the Event are authenticated to the Provider's app as users, and they have means to identify each other to the app by photographs which the app has. The Provider's app is in a position to allow them to play games together using their smartphones. Any board game could potentially be provided by the app. None of the accoutrements of a physical board game are required.

Such games which the user's can play at the Event, at their or the Organizer's instigation through the app, we will call Integrated Games. The advantage of Integrated Games over non-integrated games is mainly ease of set-up, and security of data, emerging from the special circumstances explained in the last paragraph.

Consider the game of monopoly, which has a board and there are tokens for users which historically included a ship and a boot. So, one user was represented by a ship and another a boot. In an integrated game, it is natural to represent the user by their profile picture (or, for fun, since there is plenty of technology for taking a digital photograph of a face and making a cartoon version of the photograph, some cartoon version of their profile picture).

Assume the Organizer has initiated a game, and all users are notified on their app, and a user activates a notification to play that game. A panel appears on this user's app which we will call the 'game panel'. The 'game board' for an Integrated board-game is simply part of the game panel which is a shared display between all users playing that game. The rest of the game panel we can call the user's private panel. The user's private panel corresponds to the user's 'hand' in card games, or the scrabble tokens they own in scrabble, etc. Potentially a user can interact with the interface to maximize the game board in the game panel, that is, make it take up most or all of the game panel.

A user could potentially sign in (as the same user) on more than one device they bring, potentially a tablet or laptop as well as usual their smartphone. They can maximize the game panel on the tablet or laptop, and place it down on the table screen up, for all to see as the board. The system could also provide for the game board to be cast by a user to a television using Bluetooth or some other system. Then the users who can see the game board on the laptop or tablet screen on the table can minimize the game board on their game panel (which is equivalent to maximizing their private panel). Notice that for a large table, more than one such tablet, representing the same board, is useful. The users see the private panels on their smartphones, and there, see their hand if playing cards, or their scrabble tokens if playing scrabble. On the table is the tablet or laptop whose screen shows the game board, which represents the board in the case of a board game, or the cards played on the table in the case of a card game.

In some games, users can potentially interact with the board on the tablet on the table. There is no need for what we could call a game administrator - the app carries that out. A game administrator includes dealers in card games, and 'the bank' in monopoly, and so on. To deal a pack of cards to attending users, the app just electronically deals the cards into people's respective private panels. Scoring is also done entirely by the app.

This system is useful for board games as we understand them, but also for many simple social games. Many simple games like charades can be played. So can quiz games.

Potentially Integrated Games allow people to divide easily into teams. It could divide them randomly if the users like, or Team A could go to the right half of the room and Team B to the left, and then everyone on Team A selects Ί am in Team A' on the app, and similarly for Team B; or the Organizer or authorized user drags and drops profile pictures to the right or left of their screen to put people in Team A or Team B, etc.

There can potentially be game-specific private-messaging, for use as part of the game. Potentially the entire group at the Event is a team, and can play a remote team in the game.

SECTION 2 26 - Integrated Games !l - varying levels of Integration

The app can be written in such a way that games are extremely 'light' in the app; in fact, the client app represents the equivalent of a sort of pure-terminal for the game: the client app is only receiving instructions from the server of what to display in the game panel; and it is only sending information about what part of the game panel the user has interacted with, by touching etc.

This way, since so much resources are potentially available on the server or servers, there is essentially no practical limit placed on the servers regarding how many games are made available to the app.

The Provider can allow third parties (parties other than the Provider and Oganizer) to develop such games, by developing and providing an API and development kit.

It is also possible to integrate, in a somewhat different way, third-party games, which are entirely on web apps hosted on separate servers by third parties. As an example, suppose there is a third-party web app game called 'JollyMonsters'. Assume that JollyMonsters.com is a front end to the web app JollyMonsters; we will use JollyMonsters.com essentially as a label for the Jolly Monsters servers. Users at the Event can play JollyMonsters in an integrated way, but they will have to install and run it on their app.

Now, the Provider's app can give Monsters.com the IP address of users; and it can tell JollyMonsters.com that users are to be associated as participating in the same game at JollyMonsters, by associating their IP addresses as playing a game in a group to Jolly Monsters. In a substantial sense, the Provider can 'sign in' users into JollyMonsters to play a game, and associate all of these users to the same game, by communicating with

JollyMonsters.com and by specifying users only by their IP address.

If it is acceptable from a privacy standpoing, the Provider can provide photographs of the users and associate them with their IP addresses to JollyMonsters.com, and now photographs of users can be used to identify other users in the Jolly Monsters game that the users at the Event are playing.

If it is not acceptable that photographs of the users are shared by the Provider with

JollyMonsters.com, there is still a way that photographs of other users at the Event can be seen and used by users in the Jolly Monsters app, provided the Operating System on the smartphone permits it, all without JollyMonsters.com having access to these photographs. This is potentially done in the following way: JollyMonsters.com can 'instruct' the servers of the Provider's website to present the photograph of a given user, which JollyMonsters.com only knows the IP address of, but which the Provider has the photograph of, on a chosen part of the display of their own app, on a target smartphone or other client identified by IP address; if the operating system of the smartphone allows it, the Provider's app could display the desired photograph on the desired part of the display of the Jolly Monsters app on the desired client.

Potentially throughout an entire game of Jolly Monsters, run on the Jolly Monsters web apps of all users attending the Event, in which photographs of other users are displayed and potentially interacted with, JollyMonsters.com has no access to those photographs, and in fact, only identifies users and clients by IP address and no more.

SECTION 2.27 - integrated Games II I - control by the Organizer

While the Provider may present a very large number of games which can be played through the app, the Organizer can potentially narrow down the games which can be played at their Event to a subset of their choice.

The Organizer can potentially control who initiates the games at the Event, and can decide, for example, that either only the Organizer, a user or number of users authorized by the Organizer, or all users can play given games.

SECTION 2 28 - More on Siiper-Orgsnizers and Branding

The Provider can potentially offer a super-Organizer the service of providing a web front- end for the super-Organizer. For example, for the hypothetical super-Organizer discussed in the Common Scenario who uses the brand 'Debby's Dates', the Provider can offer them a front end with 'Debby's Dates' own URL, for example 'DebbysDates.com'. In this case, the DebbysDates.com is a separate front-end website to the Provider's distributed application. In a similar vein to offering a customized web front-end, the Provider can potentially offer DebbysDates a customized web app, Debbys Dates Web App. Such a web app would be a front end of the Provider's distributed application.

Potentially the sub-Organizers of Debby's dates would be revenue-sharing with Debbies Dates for Events they organize under Debby's Dates brand, and this revenue-sharing is potentially implemented automatically by the Provider.

Throughout the description, any respect in which an Organizer can restrict a functionality which might be made available to users at their Event, a super-Organizer can potentially restrict such functionality to Organizers at Events running under the super-Organizers brand. For example, when we said that Organizers could potentially limit the particular kinds of Integrated Games which can be played at an Event, potentially it is similarly useful that a super-Organizer limits the games which a given Organizer can allow to be played at Events run under the super-Organizer's brand. This gives the super-Organizer control of the character of Events run under their own brand.

SECTION 2 29 - MOS1 cancellation

The app potentially, and certainly usefully, offers the user the functionality of cancelling a MOSI that they have directed towards another user. This will obviously be no longer useful if the MOSI has been successful and notifications have occurred.

SECTION 2.30 - Registering and attending ... not necessarily distinct

Normally registering, and indicating that one is actually attending at this point in time, are distinct. But they could potentially be one and the same.

SECTION 2.31 -- Automatic check-in and fee-territory division and related billing

It has been mentioned that potentially the app, using a user's location, automatically checks a user into an event for which the user is registered when the user enters the Attendance Area for the Event. Potentially an Organizer, interacting with the app, defines the

Attendance Area for an Event by specifying its boundary on a digital map on a computer, thereby making the precise area of the event known to the app.

Potentially a user checks out of an event simply by walking out of the Attendance Area of the Event, provided that the app can get their current location from their smartphone. Similarly, the user could check into another Event (as perceived by the app) by walking into its area.

Consider a large resort. Consider its being divided into different zones belonging to different businesses - for example, the golf course, a swimming pool are, and so on. The owner of the large resort is potentially a Provider, or alternatively, a super-Organizer, and the owners of the businesses, sub-Organizers. When a user walks out of the golf course, and into the swimming-pool area, they potentially have in our terms checked out of one Event (at the golf-course - possibly not limited in time) and checked into one at the swimming pool.

While the user is at the golf course, any MOSIs they do there will be under the terms of the golf-course Organizer, and the fee model and related fees configured by the golf course Organizer on the app, and fees will go to the golf course, all this being done automatically by the Provider, which is potentially revenue-sharing with the golf-course.

Similarly while the user is at the swimming pool, all MOSIs are under the swimming-pool Organizer's terms and fees go to the Swimming pool.

In a scenario such as the one described, an Organizer (sub- or super-) can potentially disable use of their MOSI service unless a user has enabled access by the app to the user's position. More than one Event can potentially be going on in one place. A user can potentially be checked into more than one. Potentially, there could be, for example, one event for seniors at a place, and a separate one for younger people, at the same time.

SECTION 2.32 - Use of MOSIs not confined to 'relationship', but any shared activity

On a cruise ship, hotel, or resort, the Organizer could potentially configure the Event so that someone could even ask someone to dance, or, for example, ask someone to play tennis, using the MOSI system, and smartphones.

MOSIs are useful in any circumstances where approach and making a proposition is awkward, and/or the possibility of rejection may be awkward.

MOSI's could usefully sometimes be disabled between all users at an Event, except to and from the Event Organizer, and/or a selected group of users. These have use when the proposed relationship is not in any way amorous at all. For example, there are some 'open house' events in co-operative living situations where people potentially wishing to live there visit the house and meet those who live there. In such a case, the Organizer represents those already living in the house, and use of a MOSI can be directed from the Organizer towards users the Organizer wants to consider living with, and in the other direction as well, from the users who want to live there and the Organizer; but not between users. The 'goal' could be 'let us talk more, we can consider living together'.

Similarly, at a job fair, between potential employers and potential employees.

SECTION 2.33 - Organizer can turn off direct-messaging at their meetings

Potentially, to increase revenue from MOSIs at a given meeting, in an embodiment in which users at an event can normally direct-message each other through the app, the Organizer can, through the app, block users at the event to direct-message each other. (More strictly speaking, they would not be able to use the photographs that they see on the app of other people at the event as a means to identify those people for making messages; they would presumably still be able to direct message these people if they had alternative means to message them, such as that they were already social-media friends on the Provider's platform.)

SECTION 2.34 -Whether the app places people in contact

It is presumed that some means is provided to keep people in contact if they have directed matching MOSIs towards each other. It is not necessary for us to claim it, because the system would not be useful unless such means exist.

If they are being placed in communication by the Provider, this does not necessarily mean revealing each other's identity to each other; this could entail, for example, only allowing each other to message each other.

Placing two users in communication could entail allowing them to continue direct- messaging each other beyond a time when direct-messaging normally expires; or enabling it if it is not enabled between those two users. SECTION 2.35 - Application to Virtual Events or no Events

Many and even most of the features mentioned here can potentially apply to virtual Events or meetings (meaning essentially meetings 'online', in which one user experiences another through video, audio, or even just text interactions. None of the features such as Search, ECP, Conditional MOSIs and Compound MOSIs should be construed as applying only to in- person Events because they can apply to virtual Events as well, or even out of the context of Events.

SECTION 3 - Transition to the Cla ms

The word 'process' when appearing alone in the claims without qualification, is intended to mean "process" as the common legal term in patent applications.

When appearing alone in this way it is not intended to be term of art in computing in general and operating systems in particular, in the phrase 'computing process'; if that term of art meaning is intended, the term "computing process" will be used.

As a common term of art which we will follow, a computing process is an instance of a computer program that is being executed.

A Distributed application is defined as follows: A distributed applications is an application or software, a single running instance of which runs on multiple computers within a network.

We define a distributed computing process as an instance of a distributed application which is being executed. Note that a distributed computing process is the direct analog of a computing process, but distributed over more than one computer in a network, and usually over several.

For programs which are run on a single computer, there are usually, in fact almost always, many instances of processes running that application around the world; this is certainly true of all commodity software.

We use the word 'instance' of a distributed application; note that there may in fact be only one such instance in the world in many cases. In contrast with applications run on a single computer, there are many significant cases of distributed applications of which there are only one running instance; the program is entirely customized for that one instance, which may have, say, a particular website front-end, and no other instance of that particular distributed application running anywhere else in the world. Therefore, sometimes, a distributed application corresponds one-to-one to a particular distributed computing process; and yet there is a distinction between the meaning of the distributed application and the distributed computing process running it even though they correspond one-to-one; the distributed computing process is running on a particular set of data, and is associated with that particular set of data while it is running. The distributed application is defined only by its software.

In what was discussed here, ??????? the CPIS is essentially a particular distributed computing process. The CPISP is the entity which owns/runs/controls the CPIS. The CPIS will be running on software, which software, taken in aggregate on both clients and servers, corresponds to a distributed application. If no other CPISP is running the same distributed application software in the world, then the CPIS is the only instance of the particular distributed application in question.

The interface of a (distributed) computing process will be regarded as the interface instance of the (distributed) application it is running. For example, the Microsoft Word application has a particular windows interface: the interface of a computing process running the Microsoft Word application will be substantially a particular window which represents the interface of that instance of the application, on the computer it is running on.

We shall use the term 'instruct' as follows: when a user interacts with the (distributed) computing process through its interface in a way in which the user is non-passive and is behaving in a way in which a knowing user who knows the interface would behave in order to make the (distributed) application behave in a certain way, the user is regarded as instructing the (distributed) computing process, and to behave in that particular way; a user A is regarded as instructing the (distributed) computing process to behave in the way that a knowing user B, who knows uses the interface properly, would expect it to behave, if the knowing user B behaved as user A behaved.

Therefore, for example, to click on the 'X' on the top right-hand corner of windows on the current Windows system is to 'instruct' the related computing process to terminate; to click on the square to the left is to instruct it to maximize its window. If a user intends to maximize the window, but either by clumsiness or ignorance clicks on the 'X', they are still for our purposes regarded as instructing the computing process to terminate; the instruction given is regarded as corresponding to the intention of a knowing user, not an unknowing one.

An instruction has 'semantics', which means 'meaning'; this is a term of art from which we are in no way departing. The meaning, or semantics, of the instruction of clicking on the 'X' on the Windows window, is that it is to terminate.

We may use the term instruct in a way such as 'instructs the computing process that something is so', which is equivalent to the commanding the computing process, to note in memory, that something is so; which in turn means to make a record in memory that something is so; this is the same meaning as telling the computing process that something is so. We use 'express' in a way so that equivalent in meaning to 'instructs the computing process that something is so' is 'expresses to the computing process that something is so'. Following our definition of the word 'instruct' the phrase 'to issue an instruction' may be used, in the obvious way, with the instruction in question being defined in that it means exactly 'do whatever was instructed in this case'.

When a user has a mobile computing device which has GPS or similar location system, and an application on the computing device is reading the user's location, we take the view that the user's moving around carrying the mobile computing device is an interaction with the applications interface, though it may be one which is ignored and negligible; therefore it is an interaction with the interface but it may not be consciously recognized as an instruction by the user. Anything the user does which the application reads, and potentially acts upon, is an interaction of the user with the application's interface.

A distributed application can potentially have a natural-language interface, and the natural language could be entered by text or voice.

When a user is instructing an application, the user is in fact issuing a command to the application in what we call a language; not necessarily a natural or spoken language and certainly not what is known as a language to the layman; but a language nonetheless. For a user using a windows-like interface, the user is instructing the application in a kind of sign- language; the 'utterances' are not verbal, but they are utterances in our sense (note that defamation and libel law in certain countries similarly uses the word 'utter' in a similar general way which is by no means confined to spoken or natural language).

The following is a common definition of 'language':

language is the method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.

Ours is a little broader, but consistent with abstract and academic use:

language is the method of human communication, either spoken or written or otherwise uttered, consisting of the use of words or other utterances in a structured and conventional way.

Instructions are made by making utterances in the language of the interface.

Our use of the word 'indicate' should be obvious, namely, to point out, or to show.

We believe the term 'register with' to be a term of art, and common usage also: the meaning of 'a first user registers with the distributed computing process, that ...<such and such is so>' means that the distributed computing process is given the information by the first user that <such and such is so>, and, implicitly in the context, expected to record and make use of it. There is no formal distinction between registering information with the distributed computing process and merely giving it that information, but there is a tendency for the word register to be used when the information has applicability over a nontrivial time period. This may be obvious, but of course a user 'registering something with the distributed computing process' is implicitly doing it through its interface, as there is no other option for doing it.

It may be useful to clarify some possible claim language.

I could, for example claim Hypothetical Claim X below:

Hypothetical Claim X: A process to facilitate socializing and game-playing, carried out by a distributed computing process, characterized in that: a first user registers with the distributed computing process, that the first user is organizing a particular social event entailing in-person meetings; the distributed computing process provides an interface so that a second user, not necessarily distinct from the first user, recorded by the distributed computing process as attending the social event registered by the first user, may start a computer game served by the distributed computing process; the distributed computing process either allows all users who are recorded by it as attending the social event to enter the game as players, or allows a subset, determined by the second user, of such users to enter the computer game as players;

The above claim is of course in the context of this description and refers to the game-playing embodiment described in it. Potentially, and in the near future likely most usually, the distributed computing process is running in the 'web server' as server, and the web apps on the smart phones of the users of the event, as clients.

Notice the phrase 'recorded by the distributed computing process as attending the social event'. In informal language (and arguably as a term of art) programmers will say the process or application knows that the user is attending the event; this means that the process has in its memory information which indicates that the user is attending the event. This is the same as saying that the user is virtually attending the event. Note that in this case by saying that they are virtually attending the event, this is not in any way meant to imply or suggest that they are not also physically attending the event; in fact, in this case they are expected to be physically attending it also.

Notice the phrase 'game served by the distributed computing process'. I expect that this is clear to someone skilled in the art who has read the description in its entirety. But to clarify in case of possible ambiguity, the only intended meaning in saying this is that the game is 'run in the distributed computing process'. That is, the execution of the game is part of the running of the distributed computing process as a whole. The distributed computing process offers many 'services' and the game is one of them, justifying the use of the general-purpose phrase 'served'. I believe it goes without saying to a person skilled in the art that the user (player's) interface in the game is in their client devices, which is therefore their mobile computing devices in the usual case. A Webserver is potentially the 'server' for the game, but recall that in embodiments of the invention we are not confined to a distributed computing process which is in a client-server arrangement, so a game substantially run in a peer-to-peer arrangement of the user's own clients is a potential embodiment of the invention.

Claims

I claim :

Claim 1: A process to facilitate socializing and game-playing, carried out by a distributed com puting process, characterized in that: a first user registers with the distributed computing process, that the first user is organizing a particular social event entailing in-person meetings; the distributed computing process provides an interface so that a second user, not necessarily distinct from the first user, recorded by the distributed computing process as attending the social event registered by the first user, may start a com puter game served by the distributed computing process; the distributed computing process either allows all users who are recorded by it as attending the social event to enter the game as players, or allows a subset, determined by the second user, of such users to enter the computer game as players;

Claim 2: The process of Claim 1, further characterized in that: the distributed computing process provides an interface such that a third user recorded by the distributed computing process as attending the social event registered by the first user is given the option to join the computer game started by the second user.

Claim 3: A process to facilitate socializing and game-playing, carried out by a distributed com puting process, characterized in that: a first user registers with the distributed computing process, that the first user is organizing a particular social event entailing in-person meetings; the distributed computing process provides an interface so that a second user, not necessarily distinct from the first user, recorded by the distributed computing process as attending the social event registered by the first user, may join a game served by the distributed computing process which is being played by remote users not recorded by the distributed computing process as attending the social event; the distributed computing process either allows all users who are recorded by it as attending the social event to enter the game as players on the same team of the second user, or allows a subset, determined by the second user, of such users to enter the computer game as players on the same team as the first user; Claim 4: The process of Claim 3, further characterized in that: the distributed computing process provides an interface such that a third user recorded by the distributed computing process as attending the social event registered by the first user is given the option to join the computer game started by the second user on the same team as the first user.