Method and system for real-time data updates

A cloud information service provides information delivery substantially in real-time to in-network users and out-of-network users. Information delivered is formatted to appear visually as a card (a “smartcard”) for both in-network and out-of-network users. Real-time communication by way of messaging is enabled with any user whether they are in-network or out-of-network. Users of the cloud information service may employ mobile devices or desktop or laptop computers. Updates in substantially real-time are provided to the smartcards as the data sources change. The data sources may include enterprise and Internet data. The information is provided in a manner to remain current for mobile users and is efficient for mobile networks that can often experience poor connectivity and limited bandwidth.

FIELD OF THE INVENTION

This invention relates to computerized information systems and more particularly to communications and data updates substantially in real-time.

BACKGROUND

Information is increasingly available via a variety of forms. For example, the World-Wide Web (WWW) provides a rich and dynamic source of information via web pages that may be static or dynamic. Additionally, messaging, in the form of e-mail, SMS permits information to be communicated between individuals and to individuals from automated messaging systems such as email based news servers. Messaging among users subscribed to proprietary networks such as Facebook and LinkedIn is also possible.

While the above-described systems have greatly improved information delivery, there remains a need for improved methods and systems of information delivery that provide timely delivery of information from a variety of sources in a flexible manner to a variety of recipients without having to have all the recipients be part of the same network.

SUMMARY

Embodiments disclosed herein provide computerized methods and systems that operate to provide improved delivery of messages and other information in substantially real-time. Moreover, delivery of such information is not limited to users within a particular network that requires such users to be pre-registered. Instead, embodiments disclosed herein can provide message and other information delivery to any user, irrespective of whether such user is pre-registered as a member of a particular network. Moreover, such information may be delivered to users on a variety of devices including mobile phones, tablets and desktop and laptop computers. The information may be text based or incorporate rich-media aspects such as audio and video.

In disclosed embodiments, in-network users, in other words users registered to a prescribed service (referred to herein as a cloud service) and interacting with the service via a customized interface, such as provided by an application, may share some relevant content that may preferably be formatted to appear visually as a card (a “SmartCard”), and have instant communication around this content with any of their contacts who are out-of-network users (in other words, users that are not registered with the cloud service) on desktops and mobile devices. Updates in substantially real-time are provided to the SmartCards as the data sources change. The data sources may include enterprise and Internet data. The information is provided in a manner to remain current for mobile users and is efficient for mobile networks that can often experience poor connectivity and limited bandwidth.

The real-time communication is therefore not limited to users within a particular service but instead can be with anyone with a device that has a web browser. This permits widespread communication to users employing a wide range of devices and applications. In particular, in the mobile environment where users expect immediate responses, the disclosed embodiments provide a much more satisfactory user experience by providing substantially real-time communications with all users in their contact list, i.e. not only to in-network users but also to out-of-network users. As such, a user of a mobile device can initiate communication with anyone on their contact list, irrespective of whether the recipient is in-network or out-of-network. That out-of-network recipient can benefit from the same user experience provided by the SmartCard as in-network users using the mobile application. As data exchanged is changed at the source, which may be from publicly available sources on the Internet, or may be internal data from within an enterprise, the cloud service provides updates to all recipients of the data substantially in real-time.

The disclosed embodiments employ an efficient technique that stores relevant information locally and that stores and monitors exchanged information at a granular level, thereby permitting identification and transmission of granular pieces of information that have been updated. There are a number of benefits to this technique. First, the user interface is very responsive because most objects are usually found in the cache. Second, there is an eventually consistent state, because there is always synchronization with the server. Third, it works offline. If an Internet connection is not available, then the objects are returned from the local cache. Fourth, network traffic is minimized because only changed objects are passed over the network.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating information flow within a preferred embodiment of a Real-Time Cloud Information Service (RTCIS)10. As used within this specification, the term real-time refers to communication that appears to a user as occurring substantially in real-time, in other words with minimal perceived delay between transmission of information and receipt and presentation of the information on the recipient device. RTCIS10provides information to a variety of different users such as in-network users shown generally at12and out-of-network users shown generally at14. In-network users12are users registered with the RTCIS10and interacting with the RTCIS10via a customized interface, such as provided by a Mobile Application shown generally at32, which enables interaction with RTCIS10via a formatted interface that may visually resemble a card, referred to herein as a “SmartCard”. Advantageously, the RTCIS10also enables real-time communication via SmartCards to out-of-network users. An in-network user is therefore not limited to real-time communications via RTCIS10to only in-network users but may communicate in real-time with any user. As explained herein, the RTCIS10provides the necessary code to the device of an out-of-network user to enable real-time communications via the visually appealing and contextualized interface of a SmartCard.

