Systems and methods for establishing highly secure and resilient persistent communication connections

Abstract

Systems and methods for providing resilient persistent connections for communications are disclosed. The method includes: identifying, at a first device, a second device registered with a client connection service; obtaining, from the client connection service, a first resource identifier for delivering a request message to the second device via the client connection service; identifying, based on the obtained first resource identifier, a first target resource for a first request message directed to the second device, wherein the first target resource designates a first host included in the client connection service; sending, via a data communication network, the first request message to the first target resource at the client connection service for delivery to the second device by the client connection service; and receiving, via the data communication network, from the client connection service, a first response message provided by the second device as a response to the first request message.

Description

BACKGROUND OF THE INVENTION

[0001] Data communication between client devices in close proximity to each other is often required. Near field communication technologies have become a common solution for such communication. Examples include Bluetooth, Bluetooth Low Energy (BLE), and Wi-Fi technologies. However, these technologies are generally not secure and not resilient (e.g., they do not provide high availability for scenarios with connection stability issues). New and improved methods for communication are desired. SUMMARY OF THE INVENTION

[0002] According to a first aspect of the present disclosure, a first device adapted to communicate via a client connection service includes a processor and a machine-readable medium storing instructions that, when executed by the processor, cause the first device to: identify a second device registered with the client connection service, where the second device is different from the first device. The instructions may also cause the first device to: obtain, via a data communication network, from the client connection service a first resource identifier for delivering a request message to the second device via the client connection service. Additionally, the instructions may cause the first device to: identify, based on the obtained first resource identifier, a first target resource for a first request message directed to the second device, where the first target resource designates a first host included in the client connection service. The instructions also cause the first device to: send, via the data communication network, the first request message to the first target resource at the client connection service for delivery by the client connection service to the second device. Similarly, the instructions cause the one or more processors to receive, via the data communication network, from the client connection service a first response message provided by the second device in response to the first request message.

[0003] According to a second aspect of the present disclosure, a method for communicating between devices via a client connection service includes: identifying, at a first device, a second device registered with the client connection service, wherein the second device is different from the first device. The method may also include: obtaining, at the first device via a data communication network, a first resource identifier from the client connection service for delivering a request message to the second device via the client connection service. The method may further include: identifying, at the first device, a first target resource for a first request message directed to the second device based on the obtained first resource identifier, wherein the first target resource designates a first host included in the client connection service. Additionally, the method includes: sending, by the first device via the data communication network, the first request message to the first target resource to the client connection service for delivery to the second device by the client connection service. Similarly, the method includes: receiving, at the first device via the data communication network, a first response message provided by the second device as a response to the first request message from the client connection service.

[0004] According to a third aspect of the present disclosure, a method for communicating between devices via a client connection service includes: allocating, by the client connection service, a first resource to a first device. The method may also include: receiving, at the client connection service, a first request message sent by a second device to a first target resource, wherein the second device is different from the first device. The method may further include: selecting the first device based on the first target resource corresponding to the first resource. Additionally, the method includes: generating, by the client connection service, a first forwarding request message based on the received first request message. Similarly, the method includes: transmitting, via a first transmission channel, the first forwarding request message from the client connection service to the first device. The method may further include: receiving, at the client connection service via the first transmission channel, a first response message to the first forwarding request message from the first device. The method also includes: sending, from the client connection service to the second device, a second response message generated based on the first response message as a response to the first request message.

[0005] The present invention content is provided to introduce a selection of concepts in a simplified form that will be further described in the detailed description below. The present invention content is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to solving any or all of the disadvantages noted in any part of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The accompanying drawings depict one or more implementations in accordance with the present teachings by way of example and not limitation. In the figures, like reference numerals refer to the same or similar elements. Additionally, it should be understood that the drawings are not necessarily drawn to scale.

[0007] Figure 1A and Figure 1B illustrates an example of a client connection service for establishing a connection between two user computing devices to exchange messages between the two user computing devices;

[0008] Figure 2 illustrates an example of a system for establishing a secure and resilient persistent network connection for communication;

[0009] Figure 3 illustrates an example where the first instance and the second instance shown in Figure 1A , Figure 1B and Figure 2 are respectively bound to and registered with the client connection service;

[0010] Figure 4 illustrates an example of a pairing process between the first instance and the second instance that is executed via the client connection service and initiated by the second instance;

[0011] Figure 5 illustrates an example of a client connection service that is used to forward requests and corresponding responses between the first instance and the second instance paired in Figure 4 ;

[0012] Figure 6 illustrates an example where the client connection service reassigns the first instance from a first resource to a different second resource and the first instance conveys changes to the new second resource to the second instance;

[0013] Figure 7 illustrates an example where the first instance is unable to convey an updated resource identifier to the second instance in the same manner as shown in Figure 6 and the second instance recovers from an initial misuse of an outdated resource identifier for communicating with the first instance;

[0014] Figure 8A and Figure 8B illustrates an example where a second user initiates a projection session of an electronic content item from a fourth device to a third device;

[0015] Figure 8C illustrates an example of a system for establishing a secure and resilient persistent network connection between a user device and a target device;

[0016] Figure 9 Illustrates an example of a pairing process between two instances executed via the client connection service shown in FIG. 8;

[0017] Figure 10 Illustrates an example for periodically updating the secrets required for communicating with a paired device;

[0018] Figure 11 Is a flowchart illustrating an implementation manner of an exemplary process for communicating between instances via the client connection service;

[0019] Figure 12 Is a flowchart illustrating an implementation manner of an exemplary process for communicating between instances via the client connection service;

[0020] Figure 13 Is a block diagram illustrating an exemplary software architecture, each part of which can be used in combination with various hardware architectures described herein, and the hardware architectures can implement any of the features described herein; and

[0021] Figure 14 Is a block diagram illustrating components of an exemplary machine configured to read instructions from a machine-readable medium and execute any of the features described herein. Detailed Description

[0022] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the teachings may be practiced without such details. In other instances, well-known methods, procedures, components, and / or circuits have been described at a relatively high level without detail in order to avoid unnecessarily obscuring aspects of the teachings. In the following material, directional indications (such as "top" or "left") are provided merely to provide a reference frame during the following discussion and are not intended to indicate a required, desired, or expected direction of the item being described.

[0023] Figure 1A and Figure 1BThe figure illustrates an example where the client connection service 106 (labeled "connection service") is used to establish a connection between two user computing devices 130 and 132 for exchanging messages between the two user computing devices 130 and 132. The term "user computing device" refers to a computing device oriented towards an end user, and it is typically assumed that a single user uses the device at a given time. For example, a software program running on a user computing device may need to provide a password or other credentials to access resources associated with a user account. In some examples, a user computing device can support multiple such user accounts, thereby allowing different users to "log in" to the device at their respective times. In some examples, a user computing device can support a single user account; for example, most smartphone devices are assumed to be used in conjunction with a single individual. A "user computing device" can be more simply referred to as a "device".

[0024] In the specific example shown in FIG. 1, the first device 130 is a portable computing device in the form of a notebook or laptop computing device, and the second device 132 is a desktop computing device including a touch screen, a camera, a microphone, and a speaker. However, it should be understood that the first device 130 and / or the second device 132 can be implemented in other forms. In some examples, a user computing device provides capabilities that another user computing device does not provide. For example, in FIG. 1, the first device 130 includes a physical keyboard, while the second device 132 does not include a physical keyboard. As another example, the second device 130 includes a touch screen, while the first device 132 does not include a touch screen.

[0025] A first software program instance 131 (which may be referred to as a "software instance", an "application", or an "app" in some examples) is being run by a first device 130. Additionally, the first instance 131 is configured to interact with a client connection service 106 via one or more networks in conjunction with a first user identifier associated with a first user 120. Such interaction may include, for example, commands and / or data sent and received between the first instance 131 and the client connection service 106 to implement aspects of the techniques described herein. These interactions may be implemented, for example, via a persistent connection, asynchronous communication, and / or polling for transmitting messages 102 (labeled "MSG") between the first instance 131 running on the first device 130 and the client connection service 106. It should be understood that references to user computing devices that interact with or are configured to interact with the client connection service 106 occur via corresponding configured software program instances run by the user computing devices. Additionally, a second device 132 is running a second software program instance 133. Very similarly to what was described for the first instance 131, the second instance 133 is configured to interact with the client connection service 106 via one or more networks in conjunction with the user identifier for the first user 120. Thus, in Figure 1A the example shown, both the first device 130 and the second device 132 are configured to interact with the client connection service 106 and to interact with the client connection service 106 in conjunction with the first user 120.

[0026] In some implementations, a user may perform a pairing process to identify user computing devices and / or instances as eligible to pair with each other. In Figure 1A the example shown, the first instance 131 running on the first device 130 and the second instance 133 running on the second device 132 have been identified as eligible to pair together. A set of user computing devices and / or instances that have been paired via the pairing process may be referred to as an "active pairing" and are included together in the active pairing set for the duration of the period in which the set of devices and / or instances is able to communicate actively via the client connection service 106. In some examples, a set of user computing devices and / or instances may transition to or from an active pairing based on their proximity to each other and / or a common user.

[0027] A system including devices 130 and 132 and a client connection service 106 is configured to control the presentation of the user interface of instances for various activities based on whether the involved instances are actively paired during an associated time period. In some examples, the user interface presented by the instance via the user computing device can be modified in response to the system identifying that the instance has transitioned between not being actively paired and being actively paired (including but not limited to: adding displayed user interface (UI) elements, removing displayed UI elements, and / or changing the appearance of the displayed UI elements). The system is also configured to control the behavior of the instance based on whether the instance is actively paired during the associated time period.

[0028] In Figure 1A and Figure 1B In the specific example shown, the first user 120 is interacting with multiple other users in a teleconference session. The teleconference session involves the capture and transmission of video and audio media streams for distribution to other participants, as well as the reception and presentation of the video and audio media streams of other participants. The teleconference session can provide additional capabilities via the teleconference session, such as but not limited to projecting display and / or application content to and / or from other participants.

[0029] Figure 1A and Figure 1B Illustrates a first example of a system that performs unified UI interactions for user activities across multiple instances included in an active pairing set, where using a UI control presented by a first instance 131 causes an instance running on a second device 132 to join as an endpoint of a teleconference session. The first instance 131 is configured to interact with a teleconference service, such as accessing session records and participating in a teleconference session. For example, the first instance 131 can incorporate various features of Microsoft Teams TM for the Microsoft Windows TM 10 operating system. The second instance 133 is configured to interact with the teleconference service. In this example, the second instance 133 is configured to provide a "home screen" interface for the second device 132.

[0030] In Figure 1AIn this case, the first UI 112 is presented by the first instance 133 on the first display 134 (which is included in the first device 130), and is displaying the agenda of the scheduled teleconference session for the first user 120. The first UI 112 includes the scheduled teleconference session UI elements 114. The UI element 114 includes the first session join UI control 116 (labeled "Join"), which can be used to add the first user 120 as a participant to the ongoing teleconference session, where four other participants have already joined. Additionally, the second UI 126 is presented by the second instance 133 on the second display 136 (which is included in the second device 132) to provide a "home screen" interface. In this particular example, the second UI 322 includes the second session join UI control 128 (labeled "Join"), which can also be used to add the first user 120 as a participant to the teleconference session.

[0031] Figure 1B The figure illustrates the result of the first user 120 actuating the first session join UI control 116 by using the pointer 118 shown in Figure 1A The system is configured to process the actuation of the first session join UI control 116 based at least on whether the first device 130 is included in the active pairing set. In response to the first device 130 being included in the active pairing set, the system causes, for example via the second instance 133, the fourth instance 137 running on the second device 132 to operate as an audio-visual endpoint for the first user 120 to participate in the teleconference session. In some examples, the fourth instance 137 is configured to transmit messages by using the second instance 133 via the client connection service 106.

