CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/623,438 filed January 29, 2018, the contents of which are hereby incorporated by reference.

TECHNICAL FIELD

[0002] This disclosure relates to mobile devices, and more particularly to facilitating invocation, from a mobile software application, of a service hosted at a proximate electronic device or at a plurality of proximate electronic devices. BACKGROUND

[0003] Modem electronic devices are often interoperable with other devices. Often interoperability is wireless. For example, a mobile device may be able to cast audio or video wirelessly to a proximate set of speakers or a display using a medium-range wireless communications modality, such as Wi-Fi™, or a short-range wireless communication modality, such as Bluetooth™. In this context, the term“wireless communication modality” refers to any technology for wireless communication according to an established standard for transmitter behavior, receiver behavior, and/or communication protocol.

[0004] Discovery and wireless connection of a mobile device with a proximate electronic device, however, can be idiosyncratic or difficult, particularly when the devices have not previously communicated with one another using the chosen wireless communication modality. Various handshaking steps may be required to establish a wireless communication session between the devices and to access services of one device from the other. The handshaking steps may vary between wireless communication modalities.

[0005] For example, if Bluetooth™ is chosen as the operative wireless communication modality, handshaking between a first device and a second device that have not previously used that wireless communication modality may entail the following steps:

[0006] - the first device enters an inquiry state in which it broadcasts packets containing an inquiry access code on multiple hop frequencies, effectively inviting any proximate Bluetooth™ devices to respond

[0007] - the second device detects the packet from the first device on the hop frequency to which it is listening and, after a random backoff delay, responds with its own device address and clock synchronization information [0008] - the first device, having learned the device address of the second device from the response, enters a“paging” state in which it broadcasts ID packets containing the second device’s address on multiple hop frequencies to invite the second device to connect

[0009] - the second device, while in a“page scanning” state, receives from the first device the ID packet containing its own device address and sends an acknowledgement, at which time it assumes the role of a“slave” relative to the“master” role assumed by the first device

[0010] In contrast, the steps involved in establishing a wireless connection between a mobile device and a proximate electronic device using a Wi-Fi™ protocol, e.g. IEEE 802.1 lb/g/n/ac, are different from those used for Bluetooth™, and may include:

[0011] - if the Wi-Fi™ connection is to be made via an access point (AP), identifying the service set identifier (SSID) of the access point; this step may be complicated by the fact that some access points may not broadcast their SSIDs

[0012] - if the access point employs encryption, providing the correct password to facilitate connection (this may require manual queries on the part of the user)

[0013] - once a wireless communication session has been established with the AP, somehow determining the internet protocol (IP) address of the proximate electronic device within the Wi Fi™ local area network (LAN) to facilitate intercommunication with that device via the AP

[0014] To complicate matters, some wireless communication modalities, e.g. Bluetooth™, provide for“non-discoverable” modes of operation in which an electronic device is effectively invisible or silent from the perspective of a proximate mobile device. Discovery and connection with a proximate electronic device operating in that mode may be difficult if not impossible.

[0015] Even after a medium-range or shorter wireless communication session has been established, additional steps may be required to ascertain what services are available at the other device. For example, in the case of Bluetooth™, a Service Discovery Protocol (SDP) may be used by one device to discover what services another device may offer. This may involve setting up a Logical Link Control and Adaptation Protocol (L2CAP) link and exchanging of request/response protocol data units (PDU) over that link. Further steps may be required to actually access the services. These steps may require manual intervention on the part of a user.

In the case of Wi-Fi™, no comparable service discovery protocol exists, therefore proprietary methods may be required to ascertain what services may be available.

[0016] In view of the foregoing, implementation of mobile software applications that invoke services hosted at proximate electronic devices via medium-range or shorter wireless communication modalities may be tedious, complex, and inefficient.

SUMMARY

[0017] According to an aspect, there is provided a mobile device operable to wirelessly invoke a service hosted at a proximate electronic device, comprising: a transceiver for wireless communication via a medium-range or shorter wireless communication modality; at least one processor; and memory storing instructions that, upon execution by the at least one processor, facilitate invocation, from a software application at the mobile device, of a service hosted at an electronic device proximate to the mobile device, regardless of whether the software application has any information regarding the existence of the proximate electronic device, by: receiving, from the software application at the mobile device: a service payload; an indication of a requested service to be performed upon the service payload; and a target location descriptor describing a current location of the mobile device; using a dynamically updated repository of information regarding electronic devices currently proximate to the mobile device, converting the target location descriptor to device-specific addressing information for communicating, via the medium-range or shorter wireless communication modality, with the proximate electronic device; and using the device-specific addressing information, dispatching to the proximate electronic device, via the medium-range or shorter wireless communication modality and the transceiver, a request to perform the requested service upon the service payload.

[0018] In another aspect, there is provided a method of facilitating invocation, from a software application at a mobile device, of a service hosted at an electronic device proximate to the mobile device regardless of whether the software application has any information regarding the existence of the proximate electronic device, the method comprising: at the mobile device: receiving, from the software application at the mobile device: a service payload; an indication of a requested service to be performed upon the service payload; and a target location descriptor describing a current location of the mobile device; using a dynamically updated repository of information regarding electronic devices currently proximate to the mobile device, converting the target location descriptor to device-specific addressing information for communicating, via the medium-range or shorter wireless communication modality, with the proximate electronic device; and using the device-specific addressing information, dispatching from the mobile device to the proximate electronic device, via the medium-range or shorter wireless

communication, a request to perform the requested service upon the service payload.

[0019] In a further aspect, there is provided a tangible computer-readable medium comprising stored instructions that, upon execution by at least one processor of a mobile device having a wireless transceiver, facilitate invocation, from a software application at the mobile device, of a service hosted at an electronic device proximate to the mobile device, regardless of whether the software application has any information regarding the existence of the proximate electronic device, by: receiving, from the software application at the mobile device: a service payload; an indication of a requested service to be performed upon the service payload; and a target location descriptor describing a current location of the mobile device; using a dynamically updated repository of information regarding electronic devices currently proximate to the mobile device, converting the target location descriptor to device-specific addressing information for communicating, via the medium-range or shorter wireless communication modality, with the proximate electronic device; and using the device-specific addressing information, dispatching from the mobile device to the proximate electronic device, via the wireless transceiver using the medium-range or shorter wireless communication modality, a request to perform the requested service upon the service payload.

[0020] Other features will become apparent from the drawings in conjunction with the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In the figures which illustrate example embodiments,

[0022] FIG. 1 is a schematic depiction of electronic devices at a location;

[0023] FIG. 2 schematically illustrate a discovery server for facilitating discovery of services at the electronic devices of FIG. 1;

[0024] FIGS. 3, 4 and 5 schematically depict the structure of various database records of the discovery server of FIG. 2;

[0025] FIGS. 6A and 6B schematically depict operations for configuring the electronic devices of FIG. 1;

[0026] FIG. 7 depicts a graphical user interface displayed at one of the electronic devices of FIG. 1 during its configuration as shown in FIGS. 6A and 6B;

[0027] FIG. 8 is a schematic depiction of a mobile device;

[0028] FIG. 9 is a schematic depiction of memory of the mobile device of FIG. 8;

[0029] FIG. 10 illustrates a graphical user interface displayed at the mobile device of FIG. 8;

[0030] FIG. 11 schematically depicts, as a flowchart, operations for discovering proximate electronic devices and exposed services thereof for expedited wireless access to the services;

[0031] FIG. 12 is a schematic depiction of an example scenario in which a guest mobile device becomes proximate to the electronic devices at the location of FIG. 1;

[0032] FIG. 13 schematically depicts an example discovery object generated by the discovery server of FIG. 2 for the scenario of FIG. 12; [0033] FIGS. 14 and 15 schematically depict an outcome of the device and service discovery operations of FIG. 11 for the example scenario depicted in FIG. 12;

[0034] FIG. 16 depicts multiple electronic devices, in communication with a network and server, exemplary of embodiments;

[0035] FIG. 17 is a block diagram of an example device; [0036] FIG. 18 is a block diagram of memory at the device of FIG. 17;

[0037] FIGS. 19 and 20 schematically illustrate the discovery of interoperable proximate devices at a location;

[0038] FIG. 21 schematically depicts operation of the mobile device of FIG. 9 for invoking a service hosted at one or more proximate electronic devices; [0039] FIGS. 22A and 22B contain pseudocode depicting example functionality of a dispatcher component of the mobile device of FIG. 21; [0040] FIG. 23 is a flowchart showing operation of the dispatcher component at the mobile device of FIG. 21 for invoking a service hosted at a proximate electronic device; and

[0041] FIG. 24 depicts an example invocation of dispatcher component from a mobile software application.

DETAILED DESCRIPTION

[0042] FIG. 1 schematically depicts a room 1000 inside a residential or commercial building. The example room 1000 is an enclosed space to which access may be controlled, e.g. via a mechanical deadbolt lock opened by a physical key. It will be appreciated that the room 1000 is a form of location and may alternatively be referred to as such.

[0043] The room 1000 of FIG. 1 contains three electronic devices: a smart television (TV) 1010, a laptop computer 1020 and a smart thermostat 1030. The electronic devices 1010, 1020, and 1030 are, in certain respects, conventional. For example, each device includes dedicated hardware specific to the type of device-e.g. in the case of the TV 1010, a digital tuner, demultiplexer, MPEG decoder, image processor, LED display, speakers and other components. Practically, the electronic devices at location 1000 are geographically proximate to one another - for example within one hundred meters of each other.

[0044] As is conventional, each of the devices 1010, 1020 and 1030 comprises at least one microprocessor communicatively coupled to a storage medium (memory) storing executable software. The software at each device includes operating system software for basic device functions and higher-level application software. For example, application software at smart TV 100 may include applications (“apps”) for accessing different types of media or content, e.g., Netflix™, Spotify™, YouTube™ or Amazon™ Prime Video. The apps may be preloaded at the devices 110, 1020 and 1030 at the factory or may be subsequently downloaded by the device user, via an“app store” or other post-market digital distribution mechanism.

[0045] To facilitate such app downloads and for other reasons (e.g. to facilitate software updates), each of the electronic devices 1010, 1020 and 1030 is equipped for internet connectivity. In the case of smart TV 1010, the device may incorporate“set-top box” hardware for accessing the Internet 1050 directly via a broadband internet (e.g. coaxial cable) connection. In the case of the laptop 1020 and the smart thermostat 1030, the device may be equipped to access the Internet 1050 via wireless LAN, e.g. Wi-Fi™ via an internet-connected access point 1040. Devices 1020 and 1030 accordingly include suitable antennas, transceivers and software for Wi-Fi™ wireless communication, confirming to associated standard(s) such as IEEE 802.11 a/b/g/n/ac for example. The smart TV 1010 may also be factory -equipped with Wi-Fi™ capabilities. It will be appreciated that Wi-Fi™ is an example of a medium-range wireless communication modality having a typical range of about one hundred meters.

[0046] Each of the electronic devices 1010, 1020 and 1030 is also equipped for wireless communication via a short-range wireless communication modality, specifically Bluetooth™. For example, the TV 1010 and laptop 1020 may use Bluetooth™ to facilitate use of peripheral devices such as wireless keyboards or pointing devices (e.g. mice), whereas the smart thermostat 1030 may use Bluetooth™ to facilitate wireless communication with nearby temperature sensors. The devices 1010, 1020 and 1030 therefore include suitable antennas, transceivers and software for Bluetooth™ wireless communication, e.g. according to standard IEEE 802.15.1.