The SmartCard may be formatted to present and receive information by way of a simplified user interface that facilitates input and output of information via the limited display screen space of a mobile device. The SmartCards may employ a variety of different data formats including text and rich media such as images, video, and voice. Visual representation of a plurality of SmartCards, each presenting information in a contextualized manner and selectable by a user, provides a simplified user interface that facilitates the consumption and entry of information by a user of the RTCIS10. Each SmartCard preferably consists of three components: (i) a data object that may contain reference to other objects, (ii) logic that handle users interaction with the card, and (iii) an HTML5 representation of the card. A card may have several representations in order to accommodate different devices and form factors. The SmartCards30are preferably packaged into a binary format such as Binary JSON (BSON) to optimize use of bandwidth to transmit to the user's mobile device where it is cached and rendered using proprietary mobile storage engine and template-driven renderer.

In certain embodiments, the SmartCard30may appear visually as a rectangular card shaped container and be employed as a fundamental unit of consumption or interaction with RTCIS10. In such an embodiment, the SmartCard30has the following properties:A fixed dimension (border) for a given mobile device form factor. All cards on a given mobile device type (iPhone 6, iPhone 5c, iPhone 5s, Samsung Galaxy 3, iPad, iPad Mini etc.) look identical in shape.A front and back face.Can display information on only the front face, or on the front and back face.Can either be static—i.e. an image, or dynamic—i.e. show information in it that may change over time or for each target device or user.Interactive—has one or a few actions embedded in the card for the user to perform.Branded or brandable based on source(s) of information.Connection properties to the source/s of content available on the card.A lifespan associated with it. Default lifespan is forever but there may be some SmartCards that exist only for a given span of time.Connection properties related to a source of content. For example, for a company profile SmartCard from for example, Salesforce.com, the salesforce instance URL, username and password are required to connect to the salesforce instance to retrieve specific information related to a target user and their context.A transportable unit of content that has a variable length mix of text, images, video and voice relevant to a user context and about a person, company or location. Context Intelligence functionality may be used to determine the relevance of one or more SmartCards for a given user's context and delivering these SmartCards to the user (devices).

In-network users12may exchange information with other in-network users12as seen at17. In-network users12may also advantageously exchange information with users that are not registered with RTCIS10, or with users that are registered with RTCIS10but that are not using Mobile App32. As used herein, the term “out-of-network user”, shown generally at14, refers to a user that is not registered to the RTCIS10or to an in-network user that is not using Mobile Application32. Out-of-network users14may interact with the RTCIS10via a variety of devices including a browser on a mobile device18or a browser on a laptop/desktop computer20.

The RTCIS10employs a variety of notification mechanisms to communicate with in-network users12and out-of-network users14, such as SMS (Short Message Service)22, e-mail24, or push notifications26. This permits widespread notification to users employing a wide range of devices and browsers to facilitate real-time communications. For example, the RTCIS10is not limited to communication within a particular application, as is the case with messaging capabilities provided by available on-line services. Moreover, while some on-line services can send a communication, such as an e-mail, to a recipient outside of the service, that communication is not in real-time. Moreover, unlike conventional messaging systems, the RTCIS10also permits real-time conversation (ie, bi-directional, or multi-way communication of information) in multiple contexts such as sales opportunities, sales pipeline, sales history, calendar entries, etc. of any information in the Enterprise or Internet sources of data shown generally at28. The RTCIS10advantageously operates with numerous sources of data shown generally at28. Such sources can include publicly available data on the World-Wide Web and can also include private or proprietary sources of data such as may be available via subscription based information services or corporate data sources. The RTCIS10interacts with such information sources28to provide real-time updates to the SmartCards30as the target data sources change.

The RTCIS Mobile Application32may take a variety of forms, such as an iOS application consisting of two main parts: user interface and RTCIS Base library34that implements an object cache and network protocol on top of WebSockets. The RTCIS Web Client such as shown at18,20is preferably an HTML5 application that works on all modern web browsers. Web clients18,20also have a JavaScript implementation34of the RTCIS Base library.

When an in-network user shares a SmartCard with other users the following events occur via the RTCIS10: (i) Notification: The recipient is informed of the new content shared, and (ii) Messaging: After the recipient gets the notification, the users message each other on the SmartCard content in real-time.

