Patent Application
20160050235
This disclosure relates generally to systems, methods, and computer readable media for flexible and dynamic server architectures, e.g., for communication servers.
The proliferation of personal computing devices in recent years, especially mobile personal computing devices, combined with a growth in the number of widely-used communications formats (e.g., text, voice, video, image) and protocols (e.g., SMTP, IMAP/POP, SMS/MMS, XMPP, YMSG, etc.) has led to a communications experience that many users find fragmented and/or difficult to manage, while still maintaining a desired level of privacy and flexibility.
With current communications technologies, communications servers typically have a “static” architecture, that is, the incoming and outgoing gateway for a particular channel of communication tends to remain the same over time. For example, a user's personal emails (e.g., those going through a third party webmail server) may, by default, always be pulled from such third party's webmail server, sent through a centralized communication server, and then synced to the user's client device(s). However, in some instances, the user may desire the flexibility to change the incoming gateway for the particular channel of communication. For example, the user may desire his or her personal emails to first be pulled directly to a client device, where they may be encrypted prior to being synchronized with the aforementioned centralized communication server and pushed to the user's other client devices. In such a situation, the centralized communication server would not be able to decrypt or understand the messages received or sent for this particular communication channel, thus providing additional privacy to the user—while still being able to be used as the “gateway,” i.e., entry and exit point, for other channels of communication, such as work emails or voice messages.
Another limitation with current communications technologies relates to the disparate manners in which communications of different formats (and sent via different communications protocols) are handled by centralized communications servers. For example, an email object, may need to have a properly-packaged header including, e.g., the To:, From:, Subject: information, etc., before being sent to the corresponding third party webmail server. With the proliferation of communications formats, this may place a significant burden on communications servers attempting to pass messages of different formats (and sent via different communications protocols) between and among a plurality of client devices.
Thus, according to some embodiments described herein, an improved centralized server architecture is disclosed, which provides a “unified API” (Application Programming Interface) approach for interacting with every major form of communication and every major digital file type (e.g., .doc, .pdf, .png, .xlsx, .zip, etc.). Such an improved centralized server, which may, e.g., take the form of a centralized communication server, may effectively act as an I/O (input/out) hub, which directly connects to each channel of communication individually—while maintaining persistent connection(s) to each connected client, which clients may be run on a variety of devices and OS's (operating systems), including mobile computing devices, wearables, and the like. In other embodiments, the centralized server may take the form of a file server, or other form of input/output-based server system.
Such an improved centralized server, in effect, forms an additional layer of abstraction on top of the world's major communication APIs. To deal with the variety of disparate communications formats and protocols handled by such an improved centralized server, once a message enters the centralized server ecosystem, it may be converted to a so-called “common message object” for subsequent communication, search, and storage. By forming this additional abstraction layer around messages, the improved centralized server may treat incoming messages agnostically after entering the system, and then translate such messages into any desired protocol, e.g., according to a set of predefined protocol translation rules, before transmitting the messages to the appropriate end points. Further, by being able to rapidly and flexibly change the architecture of the improved centralized server, users may be placed in greater control over their data and devices—potentially leading to increases in privacy, security, and speed in communications.
The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above. To address these and other issues, techniques that enable flexible and dynamic server architectures are described herein.
Disclosed are systems, methods, and computer readable media for allowing users or systems to change the incoming and outgoing gateways for particular channels of communication in an on-demand fashion, i.e., with the “flick of a switch.” More particularly, but not by way of limitation, this disclosure relates to systems, methods, and computer readable media which, by default, directly interact with each channel of communication and then funnel messages to the appropriate connected clients. Moreover, according to the techniques disclosed herein, each user may choose which device becomes the entry and/or exit point (i.e., gateway) for each communication channel, and that device may instantly become the “master” for those messages arriving via that communication channel. The improved centralized server then knows where to automatically route such messages for each communication channel.
In addition, the improved centralized communication system according to some embodiments may elect to intelligently “flick the switch” to change the entry and/or exit point for a particular communication channel on behalf of a user. For example, while travelling, users may need to reauthorize their credentials when using a third party webmail service (e.g., because of IP address changes). The improved centralized communication system's server will be able to automatically detect such an issue and reauthorize the third party communication channel through the centralized server (which provides a stable IP address). Once reauthorized, the client device may then reconnect to the third party webmail service communication channel. Another example involves the opposite case, i.e., if the user has a third party communication channel that the centralized server can't authorize, the system may instantly try to connect through the client instead. Yet another example of a time when the centralized communication system's server could intelligently and dynamically change the entry and/or exit point for a particular communication channel would be when the server is overloaded and the system automatically or manually “flicks the switch” to reduce the load on the server and distribute the load to the clients. As will be more fully appreciated, architecturally, this system provides for dynamic syncing between client and server, as well as discretionary content flow and sync management.
Common Message Objects (CMOs)
Another innovation provided herein is the use of so-called “common message objects” (CMOs) by the flexible and dynamic server architecture system to be described herein. The CMO may be used to unify all types of “communication events,” file object, or other data object into a single kind of data object. According to some embodiments, the CMO comprises a limited number of attributes, such as: “Message Type”; “Channel Association”; “Sender/Recipient Association”; and metadata. The “Message Type” attribute may provide the server with an indication of the format of the particular message, e.g., email message, SMS message, etc. The “Channel Association” attribute may be used to provide the server with an indication of what protocol the CMO is to be sent via. For example, the Channel Association attribute could specify a particular third party email server, social network server, instant messaging server, Exchange message server, or the like. The “Sender/Recipient Association” attribute may be utilized by the server to keep track of which party(ies) each message involves, i.e., who the message belongs to and who it is being sent to. These attributes may be expandable, depending on the needs of a particular implementation. For example, each CMO may be tagged with information for both the sender and recipient, including, at a minimum, an ID and transmission protocol for the relevant communication channel at both the incoming and outgoing levels. According to some embodiments, the various attributes of the CMO determine how the centralized server will format a message object on the outgoing end.
According to some embodiments, the CMO framework allows the centralized server to handle generic JavaScript Object Notation (JSON) objects, rather than specific messages types, such as email messages or SMS messages. JSON is a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate. JSON is based on a subset of the JavaScript Programming Language that uses a text format that is completely language-independent—but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. For example, a JSON object is an unordered set of name/value pairs. An object begins with a left brace and ends with a right brace. Each name is followed by a colon, and the name/value pairs are separated by commas. These properties make JSON an ideal data-interchange language.
By leveraging generic JSON objects, the centralized server does not have to know how to specifically handle particular messaging formats, such as email messages or SMS messages. It simply handles a CMO JSON object that is “tagged” as an email. Then, just before sending the CMO to the appropriate location, e.g., a Google third party webmail server, the centralized server may convert the CMO to a Gmail-compatible email object. This enables the system to treat all messages the same for the purposes of search, storage, and transport throughout the system. For example, Email and XMPP use MIME and XML message formats, respectively, and, by leveraging the CMOs, the system does not have to deal with those message formats individually within the system—only JSON. Also, the “translations” into MIME are standard, so they do not have to be stored within the CMO; instead, they may be stored within the IMAP service portion of the system (i.e., in only one place). Thus, the centralized server needs only to inspect the JSON objects and then follow the rules about how to package the message object. This flexibility allows the same content to be read or transmitted to the user in a completely different format at an arbitrary time in the future, e.g., as an SMS text message in six months' time.
As may now be more fully appreciated, the flexible and dynamic server architecture system may now essentially function as a simple router, i.e., processing packets of a common object type according to a set of predefined rules.
Event-Driven Architecture
According to some embodiments, the flexible and dynamic server architecture system may be largely “event driven,” meaning that it simply reacts as a router, processing and redirecting incoming CMOs to the appropriate destinations as they occur. As such, the architecture may very rapidly and intelligently change the entry and/or exit point for a particular communication channel on behalf of a user. For example, if a user logs into a third party webmail server, the centralized server may receive access to the third party system directly, in which case it would have no problem synchronizing messages for the user with respect to that particular webmail server. However, in the case of an Exchange Server, the Exchange Server may look for the appropriate hardware token and/or certificate on a client before passing messages to such a client. According to some embodiments described herein, a user may declare his or her authorized device (e.g., his or her work-provided laptop or desktop device) as the entry and/or exit point for the communication channel corresponding to his or her Exchange server. At that point, the centralized server may receive and forward the encrypted messages received via the Exchange server to the user's client devices, but will not itself be able to read such messages—since the centralized server will not hold the key needed to decrypt the content.
In other embodiments, the flexible and dynamic server may comprise a “revolving switch”-style architecture. For example, in the case of users travelling abroad, it may become necessary for a user to reauthorize his or her credentials when using a third party webmail service. However, this may be difficult due to the new and changing IP addresses the user's devices may be utilizing abroad. Thus, according to such embodiments, the flexible and dynamic server may look to a user's work-provided laptop or desktop device and attempt to use that device as the entry and/or exit point for the communication channel corresponding to that particular third party webmail service. If the user's work-provided laptop or desktop device is down, the flexible and dynamic server may next look to the user's phone, and so on and so forth through the user's various client devices or the centralized server until finding a device that may be used as the gateway for that communication channel (it should be noted that the usable device may also be used as an extension of—or part of—the centralized server itself). Such a “revolving switch” architecture is made possible by the flexible and dynamic server maintaining a list of every authorized device for users of the centralized communication system.
Socket-Driven Architecture
According to some further embodiments, the flexible and dynamic server architecture may also be “socket-driven,” meaning that it utilizes sockets, e.g., Transmission Control Protocol (TCP) sockets, in a unique way to provide near latency-free communication routing. In particular, and according to some embodiments, the flexible and dynamic server with socket-driven architecture treats clients as extensions of the event-driven server. In such embodiments, the entire server architecture may comprise modular services connected together via sockets, where the clients are just another service that happens to have a user interface (UI). In some embodiments, the WebSocket protocol is used to implement the socket-driven server architecture (though such a choice is not strictly necessary, as different socket protocols may be employed for a given implementation, such as the User Datagram Protocol (UDP) or Raw IP sockets). WebSocket is a protocol providing an abstraction layer making full-duplex communications channels over a single TCP connection easy. The WebSocket protocol may make greater interaction possible between a browser (or other client) and a webserver (or other server) by facilitating live content and the creation of real-time content. This improved interaction is made possible by providing a standardized way for the server to send content to the browser (or other client) without first being solicited by the client. The WebSocket protocol also allows for messages to be passed back and forth between client and server, while keeping the connection open. In this way, a bi-directional ongoing conversation can take place between a client and the server.
Use of the socket-driven server architecture in certain embodiments described herein allows the flexible and dynamic server architecture system to rapidly change the gateways for particular communications channels. The use of sockets may also provide for increased speed in the routing of messages by the centralized server to the various client devices of users.
Unified Communication API
According to some embodiments, the techniques disclosed herein provide for a “unified communications API” for interacting with every major communication protocol (e.g., SMTP, IMAP/POP, SMS/MMS, XMPP, YMSG, etc.) and every major digital file type (e.g., .doc, .pdf, .png, .xlsx, .zip, etc.). This allows any type of client device, e.g., a smartphone, smart watch, or other connected and capable device, to connect to the centralized server with a single command, while allowing the server to handle everything else about the communication interaction. Further, by employing the CMO model, client devices do not need to do anything particular to initialize communication channels with the centralized server. They simply open the necessary sockets and allow the centralized server to carry the burden of message packaging and routing. Files of various types, e.g., audio and video files, may be stored in their original formats in a centralized master database or “source of truth,” so that they may be accessed, converted, routed, etc. at the appropriate time by the centralized communications server. For encrypted objects stored at the centralized communications server, there may be limited fields upon which the system is able to search for the file, such as file name, file length, etc. Clients may also generate descriptive tags to attach to the encrypted objects, so that the centralized server will also be able to perform limited content-based searching at a later time. The unified and universal nature of the messaging infrastructure proposed herein may lead to many significant API developments, and may be employed in many different fields where the client devices and/or locations at any given point in time are diverse and varied, such as emergency notification services, Amber Alert services, and others.
As may now be more fully appreciated, the clients in certain embodiments of the flexible and dynamic centralized server architecture described herein are not “clients” in the typical sense. Instead, the clients may actually be thought of as “extensions” to the centralized server itself, wherein the entire centralized server system utilizes modular pieces referred to herein as “services,” which may all be interconnected to one another through sockets. In some embodiments, e.g., WebSockets are used to extend these same services from the centralized server to the clients. For example, an IMAP client service on the centralized server could also be loaded onto any number of clients—and the centralized server may then keep track of which client is “valid” for any given communication channel, thus enabling the aforementioned flexible and dynamic “switching” architecture.
Flexible and Dynamic Server Architecture Infrastructure Examples
Referring now to
Server 106 in the server-gateway network architecture infrastructure 100 of
Servers 108 and 109 (referred to herein as “Channel 3” and “Channel 4,” respectively) represent third party instant message servers (e.g., a YAHOO! ® Messenger or AOL® Instant Messaging server). (AOL is a registered service mark of AOL Inc.) Third party instant messaging servers 108 and 109 may also be periodically pinged by sync server 105 to determine whether particular users of the flexible and dynamic server architecture system described herein have received any new instant messages via the particular third-party instant messaging services. Server 110 (referred to herein as “Channel 5”) represents a third party Exchange Server, e.g., a server managing a user's business email account (referred to herein as “Channel 5”). Server 111 (referred to herein as “Channel 6”) represents a cellular service provider's server. Such servers may be used to manage the sending and receiving of messages (e.g., email or SMS text messages) to users of mobile devices on the provider's cellular network. Cellular service provider servers may also be used: 1) to provide geo-fencing for location and movement determination; 2) for data transference; and/or 3) for live telephony (i.e., actually answering and making phone calls with a user's client device). In situations where two ‘on-network’ users are communicating with one another via the flexible and dynamic server architecture system itself, such communications may occur entirely via sync server 105, and third party servers 106-111 may not need to be contacted.
As may now be more fully appreciated, the “server-gateway” network architecture infrastructure 100 shown in
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
System unit 805 may be programmed to perform methods in accordance with this disclosure. System unit 805 comprises one or more processing units, input-output (I/O) bus 825 and memory 815. Access to memory 815 can be accomplished using the communication bus 825. Processing unit 810 may include any programmable controller device including, for example, a mainframe processor, a mobile phone processor, or, as examples, one or more members of the INTEL® ATOM™, INTEL® XEON™, and INTEL® CORE™ processor families from Intel Corporation and the Cortex and ARM processor families from ARM. (INTEL, INTEL ATOM, XEON, and CORE are trademarks of the Intel Corporation. CORTEX is a registered trademark of the ARM Limited Corporation. ARM is a registered trademark of the ARM Limited Company). Memory 815 may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid-state memory. As also shown in
Referring now to
The processing unit core 810 is shown including execution logic 880 having a set of execution units 885-1 through 885-N. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. The execution logic 880 performs the operations specified by code instructions.
After completion of execution of the operations specified by the code instructions, back end logic 890 retires the instructions of the code 850. In one embodiment, the processing unit core 810 allows out of order execution but requires in order retirement of instructions. Retirement logic 895 may take a variety of forms as known to those of skill in the art (e.g., re-order buffers or the like). In this manner, the processing unit core 810 is transformed during execution of the code 850, at least in terms of the output generated by the decoder, the hardware registers and tables utilized by the register renaming logic 862, and any registers (not shown) modified by the execution logic 880.
Although not illustrated in
Example 1 is a non-transitory computer readable medium that comprises computer executable instructions stored thereon to cause one or more processing units to: obtain, at a centralized server, one or more messages for a first user from each of a first plurality of communications channels, wherein each of the first plurality of communications channels are configured to connect to the centralized server and attempt to maintain a persistent connection to a client associated with the first user; receive, at the centralized server, one or more requests to change a gateway for a particular one of the first plurality of communication channels; and update, by the centralized server, the gateway for the particular one of the first plurality of communication channels according to the one or more requests.
Example 2 includes the subject matter of example 1, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a third party server.
Example 3 includes the subject matter of example 1, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a client.
Example 4 includes the subject matter of example 2, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a client.
Example 5 includes the subject matter of example 1, wherein the client is configured to connect to the centralized server via a socket protocol.
Example 6 includes the subject matter of example 5, wherein the socket protocol comprises a WebSocket protocol.
Example 7 includes the subject matter of example 1, further comprising instructions to store at least one of the one or more messages obtained at the centralized server as a JavaScript Object Notation (JSON) object.
Example 8 includes the subject matter of example 7, wherein the JSON object comprises a plurality of attributes comprising at least one of the following: a message type; a format type; a channel association; a sender association; and a recipient association.
Example 9 includes the subject matter of example 1, wherein at least one of the first plurality of communications channels is configured to connect to the centralized server via a socket protocol.
Example 10 includes the subject matter of example 4, wherein the instructions to update, by the centralized server, the gateway for the particular one of the first plurality of communication channels according to the one or more requests further comprise instructions to: update the particular one of the first plurality of communications channels from entering and exiting the centralized server via a third party server to entering and exiting the centralized server via a client; or update the particular one of the first plurality of communications channels from entering and exiting the centralized server via a client to entering and exiting the centralized server via a third party server.
Example 11 is a system, comprising: a memory; a centralized server; and one or more processing units, communicatively coupled to the memory and the centralized server, wherein the memory stores instructions to configure the one or more processing units to: obtain, at the centralized server, one or more messages for a first user from each of a first plurality of communications channels, wherein each of the first plurality of communications channels are configured to connect to the centralized server and attempt to maintain a persistent connection to a client associated with the first user; receive, at the centralized server, one or more requests to change an gateway device for a particular one of the first plurality of communication channels; and update, by the centralized server, the gateway device for the particular one of the first plurality of communication channels according to the one or more requests.
Example 13 includes the subject matter of example 11, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a third party server.
Example 13 includes the subject matter of example 11, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a client.
Example 14 includes the subject matter of example 12, wherein at least one of the first plurality of communications channels enters or exits the centralized server via a client.
Example 15 includes the subject matter of example 11, wherein the client is configured to connect to the centralized server via a socket protocol.
Example 16 includes the subject matter of example 15, wherein the socket protocol comprises a WebSocket protocol.
Example 17 includes the subject matter of example 11, further comprising instructions to store at least one of the one or more messages obtained at the centralized server as a JavaScript Object Notation (JSON) object.
Example 18 includes the subject matter of example 17, wherein the JSON object comprises a plurality of attributes comprising at least one of the following: a message type; a format type; a channel association; a sender association; and a recipient association.
Example 19 includes the subject matter of example 11, wherein at least one of the first plurality of communications channels is configured to connect to the centralized server via a socket protocol.
Example 20 includes the subject matter of example 14, wherein the instructions to update, by the centralized server, the gateway for the particular one of the first plurality of communication channels according to the one or more requests further comprise instructions to: update the particular one of the first plurality of communications channels from entering and exiting the centralized server via a third party server to entering and exiting the centralized server via a client; or update the particular one of the first plurality of communications channels from entering and exiting the centralized server via a client to entering and exiting the centralized server via a third party server.
Example 21 is a computer-implemented method, comprising: obtaining, at a centralized server, one or more messages for a first user from each of a first plurality of communications channels, wherein each of the first plurality of communications channels are configured to connect to the centralized server and attempt to maintain a persistent connection to a client associated with the first user; receiving, at the centralized server, one or more requests to change an gateway device for a particular one of the first plurality of communication channels; and updating, by the centralized server, the gateway device for the particular one of the first plurality of communication channels according to the one or more requests.
Example 22 includes the subject matter of example 21, further comprising the act of storing at least one of the one or more messages obtained at the centralized server as a JavaScript Object Notation (JSON) object.
Example 23 includes the subject matter of example 22, wherein the JSON object comprises a plurality of attributes comprising at least one of the following: a message type; a format type; a channel association; a sender association; and a recipient association.
Example 24 includes the subject matter of example 21, wherein at least one of the first plurality of communications channels is configured to connect to the centralized server via a socket protocol.
Example 25 includes the subject matter of example 21, wherein the act of updating, by the centralized server, the gateway for the particular one of the first plurality of communication channels according to the one or more requests further comprises performing the act of: updating the particular one of the first plurality of communications channels from entering and exiting the centralized server via a third party server to entering and exiting the centralized server via a client; or updating the particular one of the first plurality of communications channels from entering and exiting the centralized server via a client to entering and exiting the centralized server via a third party server.
Example 26 is a non-transitory computer readable medium comprising computer executable instructions stored thereon to cause one or more processing units to: obtain, at a first device associated with a first user, one or more messages for the first user from each of a first plurality of communications channels, wherein each of the first plurality of communications channels are configured to connect to the first device and attempt to maintain a persistent connection to the first device; receive, at the first device, one or more requests from a second device associated with the first user to send a message from a particular one of the first plurality of communication channels to the second device, wherein the second device is not configured to obtain messages from the particular one of the first plurality of communication channels when it requests the first device to send the message; and send, by the first device, the one or more requested messages from the particular one or more of the first plurality of communication channels to the second device; obtain, at the second device, one or more messages for the first user from the particular one of the first plurality of communication channels; receive, at the second device, one or more requests from the first device to send a message from the particular one of the first plurality of communication channels to the first device, wherein the first device is not configured to obtain messages from the particular one of the first plurality of communication channels when it requests the second device to send the message; and send, by the second device, the one or more requested messages from the particular one or more of the first plurality of communication channels to the first device.
In the foregoing description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. It will be apparent, however, to one skilled in the art that the disclosed embodiments may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the disclosed embodiments. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one disclosed embodiment, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
It is also to be understood that the above description is intended to be illustrative, and not restrictive. For example, above-described embodiments may be used in combination with each other and illustrative process steps may be performed in an order different than shown. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, terms “including” and “in which” are used as plain-English equivalents of the respective terms “comprising” and “wherein.”