[0047] For clarity, in this disclosure the term“medium-range or shorter” is used to refer to wireless communication modalities operable over distances of about one hundred meters or less. Examples of medium-range or shorter wireless communication modalities include but are not limited to: Wi-Fi™; Bluetooth™; Zigbee™; TransferJet™; NFC (the latter two possibly being considered an ultra-short range wireless communication modality); Z-Wave™ and DECT (used by enterprise and hospital wireless phone systems). Thus, based on the foregoing description, it may be considered that electronic devices 1010, 1020 and 1030 of FIG. 1 are equipped with two medium-range or shorter wireless communication modalities (Wi-Fi™ and Bluetooth™). For clarity, broadband cellular network technology, e.g. 3G, 4G/LTE, is not considered as a medium-range or shorter wireless communication modality because its range can extend for greater distances, e.g. up to about five kilometers.

[0048] In the example depicted in FIG. 1, it is presumed that each of the devices at location 1000 requires some form of modality-specific and device-specific security credentials in order to establish medium-range or shorter wireless communication sessions with that device using that modality. Examples of security credentials include but are not limited to a Wi-Fi™ network SSID whose broadcast has been disabled or“hidden,” a network password (encryption key, e.g. WEP key or WPA/WPA2 passphrase), an otherwise undisclosed Bluetooth™ identifier, or a Bluetooth™ pairing code. The security credentials for the devices of FIG. 1 are summarized in Table 1 below:

Table 1: Security Credentials of Electronic Devices at Location 1000

[0049] It will be appreciated that, despite being identified using distinct identifiers in Table 1, the SSIDs and passwords for the three devices 1010, 1020 and 1030 may actually be the same, e.g. if the devices all use the same access point 1040 for Wi-Fi™ connectivity. This is not necessarily always the case for electronic devices at the same location. It will further be appreciated that, in Table 1, the Bluetooth™ addresses BTADDR0001, BTADDR0002, BTADDR0003 are distinct. For clarity, the identifiers in Table 1 are symbolic. For example, actual Bluetooth™ addresses must have 12 hexadecimal characters.

[0050] Each of the electronic devices 1010, 1020 and 1030 provides a variety of services. In this disclosure, a“service” is an operation that invokes or effects functionality at, or using the resources of, a device. The functionality may for example be associated with a particular input interface (e.g., a sensor such as a microphone or CCD device of a camera); a particular output interface, e.g., a display screen, a speaker; a particular software functionality (e.g.,

decoding/encoding a message, performing a calculation, installing a software application, etc.), a particular resource (e.g., storing data in memory); a particular software application (e.g., launching a browser to display a particular website, launching an application to display a text message or image); or a combination of the above (e.g., where the service invokes the functionality of a virtual reality (VR) device comprising a combination of various interfaces, resources, and software). [0051] In the case of TV 1010, services include an image display service for displaying (still) images in common formats (e.g. .jpg or .gif), a video playing service for playing video in common video formats (e.g. .mpg or .mp4), and an audio playing service for playing audio in common formats (e.g. .mp3 or Dolby™ Digital). The laptop computer 1020 provides similar services to the TV 1010, among others. The smart thermostat 1030 provides a temperature sensing service. The services may be implemented using operating system-specific API calls and/or proprietary formats.

[0052] Notably, in order to facilitate wireless access to these services from proximate electronic devices, each of the devices 1010, 1020 and 1030 is configured with“receiver” software. The receiver software facilitates automatic wireless connectivity with suitably configured, complementary mobile devices that become proximate to the devices 1010, 1020 and 1030 and may wish to invoke an exposed service at one of the devices. This functionality may be referred to using the trademark Encounters™.

[0053] For clarity, in this disclosure, electronic devices that have been customized with the receiver software are referred to either as“receiver devices” or“host devices.” The

configuration of a device to act as a receiver device is described below in conjunction with FIGS. 6A and 6B. Conversely, mobile devices that have been configured to be complementary to receiver devices are referred to herein either as“sender devices” or“guest devices.” The latter term connotes the fact that the devices may not normally be attendant at that location, and for this reason, may not have previously established wireless communication with resident receiver devices using a medium-range or shorter modality. The configuration of a device to act as a sender device is described below.

[0054] To facilitate the functionality described above, a discovery server is deployed, e.g. at a central or remote location. An example discovery server 1200 is schematically depicted in FIG. 2.

[0055] Referring first to FIG. 2, server 1200 includes at least one processor coupled to memory storing a discovery database 1202. In this example, the database 1202 is a SQL database, which is a form of relational database. Database 1202 may also be implemented as a NoSQL database. The discovery server 1200 may be implemented as a cloud service, e.g. using Microsoft® Azure™ or Amazon™ Web Services, and may be distributed across multiple physical devices. In this case, database 1202 may be implemented as a distributed database such as, e.g., a Couchcase™ or Firebase™ database.

[0056] At a high level, the discovery server 1200 may be considered to perform a

“matchmaking” role. In that role, the server 1200 periodically and pre-emptively apprises or updates participating mobile“sender” devices (as described below) with information about receiver devices known to be at the same location as, and therefore proximate to, the mobile device. The updates may occur periodically, e.g. responsive to location updates from participating mobile devices. Each update sent to a mobile device not only identifies what receiver devices are proximate, but also what services are exposed (i.e. available for invocation by proximate sender devices) at each those devices. The updates also provide addressing information— including any necessary security credentials (e.g. as shown in Table 1 above)— to the mobile device. This is done to facilitate the automatic establishment of wireless communication sessions with target receiver devices for wireless access to their exposed services.

[0057] In a sense, the“matchmaking” performed at discovery server 1200 may be considered to match participating mobile sender devices with a dynamically changing set of proximate receiver devices using co-location as the matchmaking criterion. As will be appreciated, the pre emptive nature of the updates— i.e. the fact that the updates are made automatically and dynamically, even before the mobile device has expressed any intention of invoking a service to be performed at one of the receiver devices at its cunent location— greatly simplifies and expedites wireless access to services at proximate electronic devices should they become needed.

[0058] In this embodiment, discovery database 1202 primarily stores two types of records in respective separate database tables: user records 1204 and host device records 1206.

[0059] User records 1204 typically consist of user information of the same type that is typically collected by contemporary web-based services such as Facebook™ or Gmail™. This user information typically includes a username (possibly taking the form of a unique email address or phone number), password, and name (first name and surname).

[0060] Host device records 1206 are more substantial. Fundamentally, each device record corresponds to a participating host device, including information such as unique host device ID and the location of the device. In turn, each host device contains one or more service records. Each service record represents an exposed service at that host device and provides information required for invoking the service. Moreover, each service record itself contains one or more “route” records. A route record represents a wireless communication modality available at the containing host device for accessing the containing service. It is within this record that the above-mentioned address and security access information specific to that wireless

communication modality and to the host device (e.g. as set forth in Table 1 above) is stored.

[0061] The latter aspect of the database table structure, i.e. storing records representing addressing information for distinct wireless communication modalities (including security credentials like passwords and encryption keys) on a per-service basis, may be considered counterintuitive. The reason is that such addressing information is generally specific to the device rather than to an exposed service at that device. Nevertheless, the latter structure is adopted in this embodiment in order to more easily and efficiently identify, at run time, wireless communication modalities suitable for an exposed service of interest.

[0062] For example, if a host device providing a“play Video” video playback service is equipped with both Wi-Fi™ and Bluetooth™, the corresponding service record representing that service may contain a single“route” record representing only the Wi-Fi™ modality and no “route” record representing the Bluetooth™ modality, with the rationale that Bluetooth™ is poorly suited for meeting the data transmission demands of casting video whereas Wi-Fi™ is well-suited for that purpose. On the other hand, if the same host device provides a

“controlCursor” control mouse cursor input service, the corresponding service record representing that service may contain a single“route” record representing only the Bluetooth™ modality, with that the rationale that Bluetooth™ is particularly suited for meeting the low communication latency demands of controlling mouse cursor input whereas Wi-Fi™ is less well-suited. In another example, the route for a particular service may be limited to one or more ultra-short range wireless modalities (e.g., NFC) if the service is particularly sensitive and it is undesirable for the service to be accessed at a distance (e.g., a service to transfer funds between the devices). When multiple routes are suitable, a service record may store an order of preference.

[0063] FIG. 3 schematically depicts an example UML class diagram 1300 that can be used to represent a host device. In this example class diagram 1300, the class ahributes include: bluetoothMacAddress - a Bluetooth™ address (empty for non-Bluetooth™ devices) brand - an identifier of the host device manufacturer (e.g., Samsung™, HTC™, etc.) CREATOR - constructor of object from serialized message

devicelD - a unique host device identifier

modelNumber - an identifier of the manufacturer-assigned model number of the host device

name - a name assigned by the owner use of the host device

osldentifier - an operating system identifier

pluginS ervices - a list of exposed services (see FIG. 4) screenSize - an indicator of a size of screen (if any) at the host device type - an indicator of a type of device of the host device

userDefmedContext - a list of strings comprising user-defined context identifiers, e.g. describing an intended use of the device, properties (like“wall mounted display”)

[0064] The operations of example host device class diagram 1300 of FIG. 3 include:

DescribeContents() - describe if there are any special data types, like file descriptors stored in the object

DevicePublic() - constructor

writeToParcel (Parcel, int) - method for serializing the DevicePublic object, e.g. to facilitate passing of the data from the discovery server 1200 to mobile devices

[0065] FIG. 4 schematically depicts an example UML class diagram 1400 that can be used to represent an exposed service at a particular host device. In this example class diagram 1400, the class attributes include:

CREATOR - constructor of object from serialized message

name - service name

passcode - access code set for service (optional)

privateAccess - Boolean value; if set to true, access to service is restricted to the owner of the device

routes - a list of wireless communication modalities by which this service can be accessed at the containing host device (see FIG. 5)

running - Boolean value marking if the service is running or stopped

serviceVersionNumber - version number used for checking sender-receiver compatibility

[0066] The operations of example service class diagram 1400 of FIG. 4 include:

DescribeContents() - describe if there are any special data types, like file descriptors stored in the object

isRunningO - returns“true” if service is running

ServicePublic() - constructor of service public object

writeToParcel (Parcel, int) - method for writing the object to Android Parcel data type. Allows the serialization of data object and passing it between applications [0067] FIG. 5 schematically depicts an example UML class diagram 1500 that can be used to represent a“route” or wireless communication modality by which the containing service may be accessed. In this example class diagram 1500, the class attributes include: address - Service address. Address can be a URI, BLE address, TCP network address type - string that describes the transport protocol type, possibly encoding multiple attributes e.g. Bluetooth™/BLE/Zigbee™ connections used, link-local connection or server based TCP/UDP communication

[0068] FIGS. 6A and 6B schematically depict, in the form of a UML sequence diagram, operations 1600 for customizing (configuring) the smart TV 1010 of FIG. 1 with receiver software so that it may act as a host device. The operations 1600 may for example be performed by an owner 1602 of the TV 1010 subsequent to its purchase, or at the factory. A user may for example interact with the TV 1010 using a wireless keyboard or remote control to effect operations 1600. The same methodology can be used to configure other electronic devices, such as laptop 1020 and thermostat 1030, as host devices.

[0069] Initially, the user 1602 may open a provided web link (operation 1604, FIG. 6 A) to trigger download 1606 of the Encounters™ receiver software 1608 from an Application Store 1610. In this embodiment, the receiver software 1608 is downloaded in the form of an

Android™ application package (APK), a package file format used by the Android™ operating system for distribution and installation of software. Upon completion of downloading, the user 1602 starts 1612 (i.e. executes) the receiver software 1608 for the first time.

[0070] Firstly, the user 1602 either registers for Encounters™, e.g. by specifying new user credentials comprising a username, password, name, email address, and mobile telephone number (e.g. as for known social media platforms such as Facebook™), or logs in using existing login credentials (operations 1614 and 1616, FIG. 6A). In the former case, a new user record 1204 (FIG. 2) is defined based on the supplied user credentials.