An in-network user12may share, from their phone, with a contact, one or more SmartCards. As shown inFIG. 1, the RTCIS10sends a variety of notifications to different users. For example, mobile users will receive an SMS22, desktop users will receive an e-mail24, and RTCIS Mobile App users will receive a push notification26. The recipient users may be in-network12and or out-of-network14users. RTCIS10employs user management software that has a map of the list of mobile numbers and email ids that are in-network users and if the requested mobile # or email id is not part of this list, then RTCIS10determines it as an out-of-network user.

For out-of-network users, if the shared information is being sent to a mobile number and when the RTCIS10resolves the recipient as out-of-network, then a SMS with the URL link (to the SmartCard30) is sent by RTCIS10to notify the out-of-network user. Along the same lines, if the shared information is being sent to an out-of-network user who is not on a mobile device then an email message with the URL link is sent to the user as a notification. Upon receiving the URL link, the out-of-network user may activate the link, such as by clicking on the link. This causes a request to the RTCIS10for base library34that provides a user interface and other functionality for communicating via the RTCIS10by way of SmartCards30.

When transmitting information from one in-network user to another in-network user, the RTCIS10employs a first technique if the receiving user is connected, such as by being logged-in to the RTCIS10via the Mobile Application32. In this case, the RTCIS10sends a RTCIS PUSH notification to a RTCIS base library associated with the receiving user's Mobile App32about the newly shared information. If the recipient user is in-network but is not connected to the RTCIS10, then the RTCIS10sends a PUSH notification via a push service such as for example, Apple APN, to the target user's mobile device. This notification includes a link such as a Uniform Resource Locator (URL) that the receiving RTCIS Mobile App32employs to request RTCIS10to provide information associated, such as in the form of the appropriate SmartCard30, with the URL.

The following table summarizes the types of notifications used by the RTCIS10when an in-network user12shares SmartCards30:

Turning toFIG. 2, a base library34is associated with each client such as Mobile App32, or for browsers that may be used by out-of-network users14. The base library34accompanies Mobile App32when it is downloaded and installed to a mobile device of an in-network user12. For out-of-network users, the base library34is downloaded and installed from RTCIS10upon activation for the first time on the associated mobile device of a URL link provided by the RTCIS10. Any updates to base library10may be provided subsequently by RTCIS10. RTCIS Application servers38maintain the state of RTCIS objects that are cached in RTCIS Base libraries34and if any of them change, the servers38send RTCIS Push Notifications to both in-network (RTCIS Mobile Application) and out-of-network (RTCIS Web Clients) users. The RTCIS objects are preferably implemented in the form of HTML 5 objects. By storing information to be communicated in such a form and by tracking any changes in the server, the RTCIS10can provide real-time updates that are highly bandwidth efficient. In other words, when content tracked by RTCIS10in the form of an object changes, only the changed object is transmitted to a receiving client (Mobile App32or browser31). This is far more efficient than a retransmission of an entire web page such as performed by many conventional systems. In particular, the granular update of a changed object by RTCIS10makes efficient usage of wireless bandwidth, which can be limited and highly variable. This efficient usage ensures that communications can be in real-time, without suffering the latency often incurred by transmission of updates incorporating large amounts of unnecessary data.

InFIG. 2the RTCIS10is connected with Mobile App32via base client libraries34and WebSockets as specified by the IETF in RFC6455. When the user, for example in-network user12sends a message, the RTCIS10determines the users that will receive the RTCIS PUSH notification. The Push notification in the client fetches the new message from the RTCIS10to display in the Mobile App32(for in-network user12) and web client18or20(for out-of-network user14). Real time messaging between clients is facilitated by the RTCIS PUSH notifications.

The RTCIS object retrieval protocol (Object Protocol) operates as illustrated inFIG. 3A and 3Bfollows. There are two main methods in the RTCIS Base API:getObject(path)—api call, retrieves object from server or local cache.onUpdate(path, object)—event, fires when object update has been detected.

When a client wants to access some object it makes a getObject API call, passing object path as a parameter. getObject works as follows. At step40, using path as a key, the client searches its local cache for the object. If the object is found41, at step42the client remembers the object modification timestamp and returns the object. At step43, the client makes a call to the server with the object modification timestamp received at step42, and the object path. Turning toFIG. 3Bwhich illustrates the operations by the server at RTCIS10, at49the server checks if the object timestamp received is less or equal than timestamp of the object with the same path stored on the server, and if so at50, pushes the updated object to the client. In the other case the server at51returns a special flag indicating that content of the object has not changed and the routine terminates at52. Returning toFIG. 2A, at44, the client receives and stores the received object to its local cache and triggers the event onUpdate(path, object) the updated object. If at41the object is not found, the client makes at46, a call to the server with the timestamp set to 0. The client receives at47the object from the server in the client's local cache and at step48, stores the object in its local cache and returns the object.