[0032] The fourth instance 137 is also configured to: receive and present incoming real-time media for a conference call session, present the real-time video included in the incoming real-time media in a corresponding area of the third UI 140 on the second display 136, and present the real-time audio included in the incoming real-time media via a speaker included in the second device 132. Thus, although the first session join UI control 116 presented on the first device 130 is used to initiate joining the first user 120 to the conference call session, the visual and audio presentation of the remote participants and the video and audio capture of the first user 120 are performed by the second device 132 based on the actively paired first instance 131 and second instance 133. Additionally, the third UI 140 includes a first session UI control 142, and the first session UI control 142 includes controls for, for example, switching the video transmission of the first user 120, switching the audio transmission of the first user 120, adjusting the volume of the audio presented to the first user 120, and / or ending the participation of the first user 120 in the conference call session. Thus, the second device 132 can operate as a focal center of the conference call session while leaving the first device 130 idle for other activities, including activities unrelated to the conference call session.

[0033] As an example, in response to actuation of the first session join UI control 116 and determining that the first instance 131 and the second instance 133 are actively paired, the first instance 131 can transmit a first message 102 to the second instance 133 via the client connection service 106, where the first message 102 reflects the actuation of the first session join UI control 116. Then, in response to determining that the first instance 131 and the second instance 133 are actively paired and receiving the first message 102, the second instance 133 causes the second device 132 to operate using the fourth instance 137 as an audiovisual endpoint. Similarly, actuation of the controls included in the first session UI control 142 can cause the fourth instance 137 (e.g., via the second instance 133) to send a message 105 to the first instance 131 via the client connection service 106. It should be understood that other schemes involving the exchange of messages between the first device 130 and the second device 132 and determined by the first device 130 and the second device 132 can be applied to achieve the same effect.

[0034] Note that the first device 130 and the second device 132 are each configured to operate as an audiovisual endpoint when not paired. Thus, based on determining that the first instance 131 is not actively paired, actuation of the first session join UI control 116 will instead cause the first device 130 to operate as an audiovisual endpoint of the conference call session, as for Figure 1Bas shown by the second device 132 in. Similarly, based on determining that the second instance 133 is not actively paired, actuating the second session join UI control 128 will cause the second device 132 to operate as an audio-visual endpoint for the conference call session.

[0035] In addition, in Figure 1B while maintaining the second device 132 as the primary audio-visual endpoint of the conference call session, a projected portion of the conference call session initiated by a remote participant is presented via the first device 130. The projected portion can include, for example, a portion of the remote participant's display of "screen projection", but other projection techniques can be used. Various scenarios determined by messages 103 and 105 exchanged between the first instance 131 and the second instance 133 and / or the fourth instance 137 and the first instance 131 and the second instance 133 and / or the fourth instance 137 can be used. For example, using messages 103 and 105 sent via the client connection service 106, the fourth instance 137 can initially be notified of the projected portion and negotiate with the first instance 131 to present the projected portion on the first device 130.

[0036] In this example, the third instance 135 is configured to receive and respond (e.g., by presenting visual projection content 154 for the projected portion on the first display 134). The fifth software program instance 310 (but different software programs can be used) is configured to present a fourth UI 150 including a content display area 152, in which the visual projection content 154 included in the projection data is presented.

[0037] In addition, in some implementations, the third instance 135 is configured to also present a second session UI control 160 on the first display 134, which is very similar to that described for the first session UI control 142. The second session UI control 160 can include, for example, a control 171 for switching the video transmission of the first user 120, a control 172 for switching the audio transmission of the first user 120, and / or a control for ending the participation of the first user 120 in the conference call session. In response to actuating any of the controls 171, 172, and 173, a corresponding message 103 reflecting the control actuation is sent by the first device 130 via the client connection service 106 to the second device 132, thereby causing the fourth instance 137 to perform the corresponding action. Thus, using communication via the client connection service 106, the user 120 can easily submit commands to control the conference call session via the first device 130 in addition to the second device 132. This achieves an improved, more dynamic, and more flexible user experience for the first user 120.

[0038] Figure 2Illustrated is an example of a system 200 for establishing a secure and resilient persistent network connection for communication. In Figure 2 the example shown, system 200 can associate both a first device 202 and a second device 132 with a first user 120. For example, first user 120 may have performed a login process on first device 130 and / or second device 132, such as by using an authentication service 223 (which may be included in service 200 in some implementations). Authentication service 223 may be referred to as an "identity provider" or "identity service". In some examples, as shown in Figure 2 system 200 supports multiple users and associated devices, including additional user 226 and associated additional device 228, including supporting connections and communications between first device 130, second device 132, and / or various additional devices 228. First device 130, second device 132, additional devices 228, authentication service 223, and client connection service 106 are each configured to communicate with other parts of system 200 via one or more data communication networks 224, including the (one or more) networks 108 in Figure 1A and Figure 1B .

[0039] Authentication service 223 is configured to identify and authenticate user accounts associated with user computing devices. For example, authentication service 223 may be configured to receive and process credentials in the form of a username and password hash. In some implementations, authentication service 223 supports the use of credentials obtained from an external authentication service (e.g., a token issued by a single sign-on (SSO) service), and may associate the user identifiers provided by such a service with their respective user accounts. In some implementations, authentication service 223 is configured to issue an access token to a device that has been successfully authenticated, and service 200 is configured to receive and process the access token in subsequent communications with the device for authentication and / or authorization operations. In some implementations, authentication service 223 is configured to receive and respond to requests to verify that an access token remains valid or unexpired. In some implementations, authentication service 223 is configured to receive and process requests to "refresh" or "extend" an access token, thereby extending the expiration time of the access token.

[0040] The first device 130 includes a first operating environment 202, wherein a first software program instance 131 is run by the first device 130. Other software program instances may be run by the first device 130 within the first operating environment 202 and / or other operating environments provided by the first device 130. Similarly, the second device 132 includes a second operating environment 212, wherein a second software program instance 133 is run by the second device 132. As will be described in more detail in connection with the drawings below, for each peer instance of the first instance 131, the first instance 131 maintains a corresponding first peer resource identifier 204 (labeled "peer RSCID") and a corresponding first peer persistent identifier 206 (labeled "peer persistent ID"). Similarly, for each peer instance of the second instance 133, the second instance 133 maintains a corresponding second peer resource identifier 214 and a corresponding second peer persistent identifier 216.

[0041] The client connection service 106 includes a transport service 240 and a registration service 260. The transport service 240 is configured to provide a network-accessible resource for exchanging messages between software program instances (such as between two peer instances). To receive forwarded messages via the transport service 240, an instance binds itself to the transport service 240. The transport service 240 is configured to maintain an instance record 242 for the bound instance, with a corresponding instance record 244 for each bound instance. Figure 2 Illustrated are a first instance record 244a for the first instance 131 and a second instance record 244b for the second instance 133. As will be described in more detail in connection with the drawings below, the first instance record 244a may include a first user identifier 246a (labeled "user ID") for the user associated with the first instance 131, a first transport channel information 248a (labeled "transport INFO") including information used by the transport service 240 to establish and / or maintain a network connection for exchanging messages with the bound example, a first resource identifier 250a (labeled "RSC ID") identifying the resources assigned to the bound instance, a first resource validity period 252a (labeled "RSC validity") indicating the lifecycle of the resource identifier, and / or a first allowed peer target 254a identifying the target to which the transport service 240 will forward messages to the bound instance. Similarly, the second instance record 244b includes a second user identifier 246b, a second transport channel information 248b, a second resource identifier 250b, a second first resource validity period 252b, and / or a second allowed peer target 254b. For purposes of discussion, the first and second user identifiers 246a and 246b are the same.

[0042] The client connection service 106 may also include a registry service 260 that is configured to maintain a registry of instances bound to the transport service 240. The registry service 260 is configured to update the registry according to update requests received from instances bound to the client connection service 106. Additionally, the registry service 260 is configured to execute queries received from instances; for example, an instance may issue a query to identify an instance associated with a particular user identifier. In Figure 2 the example shown in, the registry information is maintained as user records 262, but it will be understood that the registry information may be arranged in other ways. In this example, the user record 262 includes a first user record 264a associated with a third user identifier 266a (which is the same as the first and second user identifiers 246a and 246b in this example). Additionally, the first user record 264a includes an instance record 268 for the bound instance associated with the third user identifier 266a. In this example, the instance record 268 includes a fifth instance record 270a for the first instance 131 and a sixth instance record 270b for the second instance 133. The fifth instance record 270a may include a first persistent identifier 272a associated with the first instance 131 and may include a first resource identifier 274a associated with the first instance 131. The sixth instance record 270b may include a second persistent identifier 272b associated with the second instance 133 and may include a second resource identifier 274b associated with the first instance 133. Each instance record in the instance record 268 has a different persistent identifier 272, allowing the instance to be identified despite changes to its corresponding resource identifier 274 over time.

[0043] Figure 3Illustrated is an example in which a first instance 131 and a second instance 133 are each bound to and registered with a client connection service 106. In some examples, operation 302 occurs, in which a first user 120 logs into an authentication service 223 via the first example 131 or the second device 130. In some examples, operation 302 includes receiving a token issued by the authentication service 223. At operation 304, the first instance 131 transmits a binding request message 306 to a transport service 240. The "request message" may more simply be referred to as a "request". In some examples, operation 302 includes determining connection information for the first instance 131, and the binding request 306 includes the connection information. In some examples, the first instance 131 may be configured to operate as a web server or another server type in response to an HTML request, where the connection information includes a network address, a port number, and / or a secret value (such as, but not limited to, a header or cookie value included in the request message) for communicating with the server. In some examples, the first instance 131 is configured to determine that it operates behind a firewall or is unable to operate as a server to receive requests from the client connection service 106, and in response to that determination, uses a polling mechanism (such as, but not limited to, long polling) to receive requests from the client connection service 106, where the connection information reflects the first instance 131's use of a polling-based connection scheme. In some examples, the binding request 306 includes user information, such as a user identifier and / or a token issued by the authentication service 223.

[0044] At operation 308, the transport service 240 receives and processes the binding request 306. In some implementations, operation 308 includes verifying that the first instance 131 is currently authenticated using the authentication service 223. For example, the verification can be performed based on an access token provided by the first instance 131 (e.g., based on the expiration time indicated by the access token signed by a password) and / or by requesting verification from the authentication service 223. If there is no instance record 244a associated with the first instance 131, the transport service 240 creates the instance record 244a. In some implementations, the transport service 240 is configured to remove the instance record from the instance record 242 in response to an unbinding operation performed by the instance. In some examples, a "logout" mechanism is supported for devices used by multiple different users, in response to which the instance on the device unbinds itself from the transport service 240. The first transport channel information 248a is set; for example, according to the connection information included in the binding request 306. If there are multiple different connection schemes available (e.g., webhooks versus polling), the first transport channel information 248a can include the connection type. For a webhook-based scheme, the first transport channel information 248a can include a URI or associated information. In an example where the binding request 306 includes connection information, the first transport channel information 248a can be determined based on the connection information included in the binding request 306.

[0045] The processing performed at operation 308 can include operation 310, where the transport service 240 obtains a user identifier (such as but not limited to a username or a numeric or alphanumeric value) associated with the first instance 131 that issued the binding request 306. For example, the user identifier can be obtained based on the user information included in the binding request 306. In some implementations, the transport service 240 is configured to interact with the authentication service 223 to obtain the user identifier associated with the token included in the binding request 306. The obtained user identifier can be included in the first instance record 244a as the first user identifier 246a.