[0071] Subsequently, by virtue of its execution for the first time at device 1010, the receiver software 1608 automatically generates a new Encounters™ device identifier (operation 1618, FIG. 6A) and, in operation 1620, sends the identifier to the discovery server 1200. Operation 1622 checks whether a number of allowed host devices has been exceeded and, if so, permits the user to purchase additional devices before registration continues. [0072] In operation 1624 (FIG. 6A), an SMS verification code is sent to the user for entry to verify that the device 1010 is indeed owned by the user 1602.

[0073] In operation 1626, a private context is automatically generated. In this disclosure, the term“context” refers to contextual information about a device. Broadly speaking, contextual information can include information regarding a device’s surroundings, its operating

environment, its characteristics, its configuration, or resources available at the device. For the present embodiment, an important aspect of a device’s context is its location. The location may for example be determined using a position receiver (e.g. GPS receiver) at the device or, for devices lacking such a receiver, by appropriate use of geolocation tools, which may be web- based. The contexts are considered“private” or“secret” in that they are isolated from the user and are not user-editable or even viewable by the owner or other users (to prevent bad actors from falsifying characteristics). Private contexts may be intended solely for matching services (and optionally for location verification). This can be distinguished from“public” contexts such as #livingroom, which are user defined and can be exposed to other users, and which may be used by those other users for targeting devices.

[0074] Once the host device location is known, a corresponding location descriptor is generated. Generally, a location descriptor of a device describes a current location of the device. Various formats and degrees of precision may be used. One format of location descriptor is a natural language format, using ASCII characters capable of being read and understood by a human user e.g. #boardrooml23mainstreetNYl000l. A possible advantage of using a natural language format is that human users may be able to define location descriptors that are meaningful to them.

[0075] An example of a natural language location descriptor is shown in FIG. 7, which depicts an example graphical user interface (GUI) 1700 displayed at smart TV 1010 during the course of its configuration as a host device. If the location 1000 were a living room, the owner might choose to specify a natural language location descriptor #livingroom (field 1704, FIG. 7). Such natural language descriptors can be used independently of, or in conjunction with, other forms of location descriptors (e.g. geohashes, as described below). The example GUI 1700 also permits user customization of device name (field 1702, FIG. 7) and permits access to exposed services to be controlled via checkboxes 1706. Although not depicted in FIG. 7, the GUI 1700 may also permit specification of user access permissions for each of the exposed services on a service-by- services basis (e.g. as described below in conjunction with operation 1672 of FIG. 6B). [0076] Another format of location descriptor, used in this embodiment, is a geohash. As is known in the art, a geohash is a geocoding system that encodes a geographic location into a string of letters and digits according to a hierarchical spatial data structure that subdivides space into“buckets” of grid shape. Conveniently, string-comparison techniques can be used to compare two geohashes representing the locations of two different devices to determine, by a desired order of magnitude, how proximate the devices are to one another. As will be appreciated, that approach can be used to determine whether a sender device and a host device are in sufficiently close proximity to permit medium-range or shorter wireless communication modalities to be used for wireless communication between the devices.

[0077] Turning to FIG. 6B, the receiver software 1608 then engages in processing for analyzing the host device to determine what services are available there. Upon starting this process (operation 1650, FIG. 6B), the receiver software 1608 detects the capabilities of the host device (operation 1652).

[0078] In one example, device capabilities may be detected using an operating system function such as the getSystemAvailableFeatures call provided by the Android™ O/S. This can be used to determine, e.g. if a device support single or multi-touch. In some cases, device capabilities can be inferred from the detected operating system. Other example device capabilities include: display present; location detection; compass; video capture; camera; audio capture; Bluetooth; Bluetooth Low Energy; proximity; light sensor; NFC; fingerprint reader; gyroscope; Wi-Fi™ Direct; USB host mode; and barometer.

[0079] These“capabilities” should be distinguished from“services.” The discovery server 1200 maps capabilities to services based on pre-defined mappings. For example, a service for displaying video may require the“display” and“audio” Android™ capabilities.

[0080] Other information collected about the registered device at this stage may include (if applicable):

• Android™ device ID

• International Mobile Equipment Identity (IMEI)

• network interface address

• OS version number

• Screen size

• Connectivity interfaces available (Wi-Fi™, Bluetooth™, NFC, TJ, 4G, etc.)

• Model number of device

• Brand of device • Network operator (if available)

[0081] Once the capabilities of the host device have been detected, they are communicated to the discovery server 1200 (operation 1654, FIG. 6B), where they are stored (operation 1656). In some embodiments, the capabilities are represented by strings, which can be sent to the discovery server 1200 in the form of an object representing the device and its capabilities, serialized (e.g., using Json or Protobuf serialization) for transmission via TCP/IP sockets.

[0082] Thereafter, the discovery server 1200 obtains a list of allowed services of the account as well as a permission table for services (operations 1658 and 1660, FIG. 6B). Operation 1658 essentially determines which services have been deemed accessible/inaccessible by the host device owner, e.g. via checkboxes 1706 in graphical user interface 1700 of FIG. 7.

[0083] Operation 1660 allows user access permissions to be defined so that access to exposed services can be controlled based on guest device user credentials, including by user class. For example, access to a“Showlmage” service may be set to allow access by the owner of a guest device, a first class of user (e.g. family members), but not to any other users. Alternatively, user access permissions (also referred to as“user permissions”) may be delimited by time, e.g.

accessible during particular time windows only. User permissions may be confirmed/adjusted via GUI 1700 (e.g. at subsequent operation 1672), allowing the host device owner to define, on a per-service basis, user permission such as: no one, everyone, particular people, particular classes/groups of people, or black listing. Permissions can also be defined to be time limited. These sets of permissions are stored at the host device in a data structure referred to a permissions table.

[0084] This information is used at the discovery server 1200 to generate a device service tree, i.e. a data structure representing all of the services available at a given host device (in this case, TV 1010).

[0085] At operation 1662, the service tree is sent to the receiver software 1608. Thereafter, the receiver software 1608 engages in the following operations shown in FIG. 6B. The device service tree is parsed, i.e. the discovery object is deserialized (operation 1664). Services are assigned according to capabilities; for example, each service may be provided by a

corresponding plugin as part of an exposed service, and the plugin for each service may be configured to use particular hardware resources at the hardware device, e.g., to reference particular hardware IDs for particular capabilities through the Android™ SDK (operation 1666). Capabilities are enabled/disabled, e.g. turning on transceivers, GPS receivers, or analogous components (operation 1668); allowed plugin services are started (operation 1670); permissions on services are applied (operation 1672); and wireless communication modality-specific addressing information (e.g. encryption passwords) are cached on a per-service basis (operation 1674)

[0086] Subsequently, by way of confirmation, the updated device service tree is sent to the discovery server 1200 (operation 1676, FIG. 6B). At discovery server 1200, returned services are matched, and any service in the service tree to which the host device user has denied access is removed (operation 1678, FIG. 6B). At this stage, the operations 1600 for service registration for the smart TV 1010 of FIG. 1 are complete.

[0087] Operations 1600 are also performed at each of the laptop 1020 and smart thermostat 1030 of FIG. 1. When that has been done, each of the devices 1010, 1020 and 1030 of FIG. 1 are configured to act as host devices.

[0088] FIG. 8 schematically depicts a mobile device 1800 that will be configured to act as a “sender device” as described below. In present embodiment, the mobile device 1800 is an LG Nexus™ 5X smartphone having a form factor as shown in FIG. 10 (described below). Other types of mobile devices, be they smartphones or otherwise, may be used in other embodiments.

[0089] The basic components of mobile device 1800 depicted FIG. 8 include a processor 1802, which in the case of the Nexus™ 5X is a Hexa-core (4x1.4 GHz Cortex-A53 & 2x1.8 GHz Cortex- A57). The processor 1802 is coupled to memory 1804, which in this embodiment includes 2 gigabytes of RAM and 32 gigabytes of secondary storage. The processing capabilities at the example mobile device 1800 further include an Adreno™ 418 graphics processing unit and a Qualcomm™ MSM8992 Snapdragon 808 chipset (not expressly depicted).

[0090] Mobile device 1800 also comprises conventional I/O interfaces 1806, including a speaker and an IPS LCD capacitive touchscreen (not expressly depicted). Additionally, the device includes various network interfaces 1808, including suitable antennas, transceivers and software to effect various medium-range or shorter wireless communication modalities. In the present embodiment, these interfaces provide various forms of wireless local area network (WLAN) connectivity, including Wi-Fi™ 802.11 a/b/g/n/ac, dual-band, Wi-Fi™ Direct, Digital Living Network Alliance (DLNA) and hotspot. Bluetooth™ 4.2, A2DP capability is also provided. The transceivers accordingly typically include radio frequency (RF) transceivers. [0091] The mobile device 1800 further includes position receivers 1810 for determining a current location of the device. The receivers in this embodiment comprise hardware components compatible with the Assisted global positioning system (A-GPS) and the Global Navigation Satellite System (GLONASS).

[0092] All of these components depicted in FIG. 8 are communicatively coupled to the processor 1802. Other components of device 1800 are omitted from FIG. 8 for brevity.

[0093] A user desirous of configuring the mobile device 1800 to act as a sender device may download and install Encounters™ sender software, e.g. using similar techniques as described above for host devices (i.e. downloading an APK from an application store). Alternatively, the sender software may be pre-installed at the factory by the mobile device manufacturer, e.g. from a tangible computer-readable medium (e.g. magnetic or optical disk).

[0094] FIG. 9 schematically depicts memory 1804 of mobile device 1800 in greater detail post-installation of the sender software. It will be appreciated that the depiction in FIG. 9 is simplified for the sake of brevity and clarity. The memory 1804 is a form of tangible computer- readable medium.

[0095] FIG. 9 adopts a convention in which a vertical position of the boxes representing software entities within the containing memory 1804 generally connotes the level of the corresponding software entity: a high position within the box 1804 connotes higher-level software entities, whereas a low position connotes the lower-level software entities. As such, it can be appreciated that the memory 1804 includes high-level applications (“apps”) 1902, 1904 (collectively apps 1900). In this example, the app 1902 is a slide generation/presentation app, and the app 1904 is a social media app. The apps 1900 are presumed to have been developed to benefit from the Encounter™ functionality described herein when the sender software is detected at the mobile device 1800, and to operate conventionally otherwise.

[0096] Also depicted in memory 1804 is operating system (O/S) software 1910. In the present example, the O/S is Android 8.0 Oreo, however other embodiments may use other mobile operating systems (e.g. iOS™).

[0097] Sender software 1920 may be considered to operate at a level below applications 1900 and above operating system 1910, e.g. at the level of an Android™ system service. A general objective of the sender software 1920 is to facilitate wireless access, from applications running at mobile device 1800, of exposed services at proximate host devices. In furtherance of this objective, the sender software 1920 performs operations includes: periodically apprising the discovery server 1200 of a current location of the mobile device 1800; responsive to the updating, periodically receiving a discovery object 1930 (described below) from the discovery server 1200; using the current discovery object, automatically establishing wireless

communication sessions with proximate host devices whose exposed services are to be invoked; and providing access to the exposed services using the wireless communication sessions.

[0098] The sender software 1920 provides an application programming interface (API) 1922 to simplify access to exposed services from apps 1900 at the mobile device. This approach can be used to advantageously shield the apps 1900 from complex, lower-level details that would otherwise be required to, e.g., ascertain whether any electronic devices are proximate, to identify the services (if any) exposed at those devices, and to establish any necessary wireless communication session(s) required for accessing those services wirelessly.

[0099] For clarity, the discovery object 1930 is depicted using dashed lines in FIG. 9 to connote the fact that it does not yet reside within memory 1804, since the sender software 1920 has not yet been executed.