In short, the algorithm always checks the local cache first and returns an object if it was found and after that goes to the server and checks if there is an update the object and if the object was updated sends it to the client and the client triggers an object updated event. There are several benefits of using this algorithm. First, the user interface is very responsive because most objects are usually found in the cache. Second, there is an eventually consistent state, because it always synchronizes with the server. Third, it works offline. If an Internet connection is not available objects are returned from the cache. Fourth, network traffic is minimized because only changed objects are passed over the network.

The client preferably renders the user interface by maintaining the list of object paths that were used for rendering of each UI component. When onUpdate(path, object) events occurs, the user interface re-renders only the components that depend on this particular object path, leaving other components intact. Once the users are notified by the above mechanism of the shared information, they now communicate with each other using the Object Protocol discussed in connection withFIGS. 3A, 3B.

The RTCIS10provides real-time updates for one or more of the relevant SmartCards as the data source on the Internet or enterprise content changes. The RTCIS10allows instant, incremental updates to existing content when they change at the source. For example, if a new email arrives in your work email regarding an upcoming meeting, context intelligence functionality in the RTCIS10determines relevance to a given current or future Smartcards and updates the appropriate SmartCards. Continuing with this example, a SmartCard may exist for the upcoming meeting, where the SmartCard contains information such as meeting, place, time, subject and attendees. This SmartCard may be updated with the contents of the newly received email that may indicate for example, agenda items for the meeting. The context intelligence functionality determines if the email is relevant to the meeting SmartCard by correlating information in the metadata or body of the email with information regarding the upcoming meeting. For example, the subject line may correlate with the subject of the meeting or the content of the email indicates that it is related to the meeting. The RTCIS10updates the upcoming meeting SmartCard with relevant information from the incoming email. This update is immediately reflected in the SmartCards to all the users viewing this SmartCard in the Mobile Application32and web client users. Only the changed content is invalidated using RTCIS PUSH, and updated using RTCIS Object Protocol. Similarly, the RTCIS10uses Web Hooks (user-defined HTTP callbacks) to get notified when changes occur to enterprise content40and triggers the update process to all the relevant SmartCards. For example, a change to the location of the meeting entered into the calendaring application of an enterprise would be transmitted to the relevant SmartCards. Moreover, the RTCIS10also provides updates in third-party content that may be obtained from Internet data sources42. For example, in the meeting example above, the relevant SmartCards may be updated with weather information from data sources42regarding weather on the date of the meeting, or may be updated with traffic information regarding traffic conditions in the vicinity of the meeting location. The foregoing functionality allows for real-time synchronization of changes to operational content—in the enterprise or on the Internet—instantly to a user filtered by relevance to them thereby bringing the world of data and content closer to the user when they need it. As seen inFIG. 4, this permits not just a snapshot of enterprise and Internet data, but also remains current for mobile users. Data sources28can include enterprise data sources40and generally available Internet data sources42. The RTCIS10provides real-time updates to SmartCard30content from the Internet and enterprise data sources and provides them to Mobile App user16via Mobile App32.FIG. 5illustrates the flow of data from the Mobile App32to an enterprise data source28. An update by the Mobile App user16to a SmartCard30via the Mobile App32is provided to RTCIS10, which implements a form of write-through cache, by providing the data to the enterprise data source28.

Returning toFIG. 2, the software components that enable viewing of a SmartCard30in the Mobile App32can be seen. The RTCIS Base Library34is a client side library that implements an object cache, an object loading protocol and a wire protocol based on WebSockets as specified by the IETF in RFC 6455. The Base Library34is preferably implemented in two variants: JavaScript for Web Browsers and in C++ for Mobile App32. The C++ Base Library34is downloaded to mobile device16in conjunction with download and install of Mobile App32. The JavaScript Base Library34is downloaded to a browser31, if not already present, when a URL provided from RTCIS10in connection with a message is accessed. This causes a download of the RTCIS JavaScript Base Library, which is then available for subsequent real-time communications.

Objects have arbitrary structure and may have references to other objects. Each object is transferred over the network and stored in the local cache in BSON (Binary JSON) format. Each object has a path that uniquely identifies the object. The path is similar to a path in a file system and has the following format [userId, objectType, id1, id2, . . . ] where:userId—identification of the user who owns the objectobjectType—type of the objectid1, id2, . . . some identification specific to particular objectType.Each object has a timestamp of last modification.

