Patent Application
20150046544
Not Applicable.
Not applicable.
Not applicable.
The Real-Time Communication over the World Wide Web (RTCWEB) is an effort to achieve a standardized infrastructure in web browsers on which real-time interactive communication between users of the World Wide Web can be achieved. The two main industry-driving standards are the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). The major use cases for RTCWEB are real-time audio and/or video calls, web conferencing, and direct data transfer. In RTCWEB architecture, users may receive calls from web browsers at a target site, which the users agree to receive the calls, and the callers are required to know the target site. However, the web is a distributed system without any central authorities. As such, there is no global resolution system like Domain Name System (DNS) that binds a web identity to a web location. That is, there is no single identifier representing the combined knowledge of the web browser used by the user and the web site where the user is present. In addition, users are likely to travel between websites. Thus, the expectation that all the users who need to call each other are on the same website at the same time may not be realistic or practical. Even if the users are on the same website, they may not know the presence of each other if third party identity providers are being used, such as OpenID®, as third party identity providers may be independent of the website.
Consequently, there is a need in the art for methods and systems to provide a way for users to create distributed resolution systems that dynamically bind users' web identities to users' current web locations based on the users' web presence, such that calls may be routed efficiently and accurately while users are moving between websites.
In one embodiment, the disclosure includes a mirror presence system comprising a mirror site configured to couple to a visitor site via a communication network, establish a mirror presence relationship between the mirror site and the visitor site, perform a mirror presence at the mirror site by mirroring a direct presence of a user at the visitor site to a mirror presence of the user at the mirror site according to the established mirror presence relationship when the user is connected to the visitor site through a user device, wherein the direct presence of the user at the visitor site occurs when the user connects to the visitor site directly, and provide a caller accessing the mirror site through a calling site with an online presence state of the user at the mirror site according to the mirror presence even though the user is not directly connected to the mirror site.
In another embodiment, the disclosure includes an apparatus comprising a memory comprising instructions, and a processor coupled to the memory, wherein the instructions cause the processor to create a mirror presence subscription for a presence service from a mirror site to a visitor site, wherein creating the mirror presence subscription establishes a mirror presence relationship between the visitor site and the mirror site, send a presence activation request to the visitor site when a caller for a user connects to the mirror site via a first web browser, obtain an online status of the user at the visitor site from the visitor site when the user connects to the visitor site, and provide the online status of the user to the caller via the first web browser.
In another embodiment, the disclosure includes a method for managing a mirror presence at a visitor site, comprising receiving a presence subscription request for a presence service from a mirror site, wherein a mirror presence relationship between the visitor site and the mirror site is established according to instructions from a user, receiving a presence resume message from the mirror site to activate the presence service, sending an online presence event to the mirror site when the user directly connects to the visitor site, receiving a presence pause message from the mirror site when the user directly connects to the mirror site, and stopping to send the online presence event to the mirror site when the user connects to the visitor site after receiving the presence pause message.
In yet another embodiment, the disclosure includes a web server node comprising a memory, and a processor coupled to the memory and configured to manage a mirror presence of a user when the user assigns a website on the web server as a mirror site corresponding to a visitor site by mirroring a direct presence of the user at the visitor site to a mirror presence of the user at the mirror site when the user is connected to the visitor site and is not directly connected to the mirror site, wherein the direct presence of the user at the visitor site occurs when the user connects to the visitor site directly.
These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that, although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
Presence is a familiar concept for Instant Messaging (IM) systems. Presence refers to the appearance of a user on the World Wide Web available and willing to communicate with other users. A user may have multiple web accounts on multiple websites with different user identifiers. One of the challenges in RTCWEB may be to support the presence of a user across different websites. For instance, a user may log onto Yahoo®, while the user's friends may be present on other websites such as Google® or Facebook® and may want to call the user. However, the user's presence is not known to the any other websites, other than the website to which the user is currently logged on.
In RTCWEB, every user on the network is identified by a user identifier. However, a user identifier may not reveal the actual web location where the user is present. Thus, this may pose another challenge for RTCWEB. For example, a user may be identified by an email address or other identifiers obtained from different websites. The user may use a Gmail® email account as an identifier to log onto a website that is not related to Google®. As such, there is a gap between the users' identifiers and actual web locations.
Some of the current technologies may attempt to draw some presence relations between different presentities. However, they may not provide a user's global presence across different websites. For instance, current presence architecture may employ a presentity and watcher model, such as Session Initiation Protocol (SIP) and Extensible Messaging and Presence Protocol (XMPP), where a presentity may obtain a group of presence agents or devices, and a watcher may subscribe to a presentity to receive presence update from the presentity. However, two distinct presentities may not share their presence with each other in this architecture.
The inter-domain presence federation supported in SIP and XMPP attempts to provide some relations between different presentities where a user in one domain may subscribe and receive presence of a user in another domain. However, the presence federation support may be limited to primitives such as subscribe and notify only. Again, the presence of two entities may not be bound.
Another system attempts to find a user at web locations and devices by assigning a single virtual endpoint to serve as a proxy for many physical endpoints, such as the Find Me/Follow call-forwarding services. In this system, a user may have multiple physical phone numbers and a virtual phone number assigned by the system. When the system receives a call for the virtual phone number, the system may locate the user by routing the call to any or all the physical numbers as configured by the user.
In a Voice Over Internet Protocol (VoIP) system, a centralized name resolution system may be used to map a user identifier to an Internet Protocol (IP) address. However, the web is a completely distributed system with many websites and thus developing a centralized name resolution system for all websites to share may not be realistic. Consequently, a personal name resolution system that may connect all the web accounts of a user across all websites may be needed.
Disclosed herein are methods, apparatuses, and systems that may be used to provide a mirror presence, where the presence of a resource at one website may reflect the presence of a different resource at another website. In one embodiment, a user may construct and maintain a personal web resolution system by recruiting a few mirror sites to track the sites that the user has visited, through presence subscription, notification, and composition. In another embodiment, the disclosure includes three types of web resources, a direct presence, a mirror presence, and a presentity for each identity on a website. The mirror presence protocol includes the presence subscription process from a web browser and the management of the mirror presence. In another embodiment, another embodiment of the mirror presence protocol is shown where a web browser may directly report presence to a mirror site and to accept cookie from a mirror site. The disclosed embodiments may provide users a personal web resolution system and thus may improve users' mobility, availability, and privacy. For instance, a user may receive calls from multiple sites without directly connecting to each of the sites, switch browsers or devices without reestablishing mirror presence relations, and conceal his direct presence. The disclosed embodiments may also benefit websites, such as increased user loyalty (stickiness) since users are less likely to leave a website in order to receive calls from other sites. The disclosed embodiments may reduce traffic since presence messages are small compared to repetitive call messages and redirect calls for load balancing if a pool of mirror sites is available. The disclosed embodiments may also be readily implemented in servers within current presence architectures and protocols.
Another embodiment of the mirror presence of the mirror presence system 100 is shown in
In system 200, the user 210 may receive any form of communication (calls) from any of the mirror sites or visitor sites. For example, a friend may call the user 210 using identifier Id4 from the calling site 252. The call may be routed to the mirror site 242 and then may be forwarded to one of the visitor sites, either visitor site 231 or 232, by traversing the mirror presence relations in reverse direction. Similarly, calls from the calling sites 251 or 253 may also reach the user at the visitor site 231 or 232 by traversing the mirror presence relations in reverse directions. Hence, the disclosed system may provide a distributed resolution system for a user with accounts on many websites to establish relations between visitor sites and mirror sites. The user may then be contacted at any of the mirror sites by using the user's identity for the corresponding websites.
The mirror presence protocol 400 may be presented with an example where a user may manage his presence via a web browser A 411 and connects directly to a visitor site A 410, and a friend who is interested in the user's presence state connecting to a mirror site B 420 via a web browser B 421. Protocol 400 illustrates the establishment and management of mirror presence via multiple processes including subscription creation, subscription activation, online presence notification, mirror presence deactivation, mirror presence reactivation, and offline presence notification. Protocol 400 may be carried out using any standard presence protocol, such as SIP, XMPP, or any other subscription exchange protocols.
The subscription creation process may begin when a mirror site B 420 is interested in receiving the presence state of the user at the visitor site A 410, where mirror site B 420 may subscribe to visitor site A 410 for a presence service. At step 441, the presentity module 422 at the mirror site B 420 may generate a subscription creation message and send the message to the mirror presence module 424. At step 442, a subscription message may be sent from the mirror presence module 424 to the visitor site A 410. After the visitor site A 410 receives the subscription message, the visitor site A 410 may send a success message to the mirror presence module 424 indicating the successful subscription. At step 444, the mirror presence module 424 may forward the success message to the presentity module 422. At this time, the subscription is completed, but the presentity is in an inactive state.
The subscription activation process may begin when the friend at the mirror site B 420 is interested in the user's presence. At step 445, the friend may login to mirror site B 420 via web browser B 421 and send a subscription message to the presentity module 422 via a web socket. At step 446, the presentity module 422 may generate a presence activation message and send the message to the mirror presence module 424. At step 447, the mirror presence module 424 may send a presence resume message to the visitor site A 410 to activate the subscription. At this time, the presentity is activated. Note this may occur prior to the user login to the visitor site A 410. This serves as a request to be notified by the visitor site A 410 when the user is online.
The online presence notification process may begin when the user logs in to the visitor site A 410 via a browser A 411 and a connection message may be sent to the visitor site A 410 via a web socket as shown in step 448. At step 449, the visitor site A 410 may generate a presence event to indicate the user's online status and send an online presence event to the mirror site B 420. At step 450, the mirror presence module 424 may forward the online presence event to the presentity module 422. At step 451, the presentity module 422 may forward the online presence event to the browser B 421. Thus, the friend may know the user is now online.
The mirror presence deactivation process may begin when the user logs in to the mirror site B 420 directly via web browser A 411 and a connection message may be sent to the direct presence module 423 via a web socket as shown in step 452. At step 453, the direct presence module 423 may send an online presence event to the presentity module 422. Note that the online presence event is not forwarded to the browser B 421 since the online presence event is the same as in step 451. At step 454, the presentity module 422 may send a mirror presence deactivation message to the mirror presence module 424. At step 455, the mirror presence module 424 may send a presence pause message to the visitor site A 410 to deactivate the mirror presence. At this time, the mirror presence (Uniform Resource Identifier 1 (URI1)) is deactivated. The deactivation may reduce network traffic and may be optional since both the direct presence and the mirror presence are known at the mirror site B 420. The deactivation process may serve as an example for presence aggregation and should in no way be limited to this example.
The mirror presence re-activation process may begin when the user disconnects the direct presence from the mirror site B 420 via web browser A 411 and a disconnection message may be sent to the direct presence module 423 via a web socket as shown in step 456. At step 457, the direct presence module 423 may send an offline presence event to the presentity module 422. Note that the offline presence event is not forwarded to the browser B 421 since the user is still online through the direct presence at the visitor site A 410. However, the user is no longer connected to the mirror site B 420. Thus, the mirror presence may need to be re-activated. At step 458, the presentity module 422 may send a presence activation message to the mirror presence module 424. At step 459, the mirror presence module 424 may send a presence resume message to the visitor site A 410 to re-activate the mirror presence.
The presence offline notification may begin when the user disconnects from the visitor site A 410 via web browser A 411 and a disconnection message may be sent to the visitor site A 410 over a web socket as shown in step 460. At step 461, the visitor site A 410 may generate a presence event to indicate the user's offline status and send the offline presence event to the mirror site B 420. At step 462, the mirror presence module 424 may forward the offline event to the presentity module 422. At step 463, the presentity module 422 may forward the offline event to the browser B 421. The user is no longer on visitor site A 410, or mirror site B 420. Thus, the user's presence state is now offline.
Another embodiment of the mirror presence protocol 400 of
Protocol 500 may use a web beacon for online status establishment. At step 543, the user may connect to the visitor site A 510 using identifier Id1 by opening a web page via web browser 511 where a Hyper Text Transfer Protocol (HTTP) get message may be sent to the visitor site A 510. At step 544, the visitor site A 510 may choose to embed a web beacon in the web page when the web page is returned to the browser. The web beacon may contain a Uniform Resource Identifier (URI) pointing to the mirror site B 520 (URI2). The nature of a browser is to open all URIs. Thus, at step 546, once the web page is returned to the browser 511, a HTTP request may be sent to the mirror site B 520. This HTTP request may act as an indicator to the mirror site B 520 that the user is online. Thus, at step 547, the mirror presence module 524 may generate an online presence event and send the online presence event to the presentity module 522. At step 548, the mirror presence module 524 may send a HTTP successful message to the visitor site A 510.
The web beacon may only provide the online status of a user. The offline status of a user may be detected by using a web socket. Returning back to step 544, the visitor site A 510 may choose to embed a Java Script code to create a web socket connection to the visitor site A 510 (URI1) in the web page when the web page is returned to the browser as shown in step 545. That way, when the user disconnects from the visitor site A 510 as shown in step 549, the visitor site A 510 may obtain the offline status of the user. Thus, in step 550, the presentity module 522 at visitor site A 510 may generate an offline presence event and send the offline presence event to the mirror presence module 524 at mirror site B 520. Next, at step 551, the mirror presence module 524 may forward the offline presence event to the presentity module 522.
It is understood that by programming and/or loading executable instructions onto the NE 600, at least one of the processor 630, the cache, and the long-term storage are changed, transforming the NE 600 in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume may be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an application specific integrated circuit that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.
At least one embodiment is disclosed and variations, combinations, and/or modifications of the embodiment(s) and/or features of the embodiment(s) made by a person having ordinary skill in the art are within the scope of the disclosure. Alternative embodiments that result from combining, integrating, and/or omitting features of the embodiment(s) are also within the scope of the disclosure. Where numerical ranges or limitations are expressly stated, such express ranges or limitations should be understood to include iterative ranges or limitations of like magnitude falling within the expressly stated ranges or limitations (e.g., from about 1 to about 10 includes, 2, 3, 4, etc.; greater than 0.10 includes 0.11, 0.12, 0.13, etc.). For example, whenever a numerical range with a lower limit, R1, and an upper limit, Ru, is disclosed, any number falling within the range is specifically disclosed. In particular, the following numbers within the range are specifically disclosed: R=R1+k*(Ru−R1), wherein k is a variable ranging from 1 percent to 100 percent with a 1 percent increment, i.e., k is 1 percent, 2 percent, 3 percent, 4 percent, 5 percent, . . . 50 percent, 51 percent, 52 percent, . . . , 95 percent, 96 percent, 97 percent, 98 percent, 99 percent, or 100 percent. Moreover, any numerical range defined by two R numbers as defined in the above is also specifically disclosed. The use of the term “about” means±10% of the subsequent number, unless otherwise stated. Use of the term “optionally” with respect to any element of a claim means that the element is required, or alternatively, the element is not required, both alternatives being within the scope of the claim. Use of broader terms such as comprises, includes, and having should be understood to provide support for narrower terms such as consisting of, consisting essentially of, and comprised substantially of. All documents described herein are incorporated herein by reference.