[00100] Once installation of the sender software 1920 at mobile device 1800 is complete, that device is considered to have been configured as a sender device. Initial execution of the sender software 1920 at mobile device 1800 may trigger presentation of a graphical user interface 1980 as depicted in FIG. 10.

[00101] Referring to that figure, it can be seen that the GUI 1980 presents fields 1982 for entering user credentials, permitting an existing Encounters™ user to log in (via button 1984) or to sign up for the first time (via button 1986). In the latter case, a new user record 1204 (FIG. 2) would be generated in discovery database 1202.

[00102] Afterwards, the sender software 1920 in this embodiment operates in the background at mobile device 1800, i.e. transparently from the perspective of the user. Future execution of the sender software 1920 upon mobile device startup may be automatic and may avoid the need to re-enter user credentials (e.g. using cookies or analogous mechanisms).

[00103] When the discovery server 1200 authenticates the user of the mobile device 1800, it establishes and maintains a TCP socket session (distinct from the wireless communication sessions referenced elsewhere in this disclosure) with the mobile device 1800. In the present embodiment, this involves generation of a session key that is provided to the sender software 1920 at the mobile device 1800. The session key, which is not exposed outside of sender software 1920 and the server, can be made to have an expiration period after which the user needs to re-authenticate. When the sender software 1920 is connected to the discovery server 1920, it maintains the session by maintaining a TCP/IP socket in open state. This socket is used by the discovery server 1200 to push data (e.g. discovery objects 1930) to the sender software 1920. The session may be made secure using the secure sockets layer/transport layer security (SSL/TLS) protocol. Session keys can be exchanged in accordance with SSL/TLS.

[00104] FIG. 11 schematically depicts, as a flowchart, operations 2000 for discovering devices and services for expedited wireless access to exposed services at proximate devices. The operations 2000 occur partly at the mobile device 1800 and partly at the discovery server 1200 (FIG. 2), as will be described.

[00105] The operations 2000 of FIG. 11 are described for an example scenario depicted in FIG. 12. In that scenario, a user 2100 carrying his mobile device 1800 enters location 1000 for the first time. For instance, the user 2100 might visiting location 1000 to give a presentation to prospective clients.

[00106] Operations 2000 may be triggered automatically and transparently from the perspective of the user 2100. It is presumed that the sender software 1920 of FIG. 9 is executing (e.g. in the background) at mobile device 1800 and that the receiver software 1608 (FIG. 6A) is executing (e.g. in the background) at each host device 1010, 1020, and 1030, when the user 2100 arrives at location 1000.

[00107] Initially, the sender software 1920 uses position receiver 1810 (FIG. 8) to detect the location of mobile device 1800. The detection may for example be triggered by the sensing of device motion (e.g. using an accelerometer at the device) or may occur periodically.

[00108] In response to the detection, the sender software 1920 generates a location descriptor 2104 (FIG. 12) for location 1000. In this embodiment, the location descriptor is a geohash created by converting GPS coordinates of location 1000 from position receiver 1810 (FIG. 8) and into a geohash (a string).

[00109] The location descriptor 2104 is subsequently reported to discovery server 1200, e.g. by way of a cellular data connection maintained with the server 1200 whenever the sender software 1920 is operational at mobile device 1800. The mechanism for maintaining such a connection may be similar to the mechanisms used, e.g., to maintain connectivity between other mobile apps (e.g. Facebook™) and their corresponding servers.

[00110] Receipt of the location descriptor 2104 at the discovery server 1200 triggers operations at the server for identifying a set of proximate electronic devices at the location indicated by the received location descriptor (operation 2002, FIG. 11). In the present embodiment, the discovery server 1200 generates a SQL query comprising the location descriptor of the mobile device and a specified degree of co-location precision. The latter parameter governs the granularity (magnitude) of the geographic area within which a host device must be located in order to be considered“co-located with” (proximate to) the mobile device 1800. This effectively allows for the size of search area for proximate devices to be controlled.

[00111] In the present embodiment, the specified degree of co-location precision is a number of “most significant” bytes of two geohashes that must match for their corresponding devices to be considered proximate. For example, seven matching most significant bytes may represent co- location precision of +/- seventy-six meters, which is within one hundred meters.

[00112] When the SQL query is submitted to the discovery server 1200, the host device records 1206 are searched to identify any host device whose location descriptor (as configured during setup at operation 1626, 1628 of FIG. 6A) matches the location descriptor 2104 of the mobile device 1800 within the specified degree of co-location precision. In the present example, the query result returns records for each of host devices 1010, 1020 and 1030 at location 1000.

[00113] In view of the hierarchical“device-service-modality” structure of the host device records (as described above in conjunction with FIGS. 3-5), the query result encompasses not only device information for each of the proximate host devices 1010, 1020, and 1030, but also information regarding: what services are exposed at each device; what medium-range or shorter wireless communication modalities are available at each device; and addressing information (including security credentials, if any) for establishing a wireless communication session with each host device using any of the modalities. In other words, for each proximate host device at the location 1000, the query result identifies: a set of exposed services provided at the host device; a set of medium-range or shorter wireless communication modalities of the host device for wirelessly accessing the set of exposed services; and for each of each of the wireless communication modalities, addressing information for establishing a wireless communication session with the host device (operation 2004, FIG. 11).

[00114] The discovery server 1200 uses the query result to generate a discovery object 1930, also referred to as a“service tree” or“device service tree”. The discovery object 1930 in this example is schematically depicted in FIG. 13 in the form of a UML object diagram. It will be appreciated that the representation in FIG. 13 is simplified and that some portions have been omitted for brevity.

[00115] As illustrated, the discovery object 1930 contains a set of device objects, each representing a host device proximate to the mobile device 1800. In the present embodiment, each device object is an instance of the devicePublic class of FIG. 3. The host device object 2200 contains device information of smart TV 1010, notably including screen size, wireless protocols supported, touch screen supported and environmental sensors connected. Device objects representing the laptop 1020 and the smart thermostat 1030 are not expressly depicted in FIG. 13.

[00116] Each host device object contains one or more service objects, each representing an exposed service at the relevant host device. In the present embodiment, each object in the list is an instance of the servicePublic class of FIG. 4. The service objects 2202, 2204 and 2006 depicted in FIG. 13 represent the“PlayVideo,”“Play Audio,” and“ShowText” services of smart TV 1010 (see FIG. 7); additional objects representing other exposed services of TV 1010 not expressly depicted.

[00117] Finally, service objects 2202 and 2204 contain a route object 2208 and 2210 respectively representing Wi-Fi™ at smart TV 1010. In contrast, service object 2206 contains a route object 2212 representing a different wireless communication modality, i.e. Bluetooth™.

[00118] Notably, each service object 2208, 2210 and 2212 contains addressing information required for establishing a wireless communication session with the relevant host device (TV 1010) using the relevant modality. In this example, the addressing information includes security credentials (SSID + encryption key for Wi-Fi™, Bluetooth™ address of TV operating in non- discoverable mode for Bluetooth™).

[00119] Once the discovery object 1930 has been created, it is sent from the discovery server 1200 at mobile device 1800, where it is stored in memory 1804 (FIG. 9) for future access as necessary by the sender software 1920. For security and privacy reasons, the discovery object 1930 is stored so as to deter tampering with the security credentials forming part of the addressing information for any modality, e.g. within an Android™ application sandbox (a mechanism whereby an O/S kernel enforces security between applications at the process level). [00120] The storage of discovery object 1930 may be considered as a pre-emptive storing, at mobile device 1800, of addressing information for each of the available wireless communication modalities of each of the proximate host devices as soon as the mobile device becomes proximate to those host devices. In this context,“pre-emptive storing” means“storing before the mobile device has established, and regardless of whether the mobile device shall ever establish, a wireless communication session with any of the proximate electronic devices identified in the discovery object 1930 using any of the associated wireless communication modalities.”

[00121] It will be appreciated that the stored discovery object 1930 may be considered as a repository of information regarding electronic devices currently proximate to the mobile device. As will be described, the repository is dynamically updated, e.g. based on changes in geographical location of the mobile device 1800.

[00122] To facilitate comprehension of the beneficial effect of the above-described pre-emptive storing of addressing information, a visual analogy is provided in the schematic diagram of FIG. 14. Referring to that diagram, the pre-emptive storing can be thought of as configuring the mobile device 1800 to provide three“virtual data cables” 2310, 2320 and 2330 between the mobile device 1800 and each of the respective host devices 1010, 1020 and 1030. Each virtual cable, illustrated using dotted lines, represents a prospective wireless communication session (using a medium-range or shorter modality) that can be quickly and automatically established by the sender device, i.e. without requiring any manual action for that purpose on the part of the mobile device user.

[00123] When user 2100 decides to present slides stored at mobile device 1800 to an audience at location 1000, he launches slide presentation app 1902 (FIG. 9) and loads the desired slides. Disadvantageous^, the display of the mobile device 1800 is too small for effective display of the slides at location 1000.

[00124] Conveniently, the slide presentation app 1902, transparently from the perspective of the user, invokes a function of API 1922 (FIG. 9) of the sender software 1920, passing as one of its parameters the slides to be presented. This is depicted schematically in FIG. 21.

[00125] FIG. 21 schematically depicts operation of the mobile device 1800 for invoking a slide presentation service hosted at one or more of the proximate host devices 1010, 1020 and 1030. The operation depicted in FIG. 21 permits the mobile software application 1902 to invoke the service at a proximate electronic device even without any knowledge, on the part of the software application, of what electronic device(s) may be proximate when the service is needed or of which proximate electronic device shall provide the requested service. Put another way, the depicted mechanism facilitates invocation, from a mobile software application at a mobile device, of a service hosted at an electronic device proximate to the mobile device, regardless of whether the software application even has any information regarding the existence of the proximate electronic device.

[00126] For clarity, the schematic diagram of FIG. 21 is a simplified block diagram of the mobile device 1800 depicting both hardware and software components.

[00127] The sole depicted hardware component of mobile device 1800 in FIG. 21 is wireless transceiver 2014; other hardware components of the device 1800, such as processor 1802 and memory 1804 as depicted in FIG. 8, are omitted for brevity. The wireless transceiver 2014 is suitable for wireless communication via at least one medium-range or shorter wireless communication modality as defined herein. The transceiver 2014, which may form part of the network interface 1808 depicted in FIG. 8, may for example be an integrated circuit compliant with known RF communication protocols or may comprise an optical (e.g. infrared) emitter and detector.

[00128] The software elements of FIG. 21 include the mobile software application (“app”)

1902, the sender software 1920, and the discovery object 1930, as described above.

[00129] As illustrated, the sender software 1920 includes a dispatcher 2102. In the present embodiment, the dispatcher 2102 is a software module (e.g. function or method). The dispatcher 2102 may be responsible for converting an untargeted service request 2106, i.e. a request for a service that is not specific to any device, into a targeted request 2108, i.e. an invocation or request for performing the service at a particular proximate electronic device. In the present embodiment, the dispatcher 2102 is implemented as a method of an object-oriented class comprising sender software 1920. Pseudocode 2200 depicting example functionality of dispatcher 2102 is shown in FIGS. 22A and 22B. General operation 2300 of the dispatcher 2102 of the present embodiment for generating a targeted service request from an untargeted service request is depicted in the flowchart of FIG. 23, described below.

[00130] In this example, it is presumed that the slide presentation software application 1902 at mobile device 1800 has been authored to make an untargeted service request, as defined hereinbelow, by invoking an“UntargetedServiceRequesf’ method (function) of the dispatcher 2012 upon the opening of a set of slides. An example invocation of the

UntargetedServiceRequest function is shown in pseudocode in FIG. 24. Referring to FIG. 24, it can be seen that the UntargetedServiceRequest method of the present embodiment takes four parameters.