FIG. 6shows the RTCIS Mobile Application32on iOS connected to the RTCIS10via edge server36via WebSockets using the RTCIS Base C++ Library34. This is how in-network users12connect to the RTCIS10. For out-of-network users14, the web browsers31(RTCIS Web Clients) on the desktop20and mobile18are also connected to RTCIS10via the RTCIS Base library34, in this case a Javascript library, to the RTCIS Edge Server36. The RTCIS Edge Server36maintains WebSocket sessions and handles HTTP requests from clients. The Edge Server36also manages user authentication. The RTCIS Router44implements Remote Procedure Calls (RPC) between Application Server38and Edge Server36, using a high performance asynchronous messaging library such as ZeroMQ. The RTCIS Application server38implements all business logic, data retrieval and data modification tracking. It updates clients when a data update is detected. The RTCIS architecture supports a variety of data storage mechanisms such as internal data source46and external data source28. For data storage, preferably the user ID is used as the first element of the object path for sharding and isolation of user partitions.

The RTCIS Base Library34implements a cache that resides on the mobile devices and also web browsers and uses the Web Sockets to connect to the RTCIS Cloud Service. This RTCIS Base Library34gets “RTCIS PUSH” notifications when any of the objects in the cache have changed in the RTCIS10. The RTCIS10decides the set of SmartCards that need to be updated when the target source changes and sends RTCIS PUSH notifications to these clients. Then the WebSockets layer provides the new content to the Base Library34, which preferably implements its cache in the form of an HTML5 cache. This permits the updates to be in near real-time as a) only the changes are notified and b) only the changed objects are fetched back from the server. This is very efficient in the mobile world in network usage as only changes are intelligently determined and pushed to the HTML5 pages. This is also performed via RTCIS PUSH Notifications and not polling.

FIG. 7illustrates a flow diagram of a scenario when a user is using Mobile Application32to share a RTCIS Smartcard30with two users one of which is In-Network user12and other is Out-of-Network user14. After that the out-of-network user14sends a text message to other users in the group. In-Network user ravi@mail.com shares a SmartCard30with andrey@mail.com and ramu@mail.com. The Mobile Application32connects to the RTCIS10using Object Protocol over Websockets. RTCIS10responds by accessing a database to check if andrey@mail.com is an in-network user. In this case andrey@mail.com is an in-network user. The RTCIS10responds by sending a push notification such as an Apple Push Notification to Mobile Application32which wakes up, connects to RTCIS10and loads all updates including the shared SmartCard30. The RTCIS10checks if ramu@mail.com is an in-network user. In this case ramu@mail.com is an out-of-network user. The RTCIS10sends an email notification to ramu@mail.com. This email contains a URL to an object stored on RTCIS10. ramu@mail.com (the user) clicks the link and opens the web client which opens a WebSocket connection to RTCIS10and loads the shared SmartCard30. The user ramu@mail.com sends text message #1related to the SmartCard34. The message is stored to RTCIS10and the RTCIS PUSH notification is sent to andrey@mail.com and ravi@mail.com. Then RTCIS10sends the message over RTCIS Object Protocol to in-network user andrey@mail.com. The RTCIS10also sends the message over RTCIS Object Protocol to in-network user ravi@mail.com when RTCIS Base Libraries fetch the new message.

FIG. 8depicts a generalized example of a suitable general purpose computing system60in which the described innovations may be implemented. The computing system60is not intended to suggest any limitation as to scope of use or functionality, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems. For example, the computing system60can be any of a variety of computing devices (e.g., desktop computer, laptop computer, server computer, tablet computer, media player, gaming system, mobile device, etc.).

With reference toFIG. 8, the computing system60includes one or more processing units62,64and memory66,68. InFIG. 32, this basic configuration70is included within a dashed line. The processing units62,64execute computer-executable instructions. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC) or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example,FIG. 32shows a central processing unit62as well as a graphics processing unit or co-processing unit64. The tangible memory66,68may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s). In some implementations, the memory66,68stores software implementing, at least in part, one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s).

Computing system60may have additional features such as for example, storage72, one or more input devices74, one or more output devices76, and one or more communication connections78. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system60. Typically, operating system software (not shown) provides an operating system for other software executing in the computing system60, and coordinates activities of the components of the computing system60.

The tangible storage72may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system60. The storage72stores instructions for the software implementing one or more innovations described herein.

The input device(s)74may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system60. For video encoding, the input device(s)74may be a camera, video card, TV tuner card, or similar device that accepts video input in analog or digital form, or a CD-ROM or CD-RW that reads video samples into the computing system60. The output device(s)76may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system60.