[0046] In response to receiving the binding request 306, at operation 312, the transport service 240 allocates resources provided by a host included in the transport service 240 to the first instance 131. In some implementations, the allocated resources have a corresponding resource identifier in the form of a base URI (e.g., "https: / / 246-transport-a.trouter.io:443 / v2 / f / 6KMkABF"), which includes a scheme (e.g., HTTP or HTTPS), a authority (e.g., a hostname or network address and / or port number), and / or a base path. In some implementations, the client connection service 106 is implemented across multiple data centers, and the authority included in the base URI corresponds to a particular one of the multiple data centers. In some implementations, the allocated resources have a corresponding resource identifier in the form of a value (e.g., the string "6KMkABF"), which will be included in the request (e.g., as part of the URI the request is directed to, the header part of the request, and / or the body or payload part of the request). In Figure 3 this case, the resource identifier for the resources allocated in operation 312 is labeled "RSC ID 1". The resource identifier for the resources allocated to the first instance 131 is included in the first instance record 244a as the first resource identifier 250a. The transport service 240 is configured to: in response to receiving a request corresponding to the first resource identifier 250a, forward the received request to the first instance 131 according to the first transport channel information 248a, as will be described in more detail with reference to the subsequent figures. Additionally, at operation 314, the transport service 240 transmits a binding response message 316 to the first instance 131 as a response to the binding request 306. A "response message" may be abbreviated as a "response".

[0047] In some implementations, the transport service 240 is configured to receive a permitted peer target from the first instance 131 via the binding request 306 or an additional request not shown in Figure 3 this figure. The transport service 240 is configured to update the first permitted peer target 254a accordingly, and is configured to determine whether to forward a request for a target corresponding to the first resource identifier 250a based on whether the target corresponds to the first permitted peer target 254a. For example, if the first permitted peer target 254a includes one or more whitelisted target paths (which may be expressed using regular expressions), the target must match one of the target paths to be forwarded. By using the first permitted peer target 254a, the transport service 240 can filter requests to prevent abusive or invalid requests from being sent to the first instance 131.

[0048] Although Figure 3A single request 306 and a single response 316 are shown, but it should be understood that other communication schemes may be applied to achieve a similar effect. For example, additional messages may be exchanged to negotiate a connection scheme between the first instance 131 and the transport service 240. Similar considerations apply to other request / response exchanges described herein.

[0049] At operation 318, the first instance 131 receives a binding response 316 from the transport service 240. At operation 320, the first instance 131 transmits a register instance request 322 to the registry service 260. The register instance request 322 may indicate a user identifier, a persistent identifier, and / or a resource identifier associated with the first instance 131 (e.g., the resource identifier included in the binding response 316). At operation 324, the registry service 260 receives the register instance request 322 and, in response, correspondingly creates and / or updates a first user record 264a and a fifth instance record 270a. For example, the user identifier included in the register instance request 322 may be used to identify the first user record 264a (if it already exists) and / or be stored as a third user identifier 266a, the persistent identifier 322 included in the register instance request 322 may be used to identify the fifth instance record 270a (if it already exists) and / or be stored as a first persistent identifier 272a, and the resource identifier included in the register instance request 322 is stored as a third resource identifier 274a. By querying the registry service 260, other elements of the system 200 (such as the second instance 133) can obtain the resource identifier 274a associated with the first instance 131, as will be discussed in connection with Figure 4 what follows.

[0050] Figure 3 A similar set of operations 330, 336, 338, 340, 342, 346, 348, and 352 performed by the system 200 in connection with binding the second instance 133 to the client connection service 106 is shown. In some examples, operation 330 occurs, in which the first user 120 logs in to the authentication service 223 via the second instance 133 or the second device 130, which is very similar to that described for operation 302. At operation 332, the second instance 133 transmits a binding request 334 to the transport service 240, and at operation 336, the transport service 240 receives and processes the binding request 334, which is very similar to that described for the binding request 306 and operations 304 and 308. The processing performed in operation 336 may include operation 338, in which the transport service 240 obtains a user identifier associated with the second instance 133, which is very similar to that described for operation 310. At operation 340, the transport service 240 allocates a resource to the second instance 133, which is very similar to that described for operation 312. At Figure 3In [the description], the resource identifier for the resource assigned to the second instance 133 in operation 340 is marked as "RSC ID 2". At operation 342, the transport service 240 transmits a binding response 344 to the second instance 133, and at operation 346, the second instance 133 receives and processes the binding response 344, which is very similar to that described for the binding response 316 and operations 314 and 318. At operation 348, the second instance 133 transmits a register instance request 350 to the transport service 240, and at operation 352, the transport service 240 receives and processes the register instance request 350, which is very similar to that described for the register instance request 322 and operations 320 and 324.

[0051] Continue Figure 3 In the example of Figure 4 illustrates an example of a pairing process between a first instance 131 and a second instance 133 that is executed via the client connection service 106 and initiated by the second instance 133. In operation 402, in order to query the registry service 260 to identify other instances available for pairing with the second instance 133, the second instance 133 transmits a first list endpoint request 404 (marked as "List Endpoint REQ") to the registry service 260. At operation 406, the registry service 260 receives and processes the first list endpoint request 404 to identify appropriate instances from the registry.

[0052] In some implementations, operation 406 includes operation 408, in which the identified endpoints are limited to instances that are currently bound to the client connection service 106 and associated with the same user identifier as the second device 212 associated with the request. For example, the user identifier associated with the second instance 133 can be identified based on a token provided by the second instance 133 (such as the token included in the first list endpoint request 404), or can be explicitly included in the first list endpoint request 404. Based on the identified user identifier, the registry service 260 identifies the first user record 264a. The registry service 260 identifies the instances associated with the user identifier 268 from the instance records 268 included in the first user record 264a. In some implementations, other schemes can be used to identify the response instance records.

[0053] At operation 410, the registry service 260 transmits a first list endpoint response 412 to the second instance 133 as a response to the first list endpoint request 404. The first list endpoint response 412 includes information obtained from the instance records identified in operation 406. For example, the first list endpoint response 412 can include a persistent identifier and a resource identifier for each identified instance record. In Figure 4In the example shown, the first list endpoint response 412 includes a first persistent identifier 272a for the first instance 131 and a third resource identifier 274a, and may also include information for other instances. At operation 414, the second instance 133 receives and processes the first list endpoint response 412. Operation 414 includes operation 416, where the second instance 133 selects a peer endpoint from one or more of the instances identified in the first list endpoint response 412. In some implementations, the second instance 133 presents a list of instances to the first user 120 and receives user input selecting a desired instance for pairing with the second instance 133. In this particular example, the first instance 131 has been selected for pairing.