[00131] The first parameter, TargetDescriptors, includes a target location descriptor describing the current location of the mobile device 1800 (e.g. a geohash or a location descriptor in natural language format such as #livingroom, as described above), which is the target location for providing the desired service.

[00132] The second parameter, RequestedService, is an indication of the requested service to be invoked. In the present scenario, the service may for example be a“Display Image” or “PlayVideo” service or a comparable service suitable for presenting slides. The second parameter may take the form of an enumerated type in some embodiments.

[00133] The third parameter, ServicePayload, represents the input data for the service or payload upon which the service is to be performed. In this example, the service payload is a set of slides. In some cases, a payload may be a link to input data (e.g. a URL) rather than the data itself.

[00134] The fourth parameter, NumberOfDevices, is an integer representing the number of electronic devices that should provide the service. For example, a value of two (2) in this example scenario may indicate that the slides should be presented simultaneously on two proximate host devices. In FIG. 24, the fourth parameter has been set to one, meaning that only one proximate electronic device should be used for presenting the slides. Alternative embodiments may omit this parameter, e.g. in favor of hard-coded functionality in the dispatcher 2102 dictating the number of devices to be used for providing the requested service.

[00135] The invocation, from app 1902, of the UntargetedServiceRequest method may be considered as an“untargeted service request” because it does not specify any particular proximate electronic device for providing the desired service. This untargeted request is denoted in FIG. 21 at 2106 by an arrow from the mobile software application 1902 to the dispatcher 2102.

[00136] The dispatcher 2102 receives the untargeted requested 2106 from the app 1902 with the parameters mentioned above, including the target location descriptor describing the current location of the mobile device 1800 (FIG. 23, 2302). Thereafter, the dispatcher 2102 uses the discovery object 1930 to convert the target location descriptor to device-specific addressing information for communicating, via a medium-range or shorter wireless communication modality, with at least one proximate electronic device that will provide the requested service (FIG. 23, 2304).

[00137] In performing this conversion, the dispatcher 2102 uses the repository of information regarding currently proximate electronic devices, i.e. the discovery object 1930, to identify a candidate device for presenting the slides. Once a candidate proximate electronic device has been identified, then a route object associated with the corresponding host device object within the discovery object 1930 can be accessed in order to obtain device-specific addressing information for communicating with the candidate device via a medium-range or shorter wireless communication modality.

[00138] More specifically, and referring to FIG. 22A, the UntargetedServiceRequest method of the present embodiment initially creates a message data structure that will constitute the targeted service request 2108 of FIG. 21 (FIG. 22A, lines 4-8). In the present embodiment, the targeted service request message includes a unique ID of the sender device 1800, a unique ID of the user 2100, an indicator of the requested service, and the payload for the requested service. The sender device ID and user ID may be used at the candidate device to verify that the user 2100 and/or his mobile device 180 is/are authorized to invoke the requested service. The message may then be encrypted and serialized for transmission, e.g. into a Javascript™ Object Notation (JSON)- format string (FIG. 22A, lines 10-14), in the illustrated embodiment.

[00139] With the target service request message having been readied for transmission, attention now shifts to the identification, from among the proximate electronic devices, of one or more suitable candidates (targets) for receiving the message and performing the service.

[00140] To that end, a list of candidate devices, identified by device ID, is generated as follows. Firstly, a“NearbyDevices” list is created and initially populated with the IDs of all proximate electronic devices (FIG. 22A, lines 16-17). In the present embodiment, the IDs are obtained from the repository of information regarding proximate electronic devices, i.e. from discovery object 1930. Optionally, the“NearbyDevices” list may include the ID of the mobile device making the untargeted service request, i.e., SenderUserlD, and thus the mobile device itself may be included among the candidate devices to perform the requested service.

[00141] Subsequently, a“FilterByService” function is applied to remove, from the NearbyDevices list, the ID of any device(s) that do(es) not provide the requested service (FIG. 22A, lines 19-201). To achieve this result, the FilterByService function may check whether the “devicePublic” object representing each of the nearby devices within discovery object 1930 contains a“servicePublic” object (see FIG. 13) representing the requested service, and if not, remove the corresponding device ID from the list.

[00142] Optionally, a“FilterByPermissions” function may be applied to remove, from the NearbyDevices list, the ID of any device(s) at which the user, identified by a unique “SenderUserlD,” does not have permission to access the requested service (FIG. 22A, lines 23- 25). This function may access user permissions information stored for each service of each device within the discovery object 1930.

[00143] At this stage, the NearbyDevices list will include the IDs of only candidate proximate electronic devices that could perform the service for the user 2l00/mobile device 1800 if so requested. The focus of the remainder of the operations in the UntargetedServiceRequest method is to determine how many and which of those candidate devices to instruct to perform the requested service.

[00144] Optionally, if the invoking mobile software application has specified an input target descriptor parameter (e.g.“all”) indicating that all proximate electronic devices should be targeted for providing the requested service, the ID of each proximate electronic device in the NearbyDevices list is included in the list of targeted devices (FIG. 22A, at lines 30-34).

[00145] Otherwise, the list of target devices is made to include only such proximate electronic devices from the“NearbyDevices” list that have descriptors matching at least one of the target descriptors (FIG. 22A, lines 35-42). In the present embodiment, this is achieved by matching at least one of the input parameter target location descriptors with a device location descriptor (from the discovery object 1930) associated with the proximate electronic device.

[00146] Notably, the target location descriptors may describe a targeted location using a different (e.g. finer) granularity than whatever device location descriptors may be stored within the discovery object 1930 in association with the proximate electronic devices. For example, if the location descriptor matching performed in the UntargetedServiceRequest method compares geohashes at a specified degree of co-location precision, that specified degree of co-location precision may be greater (finer granularity) than a degree of co-location precision used by the discovery server 1200 (see FIG. 2) to generate discovery object 1930. Alternatively, if the target location descriptor is in a natural language format (e.g.“#livingroom”), then the matching operation in the UntargetedServiceRequest method may match only those proximate electronic devices having a matching natural language device location descriptor, which may be a subset of all of the proximate electronic devices represented in the discovery object 1930 (e.g. matching a proximate electronic devices from the discovery object 1930 having a“#livingroom” natural language device location descriptor but not one having only a“#kitchen” natural language device location descriptor).

[00147] Optionally, the list of targeted proximate electronic devices may be sorted by a prioritization criterion to prioritize the proximate electronic devices for providing the requested service. In one example, the prioritization criterion may be an intrinsic characteristic of the devices, such as device screen size for example (e.g. as shown in FIG. 22B, at lines 1-2). For example, prioritizing devices having a small screen might result in selection of the laptop 1020 over the smart TV 1010 (see FIG. 1). In another example, the prioritization criterion may be an extrinsic characteristic of the devices, such as the presence, absence, or detected strength of a detected beacon signal at the location. In a further example, the extrinsic characteristic may be a relative position, e.g. left speaker versus right speaker.

[00148] In the present example, it is presumed that the smart TV 1010 (as represented in the discovery object 1930 by device object 2200 - see FIG. 13) is ultimately identified as a candidate device for presenting the slide deck. The identifying may have been based in part on a determination that the exposed“PlayVideo” service, as represented by service object 2202 within the discovery object 1930 (FIG. 13), is suitable for providing the desired service.

Moreover, execution of the“PreferredRoute” and“AvailableRoute” functions at lines 9 and 12 respectively of FIG. 22B has resulted in selection of Wi-Fi™ as the operative wireless communication modality for communicating the targeted requested to the proximate electronic device. In this embodiment, the“PreferredRoute” function returns the first route, i.e. wireless communication modality, stored the discovery object 1930 for the relevant device and service, whereas the“AvailableRoute” function returns the first available one of those routes.

[00149] The targeted service request 2108 (FIG. 21) is then dispatched, via the wireless transceiver 2014, using the operative medium-range or shorter wireless communication modality, to the smart TV 1010, to cause the requested service to be performed upon the service payload, i.e. to cause the slides to be presented at the TV (operation 2306, FIG. 23). In the present embodiment, the dispatching of the targeted request is effected by the TargetedServiceRequest method (FIG. 22B, line 15), which uses the device-specific addressing information stored in the discovery object 1930 (e.g. within route object 2208 of FIG. 13) to open a wireless communications session with the targeted device via the operative modality and then closes the session upon transmission of the mssage. In some embodiments, operation 2306 may entail the sending a targeted request to each device identified in a list of targeted device IDs, as shown in lines 4-21 of FIG. 22B.

[00150] Notably, the targeted service request 2108 does not, and indeed need not, include any of the TargetDescriptors from the untargeted service request 2106. The dispatcher 2012 may be considered to have translated those descriptors into device-specific addressing information for communicating, via a medium-range or shorter wireless communication modality, with the proximate electronic device(s) providing the requested service.

[00151] When the PlayVideo exposed service has been invoked (at operation 2306, FIG. 23), it may be considered that the sender software 1920 has automatically caused a wireless communication session to be established with smart TV 1010 using the pre-emptively stored Wi-Fi™ addressing information (SSSID001, passwordOOl - see object 2208, FIG. 13). This may be considered as an“activation” of virtual data cable 2310 for carrying data, which is depicted graphically in FIG. 15 by a heavier dotted line. In this way, the mobile device 1800 conserves power that would otherwise have been consumed in establishing a wireless communication session earlier, thereby extending battery life.

[00152] At the host device smart TV 1010, the receiver software 1608 responds to the mobile device’s invocation of the exposed service by performing the service at the host device. This may for example involve extracting the data payload (the slides) received from the mobile device 1800 and in turn executing an appropriate app at the TV 1010 for displaying the slides.

[00153] Advantageously, the slides are displayed at smart TV 1010 without requiring user 2100 to: connect any physical cable to the TV; ascertain any device information of the TV or any other device at location 1000; ascertain what wireless communication modalities are available the TV or any other device at location 1000; or to manually set up any wireless communication session or enter any security credentials. From the user’s perspective, the displaying of the slides at the nearby host device“just works” even if the user knows nothing about the host device or how to connect to it.

[00154] In the event that no suitable electronic device for providing a requested service is proximate, then the invocation of FIG. 24 may simply have no effect. Put another way, some untargeted service requests may fail to trigger corresponding targeted service requests. In that case, the mobile software application may behave as a standard standalone software application.

For example, the example slide presentation application 1902 of FIG. 9 may display the slides solely on a display of the mobile device 1800. Thus, the mechanisms described herein may permit a mobile software application to provide enhanced capabilities when suitable host devices are proximate and standard capabilities otherwise. In other words, the behaviour of a mobile software application may change or“morph” based on what host devices may be proximate.

[00155] Conveniently, and particularly from the perspective of the mobile software application developer, a single line of code, e.g. as shown in FIG. 24 for example, can be easily added wherever needed to facilitate invocation of a service at one or more proximate electronic devices. The developer is shielded from complex lower-level details, such as monitoring current mobile device location, checking for the presence of proximate electronic devices, or

determining what addressing information may be required to communicate with proximate devices wirelessly. That functionality is consolidated in the sender software 1920 for invocation as needed by any mobile software application executing at the mobile device 1800. This consolidation promotes efficiency at the mobile device, e.g. by avoiding duplication of such code in multiple software applications and thereby conserving memory space.

[00156] If the NumberOfDevices had been set to a number greater than one (e.g. two), then execution of the pseudocode at lines 4-21 of FIG. 22A would result in multiple targeted requests— one for each targeted host device. In that case, the slides might be displayed not only on smart TV 1010 as in FIG. 15, but also on laptop 1020. This may be considered as a form of multicast transmission.

[00157] Advantageously, because wireless communication session setup is automatic and transparent to the user, fewer cycles are expended at the mobile device for presenting whatever user prompts and graphical user interface screens might otherwise be required. Battery life may thereby be conserved.

[00158] For clarity, in cases where an“alternative route” (wireless communication modality) is to be used for wireless communication (see lines 10-13 of FIG. 22B), another wireless

transceiver (not expressly depicted), distinct from wireless transceiver 2014 of FIG. 21, may be required or used to effect the dispatching of the targeted service request 2108. [00159] When the location 1000 is an enclosed space to which access is controlled e.g. by mechanical lock, the above-described mechanism can be used to facilitate wireless access to exposed services at each host devices known to be within the same enclosed space. For example, such devices can be identified by a common location descriptors indicative of the enclosed space (e.g. #livingroom555MainStreet).

[00160] If the mobile device 1800 moves to a new location, operations 2000 of FIG. 11 and 2300 of FIG. 23 may be repeated, again transparently from the perspective of the user 2100. When newly generated discovery object 1930 for the new location is sent to the mobile device 1800, the sender software 1920 may refresh the existing discovery object in memory 1804 either by replacing it with the new discovery object or by supplementing the existing discovery object with any new device, service, or route information in the new discovery object. Upon re- execution of the operations 2300 of FIG. 23, the sender software 1920 can invoke the PlayVideo service at a different host device at the new location, providing a continuity of experience for the user 2100 as he moves about.

[00161] Various alternative embodiments are possible.

[00162] In some embodiments, the UntargetedServiceRequest method of the dispatcher 2102 (see FIGS. 22A, 22B) may be operable to add the device ID of the sender (mobile) device to the list of TargetDevices at the request of the invoking mobile software application. For example, if the UntargetedServiceRequest method receives a predetermined input target descriptor parameter (e.g.“#self’ or“#me”) among the received target descriptors, this may be understood to indicate that the mobile device itself should be included among the targeted electronic devices for providing the requested service. The relevant service may have an associated a route that points or loops back to the sender device non-wirelessly. The loopback may allow

communication without activating any wireless communication medium, e.g., via a loopback IP address 127.0.0.1.

[00163] In some embodiments, proximate electronic devices may be prioritized for providing a requested service based on an estimated proximity to the mobile device 1800, e.g. as indicated by periodic checks of RF signal strength, with more proximate devices being given higher priority. In some embodiments, proximate electronic devices may be prioritized on a service- specific basis, e.g. if different proximate electronic devices are of differing degrees of suitability for providing different services. The identification of a candidate device may be based on a priority or order established either at the discovery service 1200 or the sender mobile device 1800. If the order is established by the discovery server 1200, the discovery object 1930 may include an ordered list of devices for each service. Alternatively, one of multiple proximate electronic devices may be chosen at random.

[00164] In some embodiments, the repository of information regarding proximate electronic devices at the mobile device (e.g. discovery object) may include addressing information for communicating with a particular proximate electronic device using multiple medium-range or shorter wireless communication modalities (e.g. NFC, Bluetooth™, Wi-Fi™, etc.). In such embodiments, one of the wireless communication modalities may be selected over another based on a selection criterion which may vary between embodiments.

[00165] One example of a wireless communication modality selection criterion is wireless communication security. For example, a modality providing more secure transmission may be chosen in favor of a modality providing less secure transmission (e.g. encrypted Wi-Fi™ over unencrypted Wi-Fi™). Another example of a wireless communication modality selection criterion is wireless communication energy efficiency. For example, a modality reflecting lower energy consumption may be chosen over a modality reflecting higher energy consumption (e.g. NFC before Wi-Fi™). A further example of a wireless communication modality selection criterion is latency. For example, Bluetooth™ typically has lower latency than Wi-Fi™, which is desirable for some services (e.g., controlling a cursor on a receiver device) but less desirable for others. Yet another example of a wireless communication modality selection criterion is bandwidth. For example, Wi-Fi™ typically provides higher bandwidth than Bluetooth™, which is desirable for data-intensive applications such as streaming a video. The wireless

communication modality selection may thus depend on the nature of the particular service being requested.

[00166] Further, in some situations, a mobile device and a proximate electronic device could communicate by way of a first wireless communication modality for a first service, and at the same time, communicate by way of a second wireless communication modality for a second service.

[00167] In some embodiments, the dispatcher may base its selection of a proximate electronic device for providing a requested service on a targeted intrinsic devices characteristic, such as a class of device. For example, a mobile software application may specify, among the target descriptor parameters passed to a dispatcher (e.g. as at FIG. 24, line 4), a target device characteristic descriptor indicative of a desired class of device (e.g. #TV, #laptop, #tablet, or #thermostat). The dispatcher may use such descriptors of intrinsic target device characteristic to select a target device, e.g. by comparing the descriptors with analogous descriptors of intrinsic characteristics of the proximate electronic devices (which may be referred to as candidate device characteristic descriptors) that may be maintained for each device within the discovery object 1930.

[00168] In some embodiments, the configuration of an electronic device with one of receiver software 1608 and sender software 1920 may automatically also configure the device with the other (complementary) software. For convenience, the sender and receiver software may be packaged as a single APK and be downloaded/installed at the same time. This allows a single configuration step to be used to configure a device to act as either a receiver device, as a sender device, or both. It also permits a unique ID to be assigned to each participating device regardless of whether it is to be used as a sender device or as a receiver device.

[00169] In some embodiments, the discovery server 1200 may store, for each exposed service of each host device in host device records 1206, user permissions indicative of which specific users, or classes of users, shall have access to the exposed service. This information may be encoded in an object similar to that defined by the UML class diagram 1400 of FIG. 4.

[00170] In conjunction, the sender software 1920 may be modified to provide to the discovery server 1200 (as shown in FIG. 12) the user credentials of mobile device user 2100, e.g. as specified by the user via fields 2002 (FIG. 10) upon account creation. In turn, when generating the discovery object 1930, the discovery server 1200 may compare the user credentials with the stored user permissions for each exposed service at each proximate host device at the mobile device’s current location, to confirm that the user of mobile device 1800 has access to the exposed service. The discovery object 1930 may thereby be made to contain information only for exposed services to which the user 2100 is known to have access permission.

[00171] Alternatively, user permissions may be applied by the sender software 1920 in some embodiments. In particular, the sender software 1920 may control access to the exposed service by comparing the user credentials with the user permissions forming part the discovery object 1930 in association with each exposed service. Alternatively, or in conjunction, the user credentials may be supplied to the host device with each invocation of an exposed service, for user permissions verification at the host device.

[00172] Where access to exposed services is governed by user permission, a mobile device user may be able to access certain exposed services even before supplying any user credentials at a sender device. For example, before logging in via a GUI 1980 as shown in FIG. 10, the user of a sender device may still have access to certain exposed services whose user permissions permit anyone, including anonymous users, to access the service. Once the user logs into to a sender device, more services may become available according to user permissions.

[00173] In some embodiments, the discovery server may perform a co-location verification to confirm sender device co-location with a host device, before any information about the host device, or its services/routes, is included in the discovery object 1930. The co-location verification operation may be intended to reduce a risk of“spoofing” of a mobile device location for a nefarious purpose, e.g. gaining access to host devices at a location to which the mobile device user is not permitted entry. Various co-location approaches may be used.

[00174] In one approach, the mobile device may detect signatures carried by RF signals at its current location. The detected signatures may for example be carried by BLE advertisements, WiFi and/or NFC broadcasts from proximate electronic devices. All of the detected signatures at the location may be periodically reported to the discovery server, e.g. along with the periodic location descriptor updates.

[00175] At the discovery server 1200, database queries may be submitted to identify any host device for which the signatures are known to be used. A query result indicating a match can be used to verify that mobile device is indeed at the location of the host device whose signature was detected. The same approach can be used in the opposite direction, with host devices detecting unique signatures of any guest mobile devices broadcast via RF signals.

[00176] In some embodiments, the signatures that are used for co-location verification may be time-variable. For example, a signature carried by a BLE advertisement from a host device may change daily or hourly.

[00177] Signatures and/or descriptors that can also be used for co-location verification can include:

• ID of visible Bluetooth™ beacons or Bluetooth™ addresses (BD ADDR)

• NFC tags scanned

• Wi-Fi™ Access points visible (SSID + MAC Address of Access Point)

• Wi-Fi™ Access points connected (SSID + MAC Address of Access Point)

[00178] It will be appreciated that, while the mobile device 1800 of the above-described embodiment is smartphone, mobile devices in other embodiments may be other types of devices, such as tablets, portable gaming devices, or laptops, to name but several examples.

[00179] In other embodiments, the location may be something other than a room, such as an outdoor space enclosed by a fence; multiple adjacent rooms between which people may freely pass; a house; an office building; or an area within a building (e.g. a floor, conference area, or similar). A location need not necessarily be enclosed and may be a sub-location of another location or may further be logically and/or physically subdivided into other locations.

[00180] In the above-described embodiment, configuration of a host device with receiver software was described, in conjunction with operation 1626 of FIG. 6A, to involve determining a location of the host device and generating a location descriptor indicative thereof. In some embodiments, a host device’s location may be initially unknown (e.g., if a GPS receiver is not available). In such cases the host device’s location may be assigned by the discovery server as follows.

[00181] When the host device is encountered by a guest device, the received RF signatures of the host device and a location of the guest device (which usually has a GPS receiver) may be sent to the discovery server by the guest device as part of requesting a service tree. The location of the guest device is used as a guess/proxy for the location of the host device. The guessed location of the guest device may be refined over time as new guest devices encounter the host device, e.g., as a population average.

[00182] Devices need not have fixed locations to act as host devices. In that case, the techniques described in the preceding paragraphs can be used to keep the location of a host device current in the discovery database.

[00183] In some embodiments, receiver software also includes a route monitoring component that monitors the availability of routes. For example, routes may come and go as Wi-Fi™ access points are disabled or enabled, or if a Bluetooth™ antenna is manually disabled/enabled by the user. This may also be particularly relevant if the host device is in motion and comes within range of new access points. Changes in available routes are reported to the discovery server, which modifies the corresponding device’s record accordingly.

[00184] In some embodiments, another route that can be made available to route data between sender and receiver devices is by virtue of an intermediary such as the discovery server. This may be useful in some situations, e.g.: (1) when the receiver device only has 4G connectivity; (2) when it is undesirable for the sender and receiver to establish direct connections due to security considerations (e.g., do not wish to provide Wi-Fi™ access point password to any senders); or (3) unable to establish direct connections due to firewalls. The intermediary (e.g. discovery server) can be configured to only route messages for devices that are proximate.

[00185] FIG. 16 schematically illustrates another embodiment comprising a plurality of devices 10-1, 10-2, 10-3, 10-4, 10-5 (individually and collectively devices 10) in communication with a network 14 at a location 100. Further, a guest carrying a device 12 is illustrated.

[00186] As will become apparent, each device 10 has some computing capability, and may intercommunicate and be interoperable with some other devices, and preferably network 14. In embodiments, devices 10 may each be televisions, monitors, network enabled loud speakers, monitors, thermostats, or any other portable electronic device with processing and

communication capabilities. In at least some embodiments, devices as referred to herein can also include, without limitation, peripheral devices such as displays, printers, touchscreens, projectors, digital watches, cameras, digital scanners and other types of auxiliary devices that may communicate with another computing device. Devices 10 may be permanently, or semi permanently located at location 100, or may be transient to the location.

[00187] Network 14 may be a packet switched network and may include several local area, including for example a conventional local area network at location 100, and wide area networks, and may include the public internet. Network 14 may accordingly include suitable base stations (e.g. cellular base stations), routers, access points, network switches, and the like. Devices 10 and 12 may communicate with network 14 by way of a network interface which may take the form of a Wi-Fi or cellular network interface, for example, compliant with one or more wireless networking standards including the IEEE802.11 family of standards; GSM; GPRS; 3G; 4G; 5G; LTE; or similar standards.

[00188] Location 100 may be a suitable host environment, and may for example be a house, office building, room, or area within a building (e.g. a floor, conference area, etc.). Practically, devices at location 100 are geographically proximate - for example within several (e.g. 1-500) meters of each other. A location 100 may be a sub-location of another location 100, or may further be logically and/or physically subdivided into other locations.

[00189] In one example application, a guest may bring device 12 (which may be referred to as a guest device) into a host environment (e.g. to location 100) in which devices 10 provide computing or similar services (which may be referred to as host devices 10) are located.

Devices 10 may be accessed by guest device 12. The present disclosure discloses how the guest device 12 may discover and gain access to the services of devices 10-1, 10-2 ... 10-h in host environment 100.

[00190] In particular, as detailed below, relevant services available at devices 10 may be determined by matching descriptors of guest device 12 with descriptors of host devices 10 to a discovery server 20, also depicted in FIG. 16. These descriptors may be provided to discovery server 20 by discovery applications executing at each of devices 10/12.

[00191] FIG. 17 schematically depicts guest device 12. Example device 12 may be a cellular phone, cellular smart-phone, wireless organizer, pager, personal digital assistant, computer, laptop, handheld wireless communication device, wirelessly enabled notebook computer, portable gaming device, or tablet computers. Example device 12 may accordingly be based on a Qualcomm or MediaTek Labs reference design.

[00192] As illustrated, device 12 includes a processor 21, processor readable memory 27, and input/output (I/O) interface 23; a network interface 25; and a position receiver 29. Device 10 may further include touch display 50; one or more audio transducers 32.

[00193] Processor 21 may be a suitable computer processing subsystem and may include a numerical processor having multiple cores, and a graphics processor. In embodiments, processor 21 may be a RISC processor having an ARM based architecture, and may for example, be a suitable mobile processor manufactured by Qualcomm, MediaTek, Apple or the like. In other embodiments, processor 21 may be based on the x86 architecture. In yet other embodiments, processor 21 may be a custom processor.

[00194] Device 12 may further include a position receiver 29. In the depicted embodiment the position receiver 29 may be a receiver capable of receiving a satellite position signal, for example, from a global positioning (GPS) satellite 16 or other satellites such as one or more GNSS satellites. Alternatively, or additionally receiver 29 may receive an indoor positioning signal, from a suitable indoor positioning system (IPS). IPS systems are, for example, disclosed at https://en.wikipedia.org/wiki/Indoor_positioning_system. Positioning receiver 29 may further be capable of receiving a position signal and optionally a beacon signal from a known location. In the depicted embodiment position receiver 29 may be a relatively high accuracy location receiver - capable, for example, of determining the position of device 10 within several metres and preferably within the centimetre range. In alternate embodiments, position receiver 29 may be a combination of hardware and software capable of determining the location of device 10, using location services.

[00195] Touch display 30 may, for example, be capacitive display screens that include a touch sensing surface. Such a display may be integrated as a single component. Alternatively, touch display 30 may include suitably arranged separate display and touch components. Touch display 30 may be adapted for sensing a single touch, or alternatively, multiple touches simultaneously. Touch display 30 may sense touch by, for example, fingers, a stylus, or the like. Touch display 30 may return the coordinates of any touch or touches for use by a process or device 10.

Likewise, touch display 30 may be used to display pixelated graphics - in the form of computer rendered graphics, video and the like.

[00196] Network interface 25 may include one or more radios for data (and optional voice) communication with a complementary wireless network, using, for example, one or more wireless networking standards including the IEEE802.11 family of standards; GSM; GPRS; 3G; 4G; 5G; LTE; or similar standards. Network 25 may further include radios to allow for short range communication using, for example, Bluetooth or NFC protocols.

[00197] FIG. 18 schematically illustrates the organization of memory 27 at device 12 (or device 10). Broadly, memory 27 stores an operating system 34, which may for example, be a Unix based operating system (e.g. Android), an Apple iOS operating system, or other operating system; a discovery application 36, exemplary of embodiments; other applications 38; and data 39.

[00198] Devices 10 similarly include a processor, processor readable memory, and a network interface (not specifically illustrated), to allow intercommunication with network 14 and/or proximate devices 10 or 12, using shorter range communication protocols. As well, devices 10 may include suitable hardware (also not specifically illustrated) and host suitable software to provide one or more computing resources or services to other devices like device 12.

[00199] Each device 10, 12 may be associated with one or more descriptors that provide contextual information about each device 10, 12. Contextual information may include the capabilities of each device; services offered by each device; services required by each device; the location of each device; proximate devices; information about the operating environment of each device; the devices available applications, interfaces, resources and the like. [00200] As will become apparent, descriptors may be auto-generated based on observed states or attributes of each device 10, 12 or may be generated from user inputs. Descriptors may be stored locally within computer readable memory at device 10, 12 or remotely, for example at a network accessible server. To that end, a software application or service (referred to herein as a “discovery application 36”) may be executing at each device 10, 12 to gather contextual information and generate corresponding descriptors.

[00201] As will become apparent, in embodiments descriptors are or included natural language descriptors that may be easily understood by a human. Conveniently, use of natural language descriptor simplifies programming, and may allow know natural language processing and comparison techniques to be used in processing and/or comparing descriptors, as detailed herein.

[00202] For example, as noted, devices 10 may be located throughout location 100, and may be of various types, e.g., mobile phones, laptop computers, desktop computers, tablet computers, smart appliances, IoT devices, VR devices, etc. Each device 10 may be uniquely identified by a GUID (globally-unique identifier).

[00203] Each device 10 executes software to expose one or more services that may be accessed by device 12 to invoke certain functionality at device 10, under control of device 12.

[00204] A service may invoke various types of functionality. For example, functionality may be associated with a particular input interfaces at device 10, e.g., a sensor such as microphones, camera, etc.); a particular output interface at device 10, e.g., a display screen, a speaker, etc.; a particular software functionality (e.g., decoding/encoding a message, performing a calculation, installing a software application, etc.), a particular resource (e.g., storing data in memory of device 10); a particular software application (e.g., launching a browser to display a particular website, launching an application to display a text message or image); or a combination of the above (e.g., where the service invokes the functionality of a VR device comprising a

combination of various interfaces, resources, and software). Example services may, for example, allow the casting of audio of video from device 12.

[00205] A service may be associated with an application programming interface (API), network protocol, or other interface allowing device 12 to access an identified service.

[00206] Example descriptors at each of devices 10, 12 may describe:

the identity of device 10, 12 by unique identifier (e.g. GUID, IMEI or similar); the identity and attributes of a user associated with the device 10, 12, which may be pre defined and associated with the user’s credentials (e.g., name, gender, age, email address etc.);

the current location of device 10, 12 (e.g., GPS coordinates; room location; etc.);

the device’s surrounding, which may be sensed from sensors of device 12 (e.g., through audio sensors, proximity to certain devices or networks or other RF signals based on signal RF strength detected through RF antennas);

the current or intended activities of a user at a device (e.g. as gleaned from user interaction with device 12 such as applications executed at device 12) by the user or gleaned from data sensed from sensors of device 12, e.g., accelerometer, microphones, etc.;

external computing resources that could be used by applications running at device 12 (e.g. #display, and/or #audio, generated if an audio video application is executing at device 12); and/or

functionality desired by the user at device 12 (e.g. print services; display services; etc.) which may be requested by applications executing at device 12, etc.

[00207] In the depicted embodiment, each descriptor may take the form of a pre-defined text string, e.g., #johndoe, #walking, #youtube, #cooking, #sensedaudio, and may include information in natural language. The text string may encode certain data such as numerical data (e.g., GPS coordinates). The descriptors should be standardized so that discovery software application 36 at device 12 (and devices 10), as well as server 20 can discern which services are available at which device 10, and allow discovery and use of these services by device 12.

[00208] In some embodiments, the descriptors may be entered free-form, entered at device 10, 12. In other embodiments, these descriptors may be constrained by a pre-defined dictionary.

[00209] Some descriptors are generated automatically (e.g., based on sensor data gathered at device 10/12) at device 10/12, and other descriptors may be defined by the user, e.g.,

#livingroom to indicate that he/she is in the living room, #hungry to indicate that he/she is feeling hungry.

[00210] In the depicted embodiment, for example, an administrator or other user at location 100 may provide/input the physical room location of each device 10 within location 100. As well, relative signal strength of radio signals emanating from network 14, and other devices 10 may be determined at each device. Also, audio or motion may be sensed at devices 10. Corresponding descriptors may be created and stored, either at the device 10/12 or remotely.

[00211] Additionally, the execution of software applications at device 12, may give rise to the generation of descriptors of resources that could be used by an executing application. For example, an application that generates audio or video, could cause discovery application 36 to generate descriptors of device 12 advertising that the application at device 12 can present output at external devices having such functionality (e.g., #screen, #speakers). At the same time, one or more host devices 10 may have the same descriptors (e.g., #screen, #speakers) generated by their respective discovery applications 36 to advertise functionality (i.e., services) for receiving such output. These matching descriptors may be used by server 20 to match device 10 to guest device 12 in manners described herein. To facilitate processing of such output, further descriptors identifying the data format of such output, and/or the identity of the application that can provide the output (e.g. #youtube; #videoplayer; etc.)

[00212] Additionally, discovery software 36 may also echo descriptors received locally at device 12, from nearby devices 10. Such descriptors, may for example, be received by way of a local radio frequency signal (e.g. Bluetooth, NFC, infrared signal, etc.) that emanating at devices 10.

[00213] Guest device 12 compiles a list of descriptors, each describing an aspect of the user of guest device 12, or his/her circumstances or situation (graphically represented as descriptors #A, #B, #C, and #D in FIG. 16).

[00214] Collectively, the list of descriptors for a particular device (e.g. device 12) or user may be referred to as that user’s or device’s context 114. As will be appreciated, descriptors for device 12 may change over time, e.g., as the user or his/her circumstances or situation change. Accordingly, the user’s context (and the context of device 12) may also change dynamically.

[00215] To that end, a server 20 hosts a database 22 that allows location registration of each of devices 10 and 12 by way of network 14. Server 20 may be remote from location 100, and may be a conventional database server, and may therefore include a processor, memory storing database 22, processor executable instructions to access database 22, and to perform methods detailed herein. The database may be a relational database - such as an SQL database, or other database or datastore. Database 22 stores one or more database structures (e.g. database tables) that store device contexts 114, as further detailed below for each device 10 (and optionally device 12). A context 114-1, 114-2, ... H4-n for each device 10-1, 10-2 ... 10-h may be stored. Context 114-0 is associated with guest device 12. Individually and collectively contexts 114- 0,114-1, 114-2 ... 114-h are referred to as context(s) 114, herein.

[00216] As will be appreciated, database 22 may be updated periodically (i.e. at defined intervals) and will allow querying of device contexts 114; and other searching and manipulation of data stored at database 22, using suitable program instructions at server 20.

[00217] Conveniently, the use of standardized descriptors in a defined format, allows querying and comparing of contexts 114 to identify desired services at server 20.

[00218] Additionally, device 12 and/or devices 10 may periodically broadcast its context, or portions thereof (e.g. select descriptors) locally, to allow proximate devices 12/10 to ascertain such descriptors. Such broadcast may, for example, be performed by a radio interface using protocol for the transmission of local signals (e.g. NFC, Bluetooth, etc.) For example, in one specific example, a host device 10 may periodically broadcast a descriptor descriptive of its location (e.g., #bedroom, #livingroom, etc.). This location descriptor may be received by a proximate guest device 12 and then echoed at device 12, i.e., included within device l2’s own descriptors. In this way, device 12 indicates that it is also at the described location, using a descriptor that was not pre-defmed or stored at device 12 prior to arriving at the described location. The matching location descriptors may be used by server 20 to match device 10 to guest device 12 in manners described herein.

[00219] FIG. 19 and 20 depicts a user (e.g. a guest at location 100) operating a personal portable electronic device 12. Device 12 is typically a user/guest’s cellphone, but could also be another type of portable device such as a wearable device, a tablet device, or another portable computing device (e.g., a laptop). Device 12 is typically authenticated on network 14 with the user’s credentials and typically travels with the user. Accordingly, device 12 may, in some respects, be viewed as a proxy for the user. For example, the location of device 12 may be used as a stand-in for the location of the user; sensors at device 12 may be used to estimate the current activities engaged in by the user (e.g., the microphone can be used to determine whether the user is engaged in conversation, the gyroscope and/or accelerometer can be used to determine whether the user is walking, jogging, etc., changes in the GPS location of the device can be used to determine whether the user is driving); applications at device 12 may be used to determine activities intended by the user (e.g., launching a video player application may indicate that the user intends to watch a video). [00220] Device 12 compiles a list of descriptors, each descriptor describing an aspect of the user or his/her circumstances or situation (graphically represented as descriptors #A, #B, #C, and #D forming context 114-0 in FIG. 19).

[00221] Device 10-1 similarly compiles descriptors #A, #B; device 10-3 compiles descriptor #F; device 10-2 descriptors #B, #E. These, in turn, define contexts 114-1, 114-2, and 114-3, respectively.

[00222] As noted, descriptors for a particular device 10/12 may be referred to as that device’s context 114, which may be stored at database 22. As will be appreciated, the descriptors may change over time, e.g., as the user or his/her circumstances or situation change. Accordingly, for example, context 114-0 of device 12 changes dynamically.

[00223] Again, select descriptors may also be broadcasted locally at device 10/12.

[00224] FIG. 19 also depicts remote server 20 (which may also be referred to as a“discovery server”) processes information regarding (i) the context 114-0 of a particular user and his/her device 12, and (ii) the respective contexts 114 of other devices 10, that execute exemplary discovery software 36 (FIG 18).

[00225] As the location of device 12 changes, the context for device 12 will change, reflecting a change in the user’s environment. As device 12 enters location 100, its context may reflect the presence of other devices 10 (e.g. device 10-1, 10-2 and 10-3 in FIG. 4). For example, as device 12 enters location 100, its GPS coordinates may reflect this. Similarly, device 12 may sense RF signals associated with Wi-Fi or similar access points at location 100. Device 12 may also sense other local RF signals - including Bluetooth or NFC signals emitted by devices 10. Each of these pieces of contextual information may be converted into a descriptor that forms part of the context 114-0 for device 12 at location 100.

[00226] As noted, server 20 maintains database 22 containing records of various devices 10, 12 and for each device 10, 12 its unique ID, and its context 114, and its services, as well as information for addressing/accessing those devices and services (e.g., IP addresses, protocol information, security access tokens, etc.). Server 20 may occasionally receive updates from devices 10, 12 reflecting changes to the context 114 associated with each device 10, 12. This may occur as device 12 enters location 100.

[00227] Device 12 and server 20 may collaborate to perform discovery of devices 10 and services provided at those devices 10 that are relevant to a particular user at device 12.

[00228] Server 20 may then provide device 12 with a list of relevant devices 10 and services provided at those devices, as well as information for addressing/accessing those devices and services.

[00229] As shown in FIG. 19 to initiate the discovery process at location 100, guest device 12 under control of discovery software 36, transmits context 114-0 of guest device 12 to server 20 over network 14. Device 12 may also transmit data to server 20 that allows for verification of credentials of user 10 and/or device 12.

[00230] Server 20 may then match context 114-0 to stored device contexts 114 of devices 10 to find those of devices 10 relevant to the user at device 12. Various ways of performing this match are possible. For example, a device 10 may be matched to a user at device 12 if their respective contexts shares at least one descriptor in common. Or a device 10 may matched to guest device 12 if their respective contexts share at least a defined number of descriptors in common. Or a device may be matched to a user if their respective contexts have the same descriptors.

[00231] In the case of purely textual descriptors, a match may be found if the text is the same.

In the case of descriptors that encode numerical values, the numerical values can be extracted and then checked to determine whether the values are within a certain range. For example, two descriptors encoding GPS coordinates may be considered the same if the coordinates are within a pre-defmed range (e.g., 20 feet, 100 feet, etc.).

[00232] Upon determining matching devices 114, server 20 may create a discovery object 250 and transmits it to device 12. Discovery object 250 includes data allowing device 12 to address/access devices 114 and its services (e.g., IP addresses, protocol information, security access tokens, etc.).

[00233] For example, as shown in FIG. 19, discovery object 250 may contain a list of devices 10 which were found to match the context 114-0 of guest device 12, as well as a list of the services at those devices. For example, discovery object 250 may contain API information and API parameters for invoking particular services at one or more of devices 10.

[00234] As shown in FIG. 20, guest device 12 was matched to devices 10-1 and device 10-2, but not device 10-3, as context 114-0 shares common descriptors #A and #B with context 114-1; context 114-0 shares common descriptors #B and #E with context 114-2. [00235] Discovery object 250 accordingly identifies devices 10-1 and 10-2 and associated services, and sufficient information to allow device 12 to access these. A user at guest device 12 can then, through device 12, invoke the functionality provided by services at device 10-1 and 10-2, e.g., by wireless communication to those devices, either directly, or by way of a portion of network 14 (e.g. by way of a local area network at location 100).

[00236] In the embodiments described above, a context 114 is provided for each particular device 10/12. In some embodiments, a context (i.e., a set of descriptors) may be provided for each service at device 10. In such embodiments, server 20 may match a context 114 of a guest device 12 to contexts of particular services.

[00237] Descriptors described above may be organized into three categories:

(1) User-defined descriptors, which are manually defined by a user of the device, the user typically being the device’s owner or administrator.

(2) Intrinsic device descriptors, which are automatically sensed and defined and describe intrinsic characteristics of the device such as, e.g., the type of device (tablet, phone, TV, etc.), any of its specifications (screen size, screen resolution), applications

installed/executing on the device.

(3) Extrinsic device descriptors, which are automatically sensed and defined and relate to extrinsic characteristics of the device such as its location and characteristics of its environment, e.g., GPS coordinates, strength of measured wireless signals, ID of wireless broadcasters in the environment. Such IDs may, for example, include:

ID of visible Bluetooth beacons;

NFC tags scanned;

Wi-Fi™ Access Points visible; and

Wireless network connected.

[00238] In an embodiment, one or more extrinsic device descriptors may optionally be used as a signature for confirming whether a particular device 12 (which may be a guest device) is in a particular environment (which may be a host environment), e.g., to confirm that device 12 and that devices 10 providing accessible services are co-located in the same environment.

[00239] Access to services may be restricted to those devices that can present a device context 114 that includes a pre-defined expected signature. For example, a device 12 that presents a context 114 lacking the expected signature will fail to discover certain services; namely, server will not include those services in the discovery object 250 returned to the device. In some embodiments, the presented signature may be allowed to deviate from the expected signature by a pre-defmed margin (e.g., only a subset of the descriptors must match). Whether or not a service is access-restricted in this manner may be toggled per device, or per service.

[00240] Descriptors forming the signature may be kept hidden from the user to prevent them from being used on devices other than the particular device that sensed the descriptors.

Accordingly, these descriptors may be referred to as“private” or“secret” descriptors.

[00241] In some embodiments, a beacon may be placed in an environment that emits a time- varying signal (e.g., a signal encoding a code that changes from time to time). The signal may for example be a Bluetooth transmission such as a Bluetooth low energy (BLE) beacon. In an embodiment, the strength of this signal may be controllable, and its range defines the extent of a particular environment (e.g., a room or a building) in which access to particular services is granted.

[00242] In these embodiments, the expected signature includes a descriptor that is the code encoded in the beacon signal (or derived from the code). Accordingly, only devices within the range of the beacon signal will be able to present the expected signature. The expected signature and the corresponding beacon signal change from time to time (e.g., every few minutes, every hour, etc.) to prevent later use or re-use of a received code.

[00243] In a further embodiment, a device (e.g. device 12) may be configured to periodically (e.g., every second) advertise its unique device ID for receipt by devices within an environment (e.g., devices 10). For example, the advertisement may be made by way of a Bluetooth Low Energy (BLE) advertisement using the iBeacon protocol.

[00244] As a user at device 12 enters and moves around the location 100, the unique device ID advertised by device 12 will be received by one or more of the devices 10 which periodically listen for advertisements (e.g., every 5-10 seconds).

[00245] For example, the ID of device 12 will become part of the private context of that device 10-1, which in return is reported to discovery server 20. Server 20 may then uses presence of device 12 by way of its ID in device 10- 1 s private context to verify that the two devices are co located. [00246] In an embodiment, server 20 may requires verification of co-location in this manner before allowing device 12 to discover device 10 or any of its services. In an embodiment, verification of co-location using the private context reported by one device 10 may be used by server 20 to control discovery of several other devices 10 (and their services) by device 12. For example, all devices 10 in location 100 (room, building, etc.) may be discoverable by device 12 if any one device 10 in that environment reports to server 20 a private context containing the unique ID of device 12.

[00247] In a further embodiment, each device 10 is configured to periodically advertise its unique device ID, which may be received by a device 12 and included in its context 114. In this embodiment, server 20 may restrict discovery to when the unique device ID of device 12 is present in the context 114 of a device 10 and reciprocally the unique ID of the device 10 is presented in the private context of device 12 (e.g., when the devices“see” one another).

[00248] In some embodiments, other forms of wireless advertisement may be used in addition to or instead of BLE advertisements. For example, Wi-Fi™ and/or NFC broadcasts may be used.

[00249] The following clauses provided a further description of example embodiments.

[00250] Clause 1 : A method of locating interoperable devices at a location, comprising:

receiving from each host device at the location a list of descriptors about each host device, and storing the lists at a discovery server; receiving from a guest device a list of descriptors of the guest device, over a network to the discovery server; receiving from the guest device a query, over the network, to the discovery server; in response to the query, comparing the list of descriptors of the guest device to the lists of descriptors of the host devices to identify a set proximate interoperable devices at the location; and providing identifiers of services of the set of proximate devices to the guest device.

[00251] Clause 2: The method of clause 1, wherein the list of descriptors received from the guest device includes an identifier of services to be used by at least one application executing at the guest device.

[00252] Clause 3: The method of clause 1, wherein the list of descriptors received from the guest device includes descriptors of at least one of the host devices, received locally at the guest device.

[00253] Clause 4: The method of clause 3, wherein descriptors of at least one of the host devices, received locally at the guest device by way of a radio signal from the at least one host device.

[00254] Clause 5: The method of clause 1, wherein the list of descriptors about each host device includes an identification of services at each host device. [00255] Clause 6: The method of clause 2, wherein proximate interoperable devices provide the list of descriptors about each host device include an identification of services at each host device accessible by said guest device.

[00256] Clause 7: The method of clause 1, wherein each of said descriptors of said host devices includes natural language describing contextual information about an associated one of said host devices.

[00257] Clause 8: The method of clause 1, wherein said comparing the descriptors of the guest device to the lists of descriptors of the host devices comprises locating at least one identical descriptor in a list of descriptors of one of the host devices, and in the descriptors of the guest device. [00258] Clause 9: The method of clause 1, further comprising receiving an updated list of descriptors from the guest device, as the guest device moves at the location.

[00259] Clause 10: The method of clause 1, wherein said list of descriptors of the guest device includes at least one of the coordinates of the guest device; identity of the guest device; IDs of visible radio beacons; an identification of NFC tags scanned; identifiers of WiFi access points visible; and an identifier of a connected wireless network.

[00260] Of course, the above described embodiments are intended to be illustrative only and in no way limiting. The described embodiments are susceptible to many modifications of form, arrangement of parts, details and order of operation. The invention is intended to encompass all such modification within its scope, as defined by the claims.