[0054] At operation 420, the second instance 420 is configured to identify a first target resource (labeled "Target 1" in Figure 4 based on the resource identifier 274a included in the first list endpoint response 412 for the first instance 131. A first peer request 422 (labeled "Peer REQ" in Figure 4 including a first connection establishment request 424 (labeled "Establish Connection REQ") for forwarding to the first instance 131 is sent to the first target resource. The first target resource corresponds to the resource assigned to the first instance 131 in operation 312, which will be designated as the first resource 460, as shown in Figure 4 In some examples, the resource identifier is a base URI, and the first target resource is identified by additional path components. For example, for a connection establishment request, based on a resource identifier with a base URI of "https: / / 246-transport-a.trouter.io:443 / v2 / f / 6KMkABF", a further path " / connect-peer" can be added, resulting in "https: / / 246-transport-a.trouter.io:443 / v2 / f / 6KMkABF / connect-peer" as the first target resource. In an example where the first peer request 422 is sent as an HTML request, the connection establishment request may be included in the body or payload of the HTML request.

[0055] At operation 426, the transport service 240 receives and processes the first peer request 422. The transport service 240 determines that the first peer request 422 is sent to the first resource 460; for example, by determining that the first target resource to which the first peer request 422 is sent corresponds to the first resource 460. Based on this determination, the transport service 240 selects the first instance record 244a associated with the first instance 131; for example, based on determining that the first target resource corresponds to the first resource identifier 250a included in the first instance record 244a.

[0056] In some implementations, the transport service 240 is configured to restrict forwarding to instances associated with the same user identifier, and operation 426 includes operation 428, where the transport service 240 determines whether the first and second instances 131 and 133 are associated with the same user identifier. In response to determining that the associated user identifiers are the same, the transport service 240 continues its processing of the first peer request 422, as shown in Figure 4 shown. In response to determining that the associated user identifiers are different, the transport service 240 does not continue to forward the first establishment connection request 424 to the first instance 131.

[0057] At operation 430, the transport service 240 establishes and / or uses an established first transport channel 470 between the transport service 240 and the first instance 131 based on first transport channel information 248a included in the first instance record 244a. The first transport channel 470 is used to transmit a first forward establish connection request 432 to the first instance 131. Although multiple network connections may be established and terminated over time between the transport service 240 and the first instance 131, these connections are all considered part of a single first transport channel 470 used by the transport service 240 to "push" forward requests received from other instances to the first instance 131 and receive corresponding responses from the first instance 131. In an example where the first peer request is directed to a path (e.g., where the first peer request 422 is an HTML request sent to a URI specifying the path) and the first forward establish connection request 432 is sent to the URI (e.g., where the first instance 131 operates as a server to receive the first forward establish connection request 432 as an HTML request), the URI can be identified based on a portion of the path. In the example, the transport service 240 is configured to obtain the " / connect-peer" portion from the " / v2 / f / 6KMkABF / connect-peer" URI for the first peer request 422 (e.g., based on the first resource identifier 250a), and combine the obtained portion with a webhook base URI (e.g., included in the first transport channel information 248a) "https: / / 1.2.3.4" to obtain the URI "https: / / l.2.3.4 / connect-peer" to which the first forward establish connection request 432 is sent.

[0058] At operation 434, the first instance 131 receives and processes a first forwarding establish connection request 432. In some implementations, operation 434 includes operation 436, in which the transport service 240 determines whether the first and second instances 131 and 133 are associated with the same user identifier. For example, the first forwarding establish connection request 432 may include a token issued by the authentication service 223. The first forwarding establish connection request 432 includes a second resource identifier associated with the second instance 133, and at operation 438, the first instance 131 retains the second resource identifier as the first peer resource identifier 204 to allow the first instance 131 to later forward requests to the second instance 133 via the transport service 240. In some examples, the first forwarding establish connection request 432 includes a persistent identifier instance associated with the second instance 133, and at operation 438, the first instance 131 retains the persistent identifier as the first peer persistent identifier 206 for later use by the first instance 131. Similarly, at operation 454, the second instance 133 retains the resource identifier included in the first list endpoint response 412 for the first instance 131 as the second peer resource identifier 214, and in some examples, at operation 454, the second instance 133 retains the persistent identifier included in the first list endpoint response 412 for the first instance 131 as the second peer persistent identifier 216.

[0059] At operation 440, the first instance 131 sends a first establish connection response 442 via the first transport channel 470 as a response to the first forwarding establish connection request 432. The first establish connection response 442 may simply acknowledge the successful connection of the second instance 133 to the first instance 131. At operation 444, the transport service 240 receives and processes the first establish connection response 442. In response to receiving the first establish connection response 442, at operation 446, the transport service 240 transmits a first peer response 448 to the second instance 133 as a response to the first peer request 422. The transport service 240 forwards the first establish connection response 442 to the second instance 133 as a second establish connection response 450 included in the first peer response 448. Thus, the second instance 133 receives confirmation of the pairing of the first instance 131 with the second instance 133.

[0060] From Figure 4 Continuing, Figure 5 illustrates that the client connection service 106 is used to Figure 4An example of forwarding requests and corresponding responses between a first instance 131 and a second instance 133 in a pairing. Note that such forwarding by the client connecting to service 106 is not limited to request messages; for example, a simplex notification message without a corresponding response message can be forwarded by the client connecting to service 106 to the instance. At operation 502, a first peer instance request 508 will be forwarded from the second instance 133 to the first instance 131, and the second instance 133 identifies a second target resource (labeled "Target 2") to which a second peer request 506 including the first peer instance request 508 is sent, which is very similar to that described for Figure 4 operation 420 in Figure 4 is very similar. At operation 504, the second peer request 506 is sent to the second target resource (which corresponds to the first resource 460 associated with the first instance 131), which is very similar to that described for

[0061] operation 420 in Figure 4 is very similar. Figure 3 At operation 510, the transport service 240 receives and processes the second peer request 506. In some implementations, the transport service 240 confirms that the first instance 131 and the second instance 133 are associated with the same user identifier, which is very similar to that described for Figure 4 operation 428 in

[0062] is very similar. In some examples, operation 510 includes operation 512, where the transport service 240 filters incoming requests through their respective target resources based on a first permitted peer target 254a associated with the first instance 131, which is very similar to that previously discussed in Figure 4 is very similar. The filtering described for operation 512 can also be performed as part of operation 426 in

[0063] At operation 518, the first instance 131 receives and processes the first forwarding peer instance request 516, and at operation 520, which is included in operation 518, in response to receiving the first forwarding peer instance request 516, performs the actions associated with the first forwarding peer instance request 516. For example, as shown in Figure 4 , the forwarding peer instance request 516 is a connection establishment request, and performs the actions described in connection with operation 434.

[0064] At operation 522, the first instance 131 transmits a first peer instance response 524 via the first transport channel 470 as a response to the first forwarding peer instance request 516. In some examples, responses to multiple forwarding peer instance requests can be aggregated in a single peer instance response transmitted by the first instance 131 to reduce the number of messages being exchanged; for example, this may be more efficient in cases where the response is a simple acknowledgement. In some examples, depending on the actions associated with the first forwarding peer instance request 516, the first peer instance response 524 can include a large amount of data for transmission to the second instance 133. At operation 526, the transport service 240 receives and processes the first peer instance response 524. In response to receiving the first peer instance response 524, at operation 528, the transport service 240 transmits a second peer response 530 to the second instance 133 as a response to the second peer request 506. The transport service 240 forwards the first peer instance response 524 as a second peer instance response 532 included in the second peer response 530 to the second instance 133. In some examples, multiple peer instance responses (e.g., including the first peer instance response 524) can be aggregated in a single peer response transmitted by the transport service 240 to reduce the number of messages being exchanged.

[0065] Additionally, the first instance 131 can send requests to and receive responses from the second instance 133 paired with it in Figure 4 . As discussed in connection with operation 438, during the pairing process performed in Figure 4 , the first instance 131 receives, in operation 340, a first peer resource identifier 204 for a second resource 560 assigned to the second instance 133 by the transport service 240. At operation 540, a second peer instance request 546 will be forwarded from the first instance 131 to the second instance 133, and the first instance 131 identifies a third target resource (labeled "Target 3") to which it sends a third peer request 544 including the second peer instance request 546, which is very similar to that described for operation 540. At operation 542, the third peer request 544 is sent to the third target resource (which corresponds to the second resource 560 assigned to the second instance 133), which is very similar to that described for operation 504.

[0066] At operation 548, the transport service 240 receives and processes a third peer request 544. In operation 548 and very similar to that described for operation 428 and operation 512 in Figure 4 , the transport service 240 may be configured to confirm that the first instance 131 and the second instance 133 are associated with the same user identifier and / or may be configured to filter received peer requests by a target resource based on a second permitted peer target 254b included in the second instance record 244b for the second instance 133.

[0067] At operation 550, and very similar to that described for operation 430 and operation 514 in Figure 4 , the transport service 240 establishes and / or uses an established second transport channel 570 between the transport service 240 and the second instance 133 based on second transport channel information 248b included in the second instance record 244b. The second transport channel 570 is used to transmit a second forwarded peer instance request 552 to the second instance 133, very similar to that described for operation 514 and the first forwarded peer instance request 516. The second forwarded peer instance request 552 is generated based on a first peer instance request 508 included in the second peer request 506. In some implementations, the third peer request 544 is an HTML request, and both the second peer instance request 546 and the second forwarded peer instance request 552 include respective payload portions in JSON or XML format. In some examples, the payload portions of the second peer instance request 546 and the second forwarded peer instance request 552 are the same. At operation 554, the second instance 133 receives and processes the second forwarded peer instance request 552, and operations are performed by the second instance 133, the transport service 240, and the first instance 131 that cause the second instance 133 to perform actions associated with the second forwarded peer instance request 552, and the first instance 131 receives the resulting response, very similar to that described for operations 522 through 534.

[0068] The described use of the client connection service 106 provides a number of advantages. By making the instance not directly available to other systems, but providing access to the instance via the client connection service 106, the actual network address of the instance is not exposed, even to other instances associated with the same user identifier. This is used to protect sensitive information such as the location and / or user identity associated with the instance. Additionally, as described for operation 512, request filtering prevents the interfaces used to make the instance available to services (e.g., the client connection service 106 and / or the remote service 280) from being accessed and misused via the client connection service 106. For example, the misuse may occur in the form of malicious requests and / or content. Further, the client connection service 106 allows peer-to-peer connections between instances to be treated as more robust and persistent connections than those obtained via direct network connections between instances. For example, the client connection service 106 can automatically respond to changes in the network connection of an instance and will have a longer uptime than expected from an instance. Similarly, the client connection service 106 encapsulates different connection schemes that can be used across instance groups. For example, although some instances may use network hooks to receive requests and some instances may use long polling, a single communication protocol can be used for all instances via the client connection service 106. Additionally, the client connection service 106 presents the instance via a server interface that supports the use of a service-oriented architecture and / or an event-driven architecture for interacting with the instance. This allows the use of common code, libraries, and / or frameworks to interact with both the instance and other services such as the remote service 280.

[0069] In some implementations, the transport service 240 is configured to temporarily (e.g., for a predetermined amount of time) cache peer requests and / or peer responses for instances that are not able to immediately receive messages, such as during a temporary period of disconnection. For example, the transport service 240 can be configured to cache peer requests and / or peer responses for up to 60 seconds. This provides resiliency against temporary disconnections of the instance from the transport service 240, which is beneficial for instances on mobile devices that may switch networks more frequently and / or experience periods of poor or no network connectivity than their non-mobile counterparts.

[0070] In some implementations, the transport service 240 is configured to maintain the resource allocation for an instance while changing to a different transport channel for communicating messages between the instance and the transport service 240. For example, after changing from a first transport channel 470 to a different transport channel, the first instance 131 may continue to be allocated to the first resource 460. In some examples, the transport channel may change in response to a change in the network connection for the instance; for example, the instance may be running on a mobile device that was initially connected via a cellular data network but has since established a network connection with a Wi-Fi network. This allows the instance on the mobile device to remain connected as it changes location and network, and avoids renegotiating the session with the peer instance. In some examples, the change to a different transport channel may include a change to a different connection scheme; for example, although long polling may have been used initially, changing to a different network without a firewall allows and results in alternatively using a network hook-based connection scheme. This allows the instance on the mobile device to use the best available connection scheme as it moves between networks.

[0071] Continue Figure 3 , Figure 6 illustrates an example in which the client connection service 106 reallocates the first instance 131 from the first resource 460 to a different third resource 670 and the first instance 131 communicates the change to the third resource 670 to the second instance 133. Note that in conjunction with Figure 2 , the first instance record 244a may include a resource expiration 252a for the resource currently allocated to the first instance 131 (and identified by the resource identifier 250a). The transport service 240 is configured to: in response to the current time being equal to or greater than the resource expiration 252a, perform operation 602, wherein the first instance 131 is reallocated from the first resource 460 to a different third resource 670. As a result, the first instance 131 is no longer associated with the first resource 460, thereby causing the first resource 460 to be unable to forward requests to the first instance 131. Similarly, the resource identifier 250a is updated to the resource identifier associated with the third resource 670, and the resource expiration 252a is updated to identify the time at which the first instance 131 should again be reallocated to a different resource.

[0072] Then, at operation 604, the transport service 240 transmits an updated resource notification 606 to the first instance 131, which provides the first instance 131 with a new resource identifier (labeled "RSC ID 3") associated with the third resource 670. At operation 608, the first instance 131 receives and processes the updated resource notification 606, including updating the second peer resource identifier 214 to the new resource identifier included in the updated resource notification 606. Further in response to receiving the updated resource notification 606, at operation 610, the first instance 131 transmits a registry instance request 612 to the registry service 260 to update the registry, such that the registry service 260 associates the first instance 131 with the new resource identifier at operation 616, which is very similar to that described in connection with Figure 3 the registration instance request 322 and operation 324 in

[0073] Also in response to receiving the updated resource notification 606, the first instance 131 provides the updated resource identifier to its peer instances, including the second instance 133. At operation 620, the first device 131 sends a fourth peer request 622 to a fourth target resource (labeled "Target 4") corresponding to the second resource 560 assigned by the transport service 240 to the second instance 133. The fourth peer request 622 includes a first peer resource update request 624, which indicates that the resource identifier associated with the first instance 131 has changed to the new resource identifier ( "RSC ID3") associated with the third resource 670.

[0074] At operation 626, the transport service 240 receives and processes the fourth peer request 622, which is very similar to that described for Figure 5 operations 510 and 548 in Figure 5 At operation 628, the transport service 240 establishes and / or uses a second transport channel 570 between the transport service 240 and the second instance 133 to transmit a first forwarded peer resource update request 630 to the second instance 133, which is very similar to that described for

[0075] At operation 632, the second instance 133 receives and processes the first forwarded peer resource update request 630, which includes updating, at operation 634, the second peer resource identifier 214 stored by the second instance 133 to the new resource identifier (“RSC ID 3”) indicated by the first forwarded peer resource update request 630, which is very similar to what was described in Figure 4 operation 454 therein. Very similar to what was described for operations 522 to 534, at operation 636, the second instance 133 sends a first peer update resource response 638 to the transport service 240 as a response to the first forwarded peer resource update request 630, at operation 640 the transport service 240 receives and processes the first peer update resource response 638, at operation 642, the transport service 240 sends a third peer response 644 (which includes a second peer update resource response 646 generated according to the first peer update resource response 638) to the first instance 131 as a response to the fourth peer request 622, and at operation 648, the first instance 131 receives and processes the third peer response 644.

[0076] Later, at operation 650, the third peer instance request 654 will be forwarded from the second instance 133 to the first instance 131. Based on the second peer resource identifier 214 updated in operation 634, the second instance 133 identifies the fifth target resource (labeled “Target 5”) to which it sends the third peer instance request 654, which is very similar to what was described in Figure 5 operation 502 therein. Then, the fifth peer request 652 is sent to the fifth target resource (which corresponds to the third resource 670 now associated with the first instance 131), which is very similar to what was described in Figure 5 operation 504 therein. Thus, by correctly using the new resource identifier to direct to the first instance 131, the third peer instance request 654 is received, processed and forwarded to the first instance 131 via the first transport channel 470 as the third forwarded peer instance request 660 in operations 656, 658 and 662, which is very similar to what was described for Figure 5 operations 510, 514 and 518 therein.

[0077] By periodically changing the resources associated with the first instance 131, even if an attempt is made to abuse the first instance 131 via the first resource 460, after a period of time, the first resource 460 will no longer be effective for forwarding messages to the first instance 131, thereby frustrating such abuse. In some implementations, the client connection service 106 is configured to detect an attempt to abuse an instance via the allocated resources (e.g., by detecting an excessive rate or total amount of messages sent to the resources) and initiate operation 602 in response to a positive detection of an attempt to abuse. For example, this can interrupt a denial-of-service attack against the instance via the client connection service 106. In some implementations, the client connection service 106 is configured to initiate operation 602 in response to receiving a corresponding request from the first instance 131 and / or the second instance 133. For example, the first instance 131 can be configured to issue such a request in response to detecting an attempted abuse or a high-latency condition. As another example, the first instance 131 can be configured to issue such a request to "reset" the current peer connection and, in some examples, reset any pending messages held by the client connection service 106 for the current peer connection.

[0078] Figure 7 illustrates an example in which the first instance 131 is unable to convey the updated resource identifier to the second instance 133 in the same manner as shown in Figure 6 and the second instance 133 recovers from an initial abuse of an outdated resource identifier used to communicate with the first instance 131. Figure 7 Continuing from Figure 6 after operation 616 therein. At operation 702, the first instance 131 attempts to provide a new resource identifier in the second peer resource update request 706 included in the sixth peer request 704, which is very similar to that described for Figure 6 operation 620 therein. Very similar to that described for Figure 6 operation 626 therein, at operation 708, the transport service 240 receives and processes the sixth peer request 704. Very similar to that described for Figure 6 operation 628 therein, the transport service 240 attempts to send the second peer resource update request 712 to the second instance 133 via the second transport channel 570. However, at this time the transport service 240 is unable to communicate with the second instance 133; for example, the second device 132 on which the second instance 133 is running may temporarily lose its network connection. As a result, the second instance 133 is not notified of the new resource identifier that will be used to forward messages to the first instance 131.

[0079] Later, at operation 720, and as in Figure 5As shown in, the second peer resource identifier 214 used by the second instance 133 continues to correspond to the first resource 460. Accordingly, a seventh peer request 722, including a fourth peer instance request 724, is sent to a seventh target (labeled "Target 7") corresponding to the first resource 460 that was previously assigned to the first instance 131. However, at operation 726, when the transport service 240 receives the seventh peer request 722, the first resource 460 is no longer associated with an instance. In response to the seventh target resource not corresponding to the first resource 460 or another such resource, at operation 728, the transport service 240 transmits an error message 730 indicating that the seventh target resource is invalid to the second instance 133 as a response to the seventh peer request 722. In some examples, the seventh peer request 722 is an HTML request and the error response 720 is an HTML response with a 4XX client error status code, such as a "404 Not Found" status code.

[0080] At operation 732, the second instance 133 receives and processes the error response 730. Based on the receipt of the error message 730 in response to the seventh peer request 722, the second instance 133 determines that the first instance 131 is no longer assigned to the first resource 460. In response to this determination, at operation 734, the second instance 133 sends a second list endpoint request 736 to the registry service 260, where the registry service 260 receives the second list endpoint request 736 and, at operation 738, identifies an appropriate instance. At operation 740, the registry service sends a second list endpoint response 742, which is very similar to that described for operations 402 to 410 in Figure 4 . Then at operation 744, the second instance 133 obtains a resource identifier associated with the second peer persistent identifier 216 of the first instance 131 from the list endpoint response 742. Alternatively, the second instance 133 may issue a locate endpoint request (not shown in Figure 7 ) that includes the second peer persistent identifier 216, where the registry service 260 identifies the resource identifier associated with the received second peer persistent identifier 216 and returns a locate endpoint response (not shown in Figure 7 ) that includes the identified resource identifier ("RSC ID 3") for the first instance 131 corresponding to the second peer persistent identifier 216. Since the persistent identifier 272a stored by the registry service 260 remains the same as the second peer persistent identifier 216 stored by the second instance 133, the persistent identifier is valid for obtaining a new resource identifier ("RSC ID 3") for the first instance 131.

[0081] At operation 746, the second instance 133 updates the second peer persistent identifier 216 with a new resource identifier obtained from the registry service 260. At operation 748, based on the new value of the second peer persistent identifier 216, the second instance 133 identifies an eighth target resource (labeled "Target 8") to which the second instance 133 sends an eighth peer request 750 that includes a fourth peer instance request 724, similar to the seventh peer request 722. The eighth target resource corresponds to the third resource 670 that is currently assigned to the first instance 131. Accordingly, at operation 752, the transport service 240 receives and processes the eighth peer request 750, and at operation 754, sends a fourth forwarded peer instance request 756 to the first instance 131 via the first transport channel 470, which is successfully received and processed by the first instance 131 at operation 758, very similar to that described for Figure 5 operations 510 through 518 in Figure 5 . The first instance 131 may perform associated actions and send a response, very similar to that described for

[0082] operations 522 through 534 in

[0083] In some implementations, the client connection service 106 is configured to periodically determine whether the first instance 131 and / or the second instance 133 remains authenticated using the authentication service 223. For example, the client connection service 106 may be configured to interact with the authentication service 223 to request verification of an access token received from the instance. In response to determining that the instance does not remain authenticated using the authentication service 223, the client connection service 106 is configured to terminate one or more connections currently maintained for the instance. In some examples, an instance (such as the first instance 131 and / or the second instance 133) may be configured to periodically interact with the authentication service 223 to ensure that it remains authenticated using the authentication service 223, such as by refreshing or extending an access token previously obtained from the authentication service 223. By having the client connection service 106 periodically determine whether an instance remains authenticated, the client connection service 106 prevents instance abuse and obviates the need to configure the instance to perform an explicit unbinding or unpairing action with the client connection service 106. Figure 1A-7 As discussed in connection with Figure 8A and Figure 8BIllustrated is a projection session in which a second user 820 (which may be referred to as a "first attendee" or "first participant") initiates a projection of a first electronic content item 844 (which may be referred to as "electronic content" or "content") from a fourth device 812 (which may be referred to as a "participant device", "user computing device", or "user device") to a third device 802 (which may be referred to as a "projection target device", "target device", or "projection target"). It is understood that a file or document is an example of an electronic content item. In Figure 8A and Figure 8B The example shown in is in an environment 800, which is a meeting room having a third device 802 and a table permanently located therein. The second user 820 is sitting at the table along with a second attendee 822 and a third attendee 824. The attendees 820, 822, and 824 may participate in a scheduled or unscheduled meeting together in the environment 800. At the time shown in, such as in Figure 8A a first display device 806 (which may be referred to as a "display") included in the third device 802 is not being used in conjunction with the meeting. For example, the third device 802 may be in a reduced power sleep state in which the display 806 is powered off. The display 806 provides a large display area that is well-suited for viewing from a distance.

[0084] In Figure 8A the second user 820 wishes to display and discuss the first electronic content item 844 accessible via the fourth device 812 with the other attendees 822 and 824. In this example, the fourth device 812 is in the form of a handheld portable smartphone computing device, but the fourth device 812 may be embodied in other forms, such as but not limited to a tablet computer, a notebook or laptop computer, a desktop computer, and / or a console computing device (e.g., a console provided on a table). As shown in Figure 8C the second participant device 812 includes a fourth application 813, which may be configured to natively obtain and present the first electronic content 844 by using computing resources included in the fourth device 812 (e.g., in the form of an electronic file stored in a local storage device included in the fourth device 812 or retrieved from a network-accessible storage service). However, although the fourth device 812 may be effectively used for individual viewing and / or editing of the first electronic content 844, in the context of the meeting shown in Figure 8A and Figure 8B it would be more effective for the first electronic content 844 to be presented on the display 806 of the third device 802 for all attendees 820, 822, and 824 to view. In Figure 8A the second user 820 is interacting with a first user interface (UI) 840 presented on a display 816 included in the fourth device 812.

[0085] As shown in Figure 8A , in this example, the third device 802 is configured to periodically transmit a first beacon signal 830 (which may be referred to as a "beacon") to indicate its presence as a device supporting pairing. In some implementations, the first beacon signal 830 is generated by a presence transceiver included in the third device 802, where the first beacon signal 830 is generated in the form of a short-range signal such as a short-range wireless signal; for example, via low-power Bluetooth (BLE), an acoustic signal (including but not limited to ultrasound), and / or an optical signal. In response to receiving the first beacon signal 830, the fourth device 812 determines the presence of the third device 802 as a device supporting pairing, and presents an option via the first UI 840 to initiate a projection to the third device 802. Then, via the first UI 840, the second user 820 initiates the projection of the first electronic content 844 to the third device 802.

[0086] In response to Figure 8A the initiation of the projection in Figure 8B , in a first projection session, the projection of the first electronic content 844 has started, where the second user 820 is the "presenter" of the projection session. This is performed by the client connection service 106 by pairing the third device 802 with the fourth device 812 and forwarding messages between the two devices 802 and 812. The first electronic content 844 (in this example, slides for a presentation application, such as Microsoft PowerPoint TM ) is presented in the second UI 842 on the display 816 by a fourth application executing on the fourth device 812. At the same time and during the illustrated projection session, the first electronic content 844 is presented in the third UI 850 on the display 806 by a third application running on the third device 802. By using the third application on the third device 802, the presentation of the first electronic content 844 does not depend on the presentation resolution, quality, and capabilities of the fourth device 812, as would typically occur when performing a projection by "screen mirroring" graphical content through the display 816.

[0087] During a projection session, actions performed by a second user 820 that affect the rendering of a first electronic content 844 on a fourth device 812 are identified, encoded, and transmitted by the fourth device 812 via a client connection service 106 to a third device 802. In response to receiving the encoded actions, the third device 802 performs equivalent actions via a third application, resulting in affecting the rendering of the first electronic content 844 by the third device 802, which is parallel to the actions performed on the fourth device 812. The encoded actions may include navigation actions (e.g., next page or scroll actions) that change which sub - part of the first electronic content 844 is being rendered. The encoded actions may include editing actions that change parts of the first electronic content 844, such as but not limited to: adding or removing text, adding, removing, resizing, and moving graphical components, and formatting actions (such as but not limited to character formatting and paragraph formatting). By modifying the rendering of the first electronic content 844 on a display 806 in response to actions received in real - time, the third device 802 provides an engaging canvas for collaborative discussion of the first electronic content 844.

[0088] Figure 8C An example of a system 800 for establishing a secure and resilient persistent network connection between a user device and a target device is illustrated. For example, the system 800 can be used to implement projection between a third device 802 and a fourth device 812, as shown in Figure 8A and Figure 8B However, the use of the device connections established by the system 800 is not limited to projection. The system 800 includes a number of features shown in Figure 2 including a client connection service 106, a transport service 240, a registry service 260, one or more networks 224, additional users 226 and devices 228, an authentication service 223, and a remote service 280. In the system 800, the transport service 240 is configured to manage instance records 242, as described in connection with Figure 2-7 In this example, the instance records 242 include a fifth instance record 244c associated with the third device 802, and a sixth instance record 244d associated with the fourth device 812. The third and sixth instance records 244a and 244b may include items corresponding to any items included in the first instance record 244a.

[0089] In some implementations, the transport service 240 is configured to access the directory service 890 to determine whether to allow a user or an instance associated with the user to connect to a device such as a third device 802. For example, the directory service 890 and / or the transport service 240 may maintain device, group, organization, and / or role access policies used by the transport service 240 and / or the third device 802 to determine whether to allow an instance to connect to the third device 802. In some examples, a device may be associated with one or more groups and / or organizations maintained by the directory service 890, and an instance may be not allowed to connect to the device based on the user being associated with an instance not included in the group or organization associated with the device and / or the user not being associated with one or more specific roles.

[0090] In system 800, the registry service 260 is configured to manage user records 262, as described in Figure 2-7 In this example, the user record 262 includes a second user record 264b associated with a second user 820. The second user record 264b may include items corresponding to any items included in the first user record 264a; for example, the second user record 264b includes a fourth user identifier 266b (for the second user 820) and a fifth instance record 270c (for the fourth device 812). The registry service 260 is also configured to manage device records 880 for devices not associated with a specific user, such as the third device 802 and additional device 892. In this example, the device record 880 includes a first device record 882a associated with the third device 802. The first device record 882a includes a device identifier 884a for the third device 802 and a fifth resource identifier 886a assigned to the third device 802 by the transport service 240, which is very similar to the third and fourth resource identifiers 274a and 274b described in Figure 2 as being assigned to their respective first and second devices 130 and 132.

[0091] Similar to the first device 130, the third device 802 includes a third runtime environment 861, in which a third software program instance 803 is run by the third device 802. The fifth instance 803 maintains a third peer resource identifier 862 for peer instances of the fifth instance 803, and the fifth instance 803 may maintain a third peer persistent identifier 866 for peer instances. In some examples, the fifth instance 803 may maintain a current secret 864, which is used to generate data included in broadcast messages transmitted by the fifth instance 803 via a first proximity transceiver 868 included in the third device 802.

[0092] Very similar to the first device 130, the fourth device 812 includes a fourth runtime environment 871, where the fourth software program instance 813 is executed by the fourth device 812. The sixth instance 813 maintains a fourth peer resource identifier 872 for a peer instance of the sixth instance 813, and the sixth instance 813 may maintain a fourth peer persistent identifier 876 for the peer instance. For connections to instances not associated with a particular user (such as the fifth instance 803), the sixth instance 813 may be configured to maintain a peer device identifier 871 (storing the device identifier for the paired instance) and / or a peer secret 874 (for communicating with the paired instance). In some examples, the sixth instance 813 is capable of pairing with an instance running on another user computing device (such as an additional device 228). The fourth device 812 includes a second proximity transceiver 878 used by the sixth instance 813 to detect proximity to other devices; for example, by receiving a broadcast message transmitted by the third device 802.

[0093] It will be appreciated that although Figure 8A , Figure 8C , Figure 9 and Figure 10 illustrate a scenario where the first proximity transceiver 868 transmits a beacon signal (e.g., the first beacon signal 830 in Figure 8A ) received by the second proximity transceiver 878 to perform proximity detection between the third and fourth devices 802 and 812, other scenarios where the first and second proximity transceivers 868 and 878 can interact to perform proximity detection are possible. By a first example, the second proximity transceiver 878 may transmit a beacon signal received by the first proximity transceiver. By a second example, both the first and second proximity transceivers 868 and 878 may receive signals, such as signals generated by a wireless communication device, and determine that the third and fourth devices 802 and 812 are in proximity to the wireless communication device based on the received signals.

[0094] Figure 9 illustrates an example of a pairing process between the fifth instance 803 and the sixth instance 813 performed via the client connection service 106 shown in FIG. 8. For the purpose of discussion, assume that both the third and sixth instances 803 and 813 have been bound to the client connection service 106, as previously described in Figure 3is very similar to that described in. The binding of the fifth instance 803 includes registering with the registry service 260 to create or update a device record 882a associated with the fifth instance 803, and as a result, at the registry service 260, associating the device identifier 884a for the fifth instance 803 with the fifth resource identifier 886a (labeled "RSC ID 4") of the fourth resource 960 currently assigned by the transport service 240 to the fifth instance 803. The binding of the sixth instance 813 may include operation 902, in which the second user 820 logs in to the authentication service 223 via the sixth instance 813 or the fourth device 812.

[0095] At operation 904, the sixth instance 904 uses the second proximity transceiver 878 to detect other devices in proximity to the fourth device 812. Very similar to that described for the first beacon signal 830 in Figure 8A , at operation 906, the fifth instance 803 transmits a second beacon signal 907 that includes the device identifier for the third device 802. In some implementations, an instance identifier may be used in place of the device identifier. In some implementations, a first secret 908 (labeled "Secret 1") is encoded in the second beacon signal 907; for example, the first secret 908 may be a key value. At operation 910, the sixth instance 813 receives the second beacon signal 907 via the second proximity transceiver 878, and at operation 912, the sixth instance 813 obtains the device identifier from the beacon signal 907 and stores it as a peer device identifier 871. In implementations where the beacon signal 907 includes the first secret 908, at operation 914, the sixth instance 813 obtains the first secret 908 from the beacon signal 907 and stores it as a peer secret 874.

[0096] Similar to using the first list endpoint request 404 to obtain the one in Figure 4The resource identifier described in, at operation 916, the sixth instance 813 transmits a device resource request 918 (labeled "Device RSC Request") to the registry service 260, requesting the resource identifier associated with the device identifier received in the second beacon signal 907. At operation 920, the registry service 260 receives and processes the device resource request 918 to identify a device record 880 that includes the device identifier identified by the device resource request 918. In this example, the registry service 260 identifies the device record 882a for the fifth instance 803. At operation 922, the registry service 260 transmits a device resource response 924 to the sixth instance 813 in response to the device resource request 918. The device resource response 924 includes information obtained from the identified device record 882a, including the fifth resource identifier 886a assigned to the fifth instance 803. In some implementations, the second beacon signal 907 includes the resource identifier assigned to the fifth instance 813, and at operation 926, the resource identifier is alternatively obtained from the beacon signal 907, and operations 916, 920, and 922 are omitted. In some implementations, in response to determining that the third device 802 is approaching the fourth device 812 and before proceeding with operation 916 or operation 930, the sixth instance 813 presents a user interface to the second user 820 to allow the second user 820 to initiate pairing with the fifth instance, and the sixth instance 813 receives user input requesting that the sixth instance 813 pair with the fifth instance 803.

[0097] At operation 930, the sixth instance 813 is configured to identify a ninth target resource (labeled "Target 9") based on the resource identifier 872 included in the device resource response 924 for the fifth instance 803. A ninth peer request 932, including a second establish connection request 934 for forwarding to the fifth instance 803, is sent to the tenth target resource, which is very similar to that described in operation 420 in Figure 4 . At operation 936, the transport service 240 receives and processes the ninth peer request 932, and at operation 938, transmits a second forwarded establish connection request 940 (generated based on the second establish connection request 934) to the fifth instance 803 via a third transport channel 970 between the transport service 240 and the fifth instance 803, which is very similar to that described in operations 426 and 430 in Figure 4 . At operation 942, the fifth instance 803 receives and processes the second forwarded establish connection request 940, which is very similar to that described in Figure 4The operations 434 and 438 described therein are very similar. In some examples, operation 942 includes operation 942, where the fifth instance 803 verifies that a sixth instance 813 associated with a user identifier (which may be included in the second forwarding connection establishment request 940) is permitted to connect to the fifth instance 803. For example, as discussed in Figure 8C the fifth instance 803 may be configured to interact with a directory service 890 to verify the user identifier. In response to a positive verification, the fifth instance 803 continues to process the second forwarding connection establishment request 940 and connects to the sixth instance 813.

[0098] In the manner in which the sixth instance 813 receives the first secret 908 from the second beacon signal 907, the connection establishment request 934 and the second forwarding connection establishment request 940 are encoded according to the first secret 908. In some examples, the first secret 908 is simply included as part of requests 934 and 940, such as part of a key / value pair. In some examples, a portion of requests 934 and 940 is encrypted based on the first secret 908, such as by using the first secret 908 as an encryption key. In some examples, requests 934 and 940 include a signature generated based on the first secret 908, such as a cryptographic signature of a payload portion using the first secret 908 as a salt value. At operation 946, which is included in operation 942, the fifth instance 802 verifies that the second forwarding connection establishment request 940 is encoded according to the current secret 864 (which is the same as the first secret 908 in this example). A successful verification allows the fifth instance 803 to determine that the sixth instance 813 is close enough to the third device 802 to receive the beacon signal transmitted by the third device 802. In response to a positive verification, the fifth instance 803 continues to process the second forwarding connection establishment request 940 and connects to the sixth instance 813.

[0099] Very similar to that previously described for Figure 4 the operations 440, 444, 446, and 452 therein, the pairing process between the fifth instance 803 and the sixth instance 813 is completed by the following operations: transmitting a third connection establishment response 950 at operation 948, receiving and processing the third connection establishment response 950 at operation 952, transmitting a fourth peer response 956 including a fourth connection establishment response 958 at operation 954, and receiving and processing the fourth peer response 956 at the sixth instance 813 at operation 960.

[0100] Continuing Figure 9 the example therein, where the third and sixth instances 803 and 813 are paired, Figure 10Illustrates an example of periodically updating the secret required for communicating with a paired device. In this example, the fifth instance 803 is configured to periodically transmit a beacon signal via the first proximity transceiver 868, very similar to that described for the second beacon signal 907. The periodically transmitted beacon signal includes the current secret 864, which is configured in the fifth instance 803 to be updated to a new value periodically. Thus, the beacon signal transmitted by the fifth instance 803 includes a secret that continuously changes over time.

[0101] At operation 1004, the sixth instance 813 transmits a tenth peer request 1006 that includes a fifth peer instance request 1008, very similar to that described for Figure 5 operation 504 in. In this example, the current secret 864 is still the first secret 908 from Figure 9 and the fifth peer instance request 1008 is encoded according to the first secret 908, very similar to that described in Figure 9 . Very similar to that described for Figure 9 operations 936, 938, 942, and 946 in, the transport service 240 receives and processes the tenth peer request 1006 at operation 1012, and transmits a fifth forwarded peer instance request 1016 (generated based on the fifth peer instance request 1008) via the third transport channel 970 at operation 1014, and at operation 1020. The fifth instance 803 receives and processes the fifth forwarded peer instance request 1016, and operation 1020 includes operation 1022, where the fifth instance 803 verifies that the fifth forwarded peer instance request 1016 is encoded according to the current secret 864. Thereafter, the processing of the fifth forwarded peer instance request 1016 continues, very similar to the examples shown in Figure 5 , 6 and / or 7.

[0102] Subsequently, a fifth instance 803 performs a periodic update of the current secret 864, changing it from a first secret 908 to a different second secret 1032 (labeled "Secret 2"). Then, at operation 1030, the fifth instance 803 transmits a third beacon signal 1031 that includes the second secret 1032. At operation 1034, a sixth instance 813 receives the third beacon signal 1031, and at operation 1036, updates the peer secret 874 to the second secret 1032 included in the third beacon signal 1031. Operations 1038, 1046, 1048, 1054, and 1056 directly correspond to operations 1004, 1012, 1014, 1020, and 1022. However, in operations 1038 through 1056, the sixth peer instance request 1042 (included in the eleventh peer request 1040) and the corresponding sixth forwarding peer instance request 1050 are encoded based on the second secret 1032 included in the third beacon signal 1031. By updating the current secret 864, transmitting the current secret 864 as a beacon signal, and verifying that messages received from paired instances are encoded based on the current secret 864, the fifth instance 803 is able to confirm that the fourth device 812 has remained near the third device 802; otherwise, it would not receive the updated secret required to encode messages to the fifth instance 803.

[0103] To further illustrate this point, operations 1060 through 1092 illustrate alternative examples of operations 1034 through 1056. In this example, although the current secret 864 has been updated to the second secret 1032 and the third beacon signal 1031 including the new secret 1032 is sent by the fifth instance 802, the sixth instance 812 does not receive the third beacon signal 1031 and thus continues to use the first secret 908. Operations 1060, 1068, and 1070 directly correspond to operations 1004, 1012, and 1014, including encoding the seventh peer instance request 1064 (contained in the twelfth peer request 1062) and the seventh forwarded peer instance request 1072 based on the first secret 908. However, at operation 1078, the fifth instance 803 fails to verify that the seventh forwarded peer instance request 1072 received at operation 1076 is encoded based on the current secret 864 (which was the second secret 1032 at that time). In response to the verification failure, the fifth instance 803 does not continue to process the seventh forwarded peer instance request 1072 but instead transmits an error response 1082 at operation 1080 as a response to the seventh forwarded peer instance request 1072. At operation 1086, the transport service 240 transmits the fifth peer response 1088 (including an error response 1090 generated based on the error response 1082 received at operation 1084) as a response to the twelfth peer request 1062. The sixth instance 813 receives the fifth peer response 1088 at operation 1092. Thus, the failure of the sixth instance 813 to receive and use the second secret 1032 prevents it from continuing to communicate with the fifth instance 803.

[0104] In some examples, the fifth instance 803 is configured to automatically terminate the pairing connection with the sixth instance 813 in response to receiving a predetermined number of messages (which may be a predetermined number of consecutive messages) from the paired sixth instance 813, the messages not being successfully verified as having been encoded based on the current secret 864 and / or after a predetermined amount of time has elapsed since receiving a successfully verified message from the paired sixth instance 813.

[0105] Figure 11 is a flowchart illustrating an implementation of an exemplary process 1100 for communicating between instances via a client connection service. In some examples, some or all of the processes of process 1100 may be performed in combination with any of the features discussed in connection with FIGS. 1 - 10, 13, and 14, but it may also be performed using any other features described herein. In Figure 11In [the process], the first operation 1110 may include identifying, at a first device, a second device registered with a client connection service, where the second device is different from the first device. In a second operation 1120, the process 1100 may include obtaining, at the first device via a data communication network, a first resource identifier for delivering a request message to the second device via the client connection service from the client connection service. In a third operation 1130, the process 1100 may include identifying, at the first device based on the obtained first resource identifier, a first target resource for a first request message directed to the second device, where the first target resource designates a first host included in the client connection service. In a fourth operation 1140, the process 1100 includes sending, by the first device via the data communication network, the first request message to the first target resource to the client connection service for delivery by the client connection service to the second device. In a fifth operation 1150, the process 1100 includes receiving, at the first device via the data communication network, a first response message provided by the second device as a response to the first request message from the client connection service.

[0106] Figure 12 is a flowchart illustrating an implementation of an exemplary process 1200 for communicating between instances via a client connection service. In some examples, some or all of the processes in process 1200 may be performed in combination with any of the features discussed in connection with FIGS. 1-10, 13, and 14, but it may also be performed using any other features described herein. In Figure 12 [the process], the first operation 1210 may include allocating, by the client connection service, a first resource to a first device. In a second operation 1220, the process 1200 may include receiving, at the client connection service, a first request message sent by a second device to the first target resource, where the second device is different from the first device. In a third operation 1130, the process 1200 may include selecting the first device based on the first target resource corresponding to the first resource. In a fourth operation 1140, the process 1200 includes generating, by the client connection service, a first forwarding request message based on the received first request message. In a fifth operation 1250, the process 1200 includes transmitting, via a first transmission channel, the first forwarding request message from the client connection service to the first device. In a sixth operation 1260, the process 1200 includes receiving, at the client connection service via the first transmission channel, a first response message to the first forwarding request message from the first device. In a seventh operation 1270, the process 1200 includes transmitting, from the client connection service to the second device, a second response message generated based on the first response message as a response to the first request message.

[0107] Detailed examples of the systems, devices, and techniques described in connection with FIGS. 1 - 12 will be presented below to illustrate the present disclosure and its benefits. Such usage examples should not be construed as limiting the embodiments of the logical processes of the present disclosure, nor should variations of the user interface methods from those described herein be considered outside the scope of the present disclosure. In some embodiments, the various features described in FIGS. 1 - 12 are implemented in corresponding modules, which may also be referred to as and / or include logic, components, units, and / or mechanisms. Modules may constitute software modules (e.g., code embodied on a machine - readable medium) or hardware modules.

[0108] In some examples, hardware modules may be implemented mechanically, electronically, or using any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic configured to perform certain operations. For example, a hardware module may include a dedicated processor, such as a field - programmable gate array (FPGA) or an application - specific integrated circuit (ASIC). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations, and may include a portion of machine - readable media data and / or instructions for such configuration. For example, a hardware module may include software contained within a programmable processor that is configured to execute a set of software instructions. It should be understood that the decision to implement a hardware module mechanically in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be driven by cost, time, support, and engineering considerations.

[0109] Accordingly, the phrase “hardware module” should be understood to encompass a tangible entity capable of performing certain operations and that can be physically configured or arranged, i.e., a physical structure, permanently configured (e.g., hard - wired) and / or temporarily configured (e.g., programmed) to operate in some manner or perform certain operations described herein. As used herein, “hardware - implemented module” refers to a hardware module. Considering examples where a hardware module is temporarily configured (e.g., programmed), each hardware module need not be configured or instantiated at any one instance in time. For example, in the case where a hardware module includes a programmable processor that is configured by software to be a dedicated processor, the programmable processor may be configured to be different dedicated processors (e.g., including different hardware modules) at different times. Software may accordingly configure one or more specific processors, e.g., to constitute a particular hardware module at one instance in time and different hardware modules at different instances in time. A hardware module implemented using one or more processors may be referred to as “processor - implemented” or “computer - implemented”.

[0110] Hardware modules can provide information to and receive information from other hardware modules. Thus, the described hardware modules can be considered to be communicatively coupled. In the case where multiple hardware modules are present simultaneously, communication can be achieved by signal transmission between two or more hardware modules (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, communication between these hardware modules can be achieved, for example, by storing and retrieving information in a memory device accessible by the multiple hardware modules. For example, one hardware module can perform an operation and store the output in a memory device, and then another hardware module can access the memory device to retrieve and process the stored output.

[0111] In some examples, at least some operations of a method can be performed by one or more processors or modules implemented by processors. Additionally, one or more processors can also be operable to support the performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some operations can be performed by multiple computers (as examples of machines including processors) and / or between multiple computers, and these operations can be accessed via a network (e.g., the Internet) and / or via one or more software interfaces (e.g., application programming interfaces (APIs)). The execution of certain operations can be distributed among processors that reside not only within a single machine but also across multiple machines. The processors or modules implemented by processors can be located in a single geographical location (e.g., in a home or office environment, or within a server farm), or can be distributed across multiple geographical locations.

[0112] Figure 13 FIG. 1300 is a block diagram showing an exemplary software architecture 1302, various parts of which can be used in conjunction with the various hardware architectures described herein, and which can implement any of the above features. Figure 13 This is a non - limiting example of a software architecture, and it should be understood that many other architectures can be implemented to facilitate the functions described herein. The software architecture 1302 can be executed on hardware such as Figure 14 a machine 1400 that includes a processor 1410, a memory 1430, and input / output (I / O) components 1450, among others. A representative hardware layer 1304 is shown and can represent, for example, Figure 14Machine 1400. Representative hardware layer 1304 includes processing unit 1306 and associated executable instructions 1308. The executable instructions 1308 represent the executable instructions of software architecture 1302, including the implementation of the methods, modules, etc. described herein. Hardware layer 1304 also includes memory / storage device 1310, which also includes executable instructions 1308 and accompanying data. Hardware layer 1304 may also include other hardware modules 1312. The instructions 1308 held by processing unit 1308 may be part of the instructions 1308 held by memory / storage device 1310.

[0113] Exemplary software architecture 1302 can be conceptualized as layers, each layer providing various functions. For example, software architecture 1302 may include layers and components such as operating system (OS) 1314, libraries 1316, frameworks 1318, applications 1320, and presentation layer 1344. In operation, applications 1320 and / or other components within the layer may make API calls 1324 to other layers and receive corresponding results 1326. The layers shown are representative in nature, and other software architectures may include additional or different layers. For example, some mobile or specialized operating systems may not provide framework / middleware 1318.

[0114] OS 1314 can manage hardware resources and provide common services. OS 1314 may include, for example, kernel 1328, services 1330, and drivers 1332. Kernel 1328 can act as an abstraction layer between hardware layer 1304 and other software layers. For example, kernel 1328 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Services 1330 can provide other common services to other software layers. Drivers 1332 can be responsible for controlling or interfacing with the underlying hardware layer 1304. For example, drivers 1332 may include display drivers, camera driver programs, memory / storage device drivers, peripheral device drivers (e.g., via Universal Serial Bus (USB)), network and / or wireless communication drivers, audio drivers, etc., depending on the hardware and / or software configuration.

[0115] The library 1316 can provide a common infrastructure that can be used by the application 1320 and / or other components and / or layers. The library 1316 generally provides functions for other software modules to perform tasks rather than directly interacting with the OS 1314. The library 1316 can include a system library 1334 (e.g., the C standard library), which can provide functions such as memory allocation, string manipulation, and file operations. In addition, the library 1316 can include an API library 1336, such as a media library (e.g., supporting the rendering and manipulation of image, sound, and / or video data formats), a graphics library (e.g., the OpenGL library for rendering 2D and 3D graphics on a display), a database (e.g., SQLite or other relational database functions), and a web library (e.g., WebKit providing web browsing capabilities). The library 1316 can also include a variety of other libraries 1338 to provide many functions for the application 1320 and other software modules.

[0116] The framework 1318 (sometimes also referred to as middleware) provides a higher-level common infrastructure that can be used by the application 1320 and / or other software modules. For example, the framework 1318 can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. The framework 1318 can provide a wide range of other APIs for the application 1320 and / or other software modules.

[0117] The application 1320 includes built-in applications 1340 and / or third-party applications 1342. Examples of built-in applications 1340 can include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 1342 can include any applications developed by entities other than the vendor of a specific platform. The application 1320 can use the functions available via the OS 1314, the library 1316, the framework 1318, and the presentation layer 1344 to create a user interface to interact with the user.

[0118] Some software architectures use virtual machines, as shown by the virtual machine 1348. The virtual machine 1348 provides a runtime environment in which applications / modules can execute as if they were executing on a hardware machine (e.g., Figure 14 the machine 1400). The virtual machine 1348 can be hosted by a host OS (e.g., the OS 1314) or a hypervisor, and can have a virtual machine monitor 1346 that manages the operation of the virtual machine 1348 and its interoperability with the host operating system. Software architectures different from the software architecture 1302 outside the virtual machine execute within the virtual machine 1348, such as the OS 1350, the library 1352, the framework 1354, the application 1356, and / or the presentation layer 1358.

[0119] Figure 14FIG. 0 is a block diagram showing components of an exemplary machine 1400 that is configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The exemplary machine 1400 is in the form of a computer system in which instructions 1416 (e.g., in the form of software components) can be executed to cause the machine 1400 to perform any of the features described herein. Thus, the instructions 1416 can be used to implement the modules or components described herein. The instructions 1416 cause the unprogrammed and / or unconfigured machine 1400 to operate as a particular machine configured to perform the described features. The machine 1400 can be configured to operate as a stand-alone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1400 can operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 1400 can be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and / or entertainment system, a smartphone, a mobile device, a wearable device (e.g., a smartwatch), and an Internet of Things (IoT) device. Further, although only a single machine 1400 is illustrated, the term "machine" includes a collection of machines that individually or jointly execute the instructions 1416.

[0120] The machine 1400 can include a processor 1410, a memory 1430, and I / O components 1450, which can be communicatively coupled via, for example, a bus 1402. The bus 1402 can include multiple buses that couple various elements of the machine 1400 via various bus technologies and protocols. In an example, the processor 1410 (including, e.g., a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) can include one or more processors 1412a to 1412n that execute the instructions 1416 and process data. In some examples, one or more processors 1410 can execute instructions provided or identified by one or more other processors 1410. The term "processor" includes a multi-core processor that includes cores that can execute instructions simultaneously. Although Figure 14 multiple processors are illustrated, the machine 1400 can include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, the machine 1400 can include multiple processors distributed across multiple machines.

[0121] The memory / storage device 1430 may include a main memory 1432, a static memory 1434, or other memories, as well as a storage unit 1436, which may be accessed by the processor 1410, for example, via a bus 1402. The storage unit 1436 and the memories 1432, 1434 store instructions 1416 embodying any one or more of the functions described herein. The memory / storage device 1430 may also store temporary, intermediate, and / or long-term data for the processor 1410. During execution, the instructions 1416 may also reside, wholly or in part, within the memories 1432, 1434, within the storage unit 1436, within at least one of the processors 1410 (e.g., within an instruction cache or a cache memory), within the memory of at least one of the I / O components 1450, or in any suitable combination thereof. Accordingly, the memories 1432, 1434, the storage unit 1436, the memories within the processors 1410, and the memories within the I / O components 1450 are examples of machine-readable media.

[0122] As used herein, "machine-readable media" refers to a device capable of temporarily or permanently storing instructions and data that cause a machine 1400 to operate in a particular manner, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), cache memory, flash memory, optical storage media, magnetic storage media and devices, caches, network-accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term "machine-readable media" applies to a single medium or a combination of multiple media for storing instructions (e.g., instructions 1416) for execution by a machine 1400 such that the instructions, when executed by one or more processors 1410 of the machine 1400, cause the machine 1400 to perform one or more of the features described herein. Accordingly, "machine-readable media" may refer to a single storage device, as well as a "cloud-based" storage system or storage network including multiple storage devices or apparatuses. The term "machine-readable media" does not include signals per se.

[0123] The I / O components 1450 may include a variety of hardware components suitable for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, and the like. The specific I / O components 1450 included in a particular machine will depend on the type and / or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or an IoT device may not include such a touch input device. Figure 14The specific examples of I / O components shown are in no way limiting, and other types of components may be included in machine 1400. The grouping of I / O components 1450 is for simplicity of discussion only and is in no way limiting. In various examples, I / O components 1450 may include user output components 1452 and user input components 1454. User output components 1452 may include, for example, display components for displaying information (e.g., liquid crystal display (LCD) or projector), acoustic components (e.g., speakers), haptic components (e.g., vibration motors or force feedback devices), and / or other signal generators. User input components 1454 may include, for example, alphanumeric input components (e.g., keyboards or touchscreens), pointing components (e.g., mouse devices, touchpads, or other pointing tools), and / or haptic input components (e.g., physical buttons or touchscreens that provide position and / or touch force or touch gestures) configured to receive various user inputs, such as user commands and / or selections.

[0124] In some examples, I / O components 1450 may include biometric components 1456, motion components 1458, environmental components 1460, and / or location components 1462, as well as a wide variety of other physical sensor components. Biometric components 1456 may include, for example, components that detect body expressions (e.g., facial expressions, vocal expressions, gestures, or body postures or eye tracking), measure biometric signals (e.g., heart rate or brain waves), and identify individuals (e.g., via voice-, retina-, fingerprint-, and / or face-based recognition). Motion components 1458 may include, for example, acceleration sensors (e.g., accelerometers) and rotational sensors (e.g., gyroscopes). Environmental components 1460 may include, for example, lighting sensors, temperature sensors, humidity sensors, pressure sensors (e.g., barometers), acoustic sensors (e.g., microphones for detecting ambient noise), physical proximity sensors (e.g., infrared sensing of nearby objects), and / or other components that may provide an indication, measurement, or signal corresponding to the surrounding physical environment. Location components 1462 may include, for example, location sensors (e.g., global positioning system (GPS) receivers), altitude sensors (e.g., barometric pressure sensors from which altitude may be derived), and / or orientation sensors (e.g., magnetometers).

[0125] The I / O component 1450 may include a communication component 1464 that implements various techniques that can be used to couple the machine 1400 to the network 1470 and / or the device 1480 via corresponding communication couplings 1472 and 1482. The communication component 1464 may include one or more network interface components or other suitable devices that interface with the network 1470. The communication component 1464 may include, for example, components suitable for providing wired communication, wireless communication, cellular communication, near field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other modalities. The device 1480 may include other machines or various peripheral devices (e.g., coupled via USB).

[0126] In some examples, the communication component 1464 may detect an identifier or include components suitable for detecting an identifier. For example, the communication component 1464 may include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode or other optical code), and / or an acoustic detector (e.g., a microphone that identifies an audio signal of a tag). In some examples, location information may be determined based on information from the communication component 1462, such as but not limited to a geographical location via an Internet Protocol (IP) address, a location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and / or signal triangulation.

[0127] Co-pending and co-owned U.S. Patent Application Serial Nos. 16 / 724,111, titled "UNIFIED INTERFACES FOR PAIRED USER COMPUTING DEVICES" and filed on December 20, 2019, and 16 / 724,116, titled "TELECONFERENCING INTERFACES AND CONTROLS FOR PAIRED USER COMPUTING DEVICES" and filed on December 20, 2019, are hereby incorporated by reference in their entireties.

[0128] Although various embodiments have been described, the description is intended to be exemplary rather than restrictive, and it should be understood that more embodiments and implementations within the scope of the embodiments are possible. Although many possible combinations of features are illustrated in the figures and discussed in this detailed description, many other combinations of the disclosed features are also possible. Unless specifically restricted, any feature of any embodiment can be used in combination with or substitute for any other feature or element in any other embodiment. Accordingly, it should be understood that any features shown and / or discussed in this disclosure can be implemented together in any suitable combination. Thus, the embodiments are not limited except as defined by the appended claims and their equivalents. Additionally, various modifications and changes can be made within the scope of the appended claims.

[0129] Although the foregoing has described what is considered to be the best mode and / or other examples, it should be understood that various modifications can be made therein, and the subject matter disclosed herein can be implemented in various forms and examples, and these teachings can be applied in many applications, only some of which are described herein. The appended claims are intended to claim any and all applications, modifications, and variations that fall within the true scope of this teaching.

[0130] Unless otherwise specified, all measurements, values, ratings, positions, magnitudes, dimensions, and other specifications set forth in this specification (including in the following claims) are approximate rather than exact. It is intended to have a reasonable range consistent with the functions involved and the conventions in the fields involved.

[0131] The scope of protection is limited only by the following claims. When interpreted in accordance with this specification and the subsequent prosecution history, this scope is intended to and should be construed to be consistent with the ordinary meaning of the language used in the claims and to include all structural and functional equivalents. Nevertheless, none of the claims is intended to cover subject matter that fails to meet the requirements of Sections 101, 102, or 103 of the Patent Act, nor should it be construed in such a way. Any accidental coverage of such subject matter is hereby disclaimed.

[0132] Except as described above, nothing stated or shown is intended or should be construed to dedicate any component, step, feature, object, benefit, advantage, or equivalent to the public, whether or not recited in the claims.

[0133] It should be understood that the terms and expressions used herein have the ordinary meanings ascribed to such terms and expressions with respect to their corresponding fields of investigation and study, unless a specific meaning is otherwise set forth herein. Relational terms such as "first" and "second" may be used solely to distinguish one entity or action from another, without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprising", "including" or any other variation thereof are intended to cover non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or elements inherent to such process, method, article or apparatus. Without further limitation, an element preceded by "a" or "an" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0134] A summary of the disclosure is provided to enable the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing detailed description, it can be seen that for purposes of simplifying the disclosure, various features are combined in various examples. This method of disclosure should not be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as reflected by the following claims, the inventive subject matter lies not in all of the features of a single disclosed example. Accordingly, the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separately claimed subject matter.

Claims

1. A first device that executes a first software application for participating in a telephone conference session, the first device comprising: a processor; and a machine-readable medium storing instructions that, when run by the processor, cause the first device to: identify a second device registered with a client connection service, where: the second device is different from the first device, and both the first device and the second device are associated with a first user; the second device is executing a second software application for participating in the telephone conference session with the first device, and the second device is configured to communicate with the first device via the client connection service; obtain, via a data communication network, a first resource identifier from the client connection service for delivering a request message to the second device via the client connection service; identify a first target resource for a first request message directed to the second device based on the obtained first resource identifier, where the first target resource designates a first host included in the client connection service; send, via the data communication network, the first request message to the first target resource to the client connection service for delivery to the second device via the first host; and receive, via the data communication network, a first response message provided by the second device from the client connection service as a response to the first request message.

2. The first device according to claim 1, wherein the instructions further cause the first device to: authenticate the first device using an authentication service in association with a first user identifier; and provide a first token to the client connection service, the first token reflecting the authentication of the first device using the authentication service.

3. The first device according to claim 1, wherein the instructions further cause the first device to: receive a beacon signal from the second device, the beacon signal including a device identifier and a secret; and encode the first request message based on the received secret, where obtaining the first resource identifier includes requesting a resource identifier associated with the received device identifier from a registry remote from the first device.

4. The first device according to claim 1, wherein the instructions further cause the first device to: receive, via a first transmission channel between the first device and the client connection service, a second request message generated by the second device; and provide, via the first transmission channel, a second response message as a response to the second request message for delivery to the second device by the client connection service.

5. The first device according to claim 1, wherein the instructions further cause the first device to: obtain, via a data communication network, a second resource identifier from the client connection service for delivering a request message to the first device via the client connection service; and Cause a registry remote from the first device to associate a first user identifier with the second resource identifier; wherein, the identifying the second device includes: Identifying a plurality of software instances, each software instance associated with the first user identifier, the plurality of software instances including a first software instance running on the second device, and Selecting the first software instance from the plurality of software instances.

6. A method for communication between devices via a client connection service, comprising: Identifying, at a first device executing a first software application for participating in a conference call session, a second device registered with the client connection service, wherein: The second device is different from the first device, and both the first device and the second device are associated with a first user; The second device is executing a second software application for participating in the conference call session with the first device, and The second device is configured to pair with the first device and communicate with the first device via the client connection service; Obtaining, at the first device via a data communication network, from the client connection service a first resource identifier for delivering a request message to the second device via the client connection service; Identifying, at the first device, based on the obtained first resource identifier, a first target resource for a first request message directed to the second device, wherein the first target resource designates a first host included in the client connection service; Sending, by the first device via the data communication network, the first request message to the first target resource to the client connection service for delivery to the second device via the first host; and Receiving, at the first device via the data communication network, from the client connection service a first response message provided by the second device as a response to the first request message.

7. The method according to claim 6, further comprising: Receiving, at the first device via a first transmission channel between the first device and the client connection service, a second request message generated by the second device; and Providing, by the first device via the first transmission channel, a second response message as a response to the second request message for delivery to the second device by the client connection service.

8. The method according to claim 6, further comprising: Obtaining, at the first device via a data communication network, from the client connection service a second resource identifier for delivering a request message to the first device via the client connection service; and Causing a registry remote from the first device to associate a first user identifier with the second resource identifier; wherein, the identifying the second device includes: Identifying, at the first device, a plurality of software instances, each software instance associated with the first user identifier, the plurality of software instances including a first software instance running on the second device, and Selecting the first software instance from the plurality of software instances.

9. The method according to claim 6, further Comprising: After sending the first request message at the first device, receiving, from the client connection service, a second resource identifier for delivering a request to the second device via the client connection service, wherein the second resource identifier is different from the first resource identifier; At the first device, identifying, based on the received second resource identifier, a second target resource for a second request message directed to the second device, wherein the second target resource specifies a second host included in the client connection service; The first device sending, via the data communication network, the second request message to the second target resource to the client connection service for delivery to the second device by the client connection service; and At the first device, receiving, via the data communication network, a second response message provided by the second device as a response to the second request message from the client connection service.

10. The method according to claim 6, wherein: The first request message includes an HTTP (Hypertext Transfer Protocol) request message; and The first response message includes an HTTP response message.

11. A method for communicating between devices via a client connection service, comprising: The client connection service allocating a first resource to a first device executing a first software application for participating in a teleconference session; At the client connection service, receiving a first request message sent by a second device to a first target resource, wherein: The second device is different from the first device, and both the first device and the second device are associated with a first user; The second device is executing a second software application for participating in the teleconference session with the first device, and The second device is configured to be paired with the first device and communicate with the first device via the client connection service; Selecting the first device based on the first target resource corresponding to the first resource; The client connection service generating a first forwarding request message based on the received first request message; Transmitting the first forwarding request message from the client connection service to the first device via a first transmission channel; At the client connection service, receiving, via the first transmission channel, a first response message to the first forwarding request message from the first device; and Transmitting, from the client connection service to the second device, a second response message generated based on the first response message as a response to the first request message.

12. The method according to claim 11, further comprising: Obtaining a first user identifier associated with the first device; Obtaining a second user identifier associated with the second device; and Before the transmission of the first forwarding request message, determining that the first user identifier is the same as the second user identifier, wherein the first forwarding request message is transmitted based on the determination that the first user identifier is the same as the second user identifier.

13. The method according to claim 11, further Including: Receiving, at the client connection service after a first time, a second request message sent by the second device to a second target resource; Selecting the first device based on the second target resource corresponding to the first resource; Generating, by the client connection service, a second forwarding request message based on the received second request message; And Transmitting the second forwarding request message from the client connection service to the first device via a second transmission channel different from the first transmission channel.

14. The method according to claim 11, Wherein: The first request message includes an HTTP (Hypertext Transfer Protocol) request message; and The second response message includes an HTTP response message.

15. The method according to claim 11, further Including: Allocating, by the client connection service, a second resource to the first device, wherein the second resource is different from the first resource; Receiving, at the client connection service, a second request message sent by the second device to a second target resource; Selecting the first device based on the second target resource corresponding to the second resource; Generating, by the client connection service, a second forwarding request message based on the received second request message; Transmitting the second forwarding request message from the client connection service to the first device via the first transmission channel; Receiving, at the client connection service via the first transmission channel, a third response message to the second forwarding request message from the first device; and Sending, from the client connection service to the second device, a fourth response message generated based on the third response message as a response to the second request message.

Images