Patent ID: 12204568

DETAILED DESCRIPTION

Disclosed are systems, methods, and computer readable media for threading communications for computing devices across multiple formats and multiple protocols. More particularly, but not by way of limitation, this disclosure relates to systems, methods, and computer readable media to permit computing devices, e.g., smartphones, tablets, laptops, wearables, and the like, to present users with a seamless, multi-format, multi-protocol, communication threading system that may also perform semantic and predictive analysis based on the content of the multi-format, multi-protocol communications that are stored by a centralized communications server.

Use of a multi-format, multi-protocol, communication threading system allows users to view/preview all their messages, conversations, documents, etc., which are related (or potentially related) to a particular query in a single unified results feed. Such a multi-format, multi-protocol, communication threading system may also provide the ability to “stitch” together communications across one or more of a variety of communication protocols, including SMTP, IMAP/POP, SMS/MMS, XMPP, YMSG, and/or social media protocols. Further, the use of semantic and predictive analysis on the content of a user's communications may help the user discover potentially valuable and relevant messages, conversations, documents, etc., that would not be returned by current string-based or single-format/single-protocol, index-based searching techniques.

Referring now toFIG.1A, a server-entry point network architecture infrastructure100is shown schematically. Infrastructure100contains computer networks101. Computer networks101include many different types of computer networks available today, such as the Internet, a corporate network, or a Local Area Network (LAN). Each of these networks can contain wired or wireless devices and operate using any number of network protocols (e.g., TCP/IP). Networks101may be connected to various gateways and routers, connecting various machines to one another, represented, e.g., by sync server105, end user computers103, mobile phones102, and computer servers106-109. In some embodiments, end user computers103may not be capable of receiving SMS text messages, whereas mobile phones102are capable of receiving SMS text messages. Also shown in infrastructure100is a cellular network101for use with mobile communication devices. As is known in the art, mobile cellular networks support mobile phones and many other types of devices (e.g., tablet computers not shown). Mobile devices in the infrastructure100are illustrated as mobile phone102. Sync server105, in connection with database(s)104, may serve as the central “brains” and data repository, respectively, for the multi-protocol, multi-format communication composition and inbox feed system to be described herein. In the server-entry point network architecture infrastructure100ofFIG.1A, centralized sync server105may be responsible for querying and obtaining all the messages from the various communication sources for individual users of the system and keeping the multi-protocol, multi-format inbox feed for a particular user of the system synchronized with the data on the various third-party communication servers that the system is in communication with. Database(s)104may be used to store local copies of messages sent and received by users of the system, as well as individual documents associated with a particular user, which may or may not also be associated with particular communications of the users. As such, the database portion allotted to a particular user will contain a record of all communications in any form to and from the user.

Server106in the server-entry point network architecture infrastructure100ofFIG.1Arepresents a third-party email server (e.g., a GOOGLE ° or YAHOO! ° email server). (GOOGLE is a registered service mark of Google Inc. YAHOO! is a registered service mark of Yahoo! Inc.) Third party email server106may be periodically pinged by sync server105to determine whether particular users of the multi-protocol, multi-format communication composition and inbox feed system described herein have received any new email messages via the particular third-party email services. Server107represents a represents a third-party instant message server (e.g., a YAHOO! ° Messenger or AOL ° Instant Messaging server). (AOL is a registered service mark of AOL Inc.) Third party instant messaging server107may also be periodically pinged by sync server105to determine whether particular users of the multi-protocol, multi-format communication composition and inbox feed system described herein have received any new instant messages via the particular third-party instant messaging services. Similarly, server108represents a third-party social network server (e.g., a FACEBOOK ° or TWITTER ° server). (FACEBOOK is a registered trademark of Facebook, Inc. TWITTER is a registered service mark of Twitter, Inc.) Third party social network server108may also be periodically pinged by sync server105to determine whether particular users of the multi-protocol, multi-format communication composition and inbox feed system described herein have received any new social network messages via the particular third-party social network services. It is to be understood that, in a “push-based” system, third party servers may push notifications to sync server105directly, thus eliminating the need for sync server105to periodically ping the third-party servers. Finally, server109represents 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 multi-protocol, multi-format communication system itself, such communications may occur entirely via sync server105, and third-party servers106-109may not need to be contacted.

Referring now toFIG.1B, a client-entry point network architecture infrastructure150is shown schematically. Similar to infrastructure100shown inFIG.1A, infrastructure150contains computer networks101. Computer networks101may again include many different types of computer networks available today, such as the Internet, a corporate network, or a Local Area Network (LAN). However, unlike the server-centric infrastructure100shown inFIG.1A, infrastructure150is a client-centric architecture. Thus, individual client devices, such as end user computers103and mobile phones102may be used to query the various third-party computer servers106-109to retrieve the various third-party email, IM, social network, and other messages for the user of the client device. Such a system has the benefit that there may be less delay in receiving messages than in a system where a central server is responsible for authorizing and pulling communications for many users simultaneously. Also, a client-entry point system may place less storage and processing responsibilities on the central multi-protocol, multi-format communication composition and inbox feed system's server computers since the various tasks may be distributed over a large number of client devices. Further, a client-entry point system may lend itself well to a true, “zero knowledge” privacy enforcement scheme. In infrastructure150, the client devices may also be connected via the network to the central sync server105and database104. For example, central sync server105and database104may be used by the client devices to reduce the amount of storage space needed on-board the client devices to store communications-related content and/or to keep all of a user's devices synchronized with the latest communication-related information and content related to the user. It is to be understood that, in a “push-based” system, third party servers may push notifications to end user computers102and mobile phones103directly, thus eliminating the need for these devices to periodically ping the third-party servers.

Referring now toFIG.2A, an example processing device200for use in the communication systems described herein according to one embodiment is illustrated in block diagram form. Processing device200may serve in, e.g., a mobile phone102, end user computer103, sync server105, or a server computer106-109. Example processing device200comprises a system unit205which may be optionally connected to an input device230(e.g., keyboard, mouse, touch screen, etc.) and display235. A program storage device (PSD)240(sometimes referred to as a hard disk, flash memory, or non-transitory computer readable medium) is included with the system unit205. Also included with system unit205may be a network interface220for communication via a network (either cellular or computer) with other mobile and/or embedded devices (not shown). Network interface220may be included within system unit205or be external to system unit205. In either case, system unit205will be communicatively coupled to network interface220. Program storage device240represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic memory, including solid-state storage elements, including removable media, and may be included within system unit205or be external to system unit205. Program storage device240may be used for storage of software to control system unit205, data for use by the processing device200, or both.

System unit205may be programmed to perform methods in accordance with this disclosure. System unit205comprises one or more processing units, input-output (I/O) bus225and memory215. Access to memory215can be accomplished using the communication bus225. Processing unit210may 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). Memory215may 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 inFIG.2A, system unit205may also include one or more positional sensors245, which may comprise an accelerometer, gyrometer, global positioning system (GPS) device, or the like, and which may be used to track the movement of user client devices.

Referring now toFIG.2B, a processing unit core210is illustrated in further detail, according to one embodiment. Processing unit core210may be the core for any type of processor, such as a micro-processor, an embedded processor, a digital signal processor (DSP), a network processor, or other device to execute code. Although only one processing unit core210is illustrated inFIG.2B, a processing element may alternatively include more than one of the processing unit core210illustrated inFIG.2B. Processing unit core210may be a single-threaded core or, for at least one embodiment, the processing unit core210may be multithreaded, in that, it may include more than one hardware thread context (or “logical processor”) per core.

FIG.2Balso illustrates a memory215coupled to the processing unit core210. The memory215may be any of a wide variety of memories (including various layers of memory hierarchy), as are known or otherwise available to those of skill in the art. The memory215may include one or more code instruction(s)250to be executed by the processing unit core210. The processing unit core210follows a program sequence of instructions indicated by the code250. Each instruction enters a frontend portion260and is processed by one or more decoders270. The decoder may generate as its output a micro-operation such as a fixed width micro-operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The front end260may also include register renaming logic262and scheduling logic264, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.

The processing unit core210is shown including execution logic280having a set of execution units285-1through285-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 logic280performs the operations specified by code instructions.

After completion of execution of the operations specified by the code instructions, backend logic290retires the instructions of the code250. In one embodiment, the processing unit core210allows out of order execution but requires in order retirement of instructions. Retirement logic295may 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 core210is transformed during execution of the code250, at least in terms of the output generated by the decoder, the hardware registers and tables utilized by the register renaming logic262, and any registers (not shown) modified by the execution logic280.

Although not illustrated inFIG.2B, a processing element may include other elements on chip with the processing unit core210. For example, a processing element may include memory control logic along with the processing unit core210. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.

Multi-Protocol, Multi-Format Inbox Feed

FIG.3Ashows an example of a multi-protocol, person-centric, multi-format inbox feed300, according to one or more disclosed embodiments. The inbox feed300shown inFIG.3Amay, e.g., be displayed on the display of a mobile phone, laptop computer, or other computing device. In certain embodiments, elements of inbox feed300may be interacted with by a user utilizing a touchscreen interface or any other suitable input interface.

As is shown across the top row of the interface302, the multi-format, multi-protocol messages received by a user of the system may be grouped by protocol (e.g., Email, IM/SMS, Video, Voice, etc.), or all messages may be combined together into a single, unified inbox feed, as is shown inFIG.3A. Row304in the example ofFIG.3Arepresents the first “person-centric” message row in the user's unified inbox feed. As shown inFIG.3A, the pictorial icon and name of the sender whose messages are listed in row304appear at the beginning of the row. The pictorial icon and sender name indicate to the user of the system that all messages that have been aggregated in row304are from exemplary user ‘Emma Poter.’ Note that any indication of sender may be used. Also present in row304are several graphical icons306that represent links to messages of different types that have been received from Emma Poter. For example, Emma Poter has sent the particular user whose inbox feed is shown inFIG.3Atwo email messages, one instant message, five video messages, and one voice message. The user interface may utilize icons, as is shown inFIG.3A, or it may use any other suitable form of indication, such as text, grids, charts, or any other form of personalized identification. The types of messages/communication used in the inbox feed may be selected or personalized, as well. The timestamp (e.g., 1:47 pm in row304) may be used to indicate the time at which the most recently received message has been received from a particular sender.

Moving down to row308of inbox feed300, messages from a second user, Peter Ehrmanntraut, have also been aggregated into a single row of the feed. As is displayed on the righthand side of row308is reveal arrow310. Selection of reveal arrow310may provide additional options to the user such as to reply, delay reply/delay send, forward, return a call, favorite, archive, or delete certain message from a particular sender. Further, the reveal action may conveniently keep the user on the same screen and allows for quick visual filtering of messages. Gestures and icon features may help the user with the decision-making process regarding the choice to reply, delay replying (including the time delaying of response across multiple protocols), delete, mark as spam, see a full message, translate, read, or flag a message as being unread. With respect to the “delay reply/delay send” option, the multi-protocol, multi-format communication system may determine, based on the determined outgoing message format and protocol, that a particular communication in a particular format (or that is being sent via a particular protocol) should be delayed before being sent to the recipient. For example, a video or voice message may not be appropriate to send at midnight, and so the system may delay sending the message until such time as the recipient is more likely to be awake, e.g., 9:00 am. On the other hand, the outgoing message is in text format and being delivered via the SMS protocol, sending the message at midnight may be more socially appropriate. Delay reply/delay send may also take into account the time zone of the recipient and choose a more socially appropriate delivery time for a message based on the recipient's local time.

Finally, moving down to row312, the ‘grayed-out’ characteristic of the row may be used to indicate that there are no remaining unread/unopened messages of any format or protocol type remaining from a particular sender. Alternately, each message type may be individually grayed out, indicating that there are no new messages of a particular type. It is to be understood that the use of a grayed out row is merely exemplary, and that any number of visual indicators may be used to inform the user of the device that no unread messages remain.

As may now be appreciated, the multi-protocol, person-centric, multi-format inbox feed300ofFIG.3Amay provide various potential benefits to users of such a system, including: presenting email, text, voice, video, and social messages all grouped/categorized by contact (i.e., ‘person-centric,’ and not subject-people-centric, subject-centric, or format-centric); providing several potential filtering options to allow for traditional sorting of communications (e.g., an ‘email’ view for displaying only emails); and displaying such information in a screen-optimized feed format. Importantly, centralization of messages by contact may be employed to better help users manage the volume of incoming messages in any format and to save precious screen space on mobile devices (e.g., such a display has empirically been found to be up to six to seven times more efficient that a traditional inbox format). Further, such an inbox feed makes it easier for a user to delete unwanted messages or groups of messages (e.g., spam or graymail). The order of appearance in the inbox feed may be customized as well. The inbox feed may default to showing the most recent messages at the top of the feed. Alternatively, the inbox feed may be configured to bring messages from certain identified “VIPs” to the top of the inbox feed as soon as any message is received from such a VIP in any format and/or via any protocol. The inbox feed may also alert the user, e.g., if an email, voice message, and text have all been received in the last ten minutes from the same person—likely indicating that the person has an urgent message for the user. The inbox feed may also identify which companies particular senders are associated with and then organize the inbox feed, e.g., by grouping all communications from particular companies together.

In other embodiments, users may also select their preferred delivery method for incoming messages of all types. For example, they can choose to receive their email messages in voice format or voice messages in text, etc.

Referring now toFIG.3B, an example of a multi-protocol, multi-format inbox feed for messages to and from a particular user320is shown, according to one or more disclosed embodiments. As is shown across the top row of the interface322, the messages from a particular user, in this case ‘Peter Ehrmanntraut’ may be displayed in a single multi-format, multi-protocol message feed. Row322in the example ofFIG.3Balso presents the user with the opportunity to select the particular sender's ‘Messages,’ Profile,′ or ‘Vault’ storage, which is a document repository of files shared between the user and a particular sender (e.g., email attachments, MMS, etc.). As shown inFIG.3B, the pictorial icon324and name of the sender whose messages are listed in interface320appear at the top of the communications page. Also present in interface320is search icon326, which may be activated to search across all message formats and protocols (e.g., including voice, video, SMS, and email messages) from a particular sender and/or for a particular search term(s) or topic, as will be described in further detail below. Message items may also be sorted in the feed by various characteristics such as time of receipt, format, or other content and/or semantic-based ranking schemes. Moving down to the messages portion of interface320, checkbox328represents the first email message received from user Peter Ehrmanntraut, whereas checkbox330represents the first new video message from user Peter Ehrmanntraut. Finally, grayed-out checkbox332represents an aggregation of voice messages that have already been listened to by the user.

Referring now toFIG.3C, an example of a preview pane340for a multi-protocol, multi-format inbox feed for messages to and from a particular user is shown, according to one or more disclosed embodiments. As is displayed inFIG.3C, the message associated with checkbox328has been opened to provide a more in-depth preview of the associated email text. According to some embodiments, the recipients342are listed out above the body344of the email, and a link346may be activated that causes the application to retrieve the full email message from either the system's sync server or third-party email servers. The interface may also provide a number of preview quick action buttons348to be performed on the message that is being previewed, e.g., reply, reply all, forward, delete, etc.

Multi-Format, Multi-Protocol, Communication Threading System

As mentioned above, there are multiple ways by which the centralized communication system may associate or “stitch” together multiple messages across disparate messaging formats and protocols, creating a “relationship” between each associated message. Such relationships, which may be created uniquely for a variety of messages in a variety of formats and protocols through the system, may be used to create a “relationship map,” i.e., a cluster of relationships connecting each message to other messages with varying degrees of separation. The relationship map may be analyzed to determine communication patterns (e.g., system-wide or on a per-user basis), provide greater search relevancy with messages across format/protocols, and provide other such insights and benefits.

According to a first embodiment, direct user actions taken in a centralized communications application may be used to associate messages as part of the same thread of conversation. For example, if a user has ‘Message1’ open and clicks a ‘Reply’ button in the multi-format, multi-protocol communication application, thus opening a ‘Message2,’ then the system may know to associate ‘Message1’ and ‘Message2’ together as being part of the same “thread,” even if, for instance, ‘Message1’ was received via an SMS protocol and ‘Message2’ is eventually sent via an email protocol using the multi-format, multi-protocol communication application. Direct user actions taken from within the multi-format, multi-protocol communication application may be logged by the application, synced with the centralized communication server and any other properly authenticated client(s), and stored for future recall when a user requests to see a “message thread” view.

According to a second embodiment, the system may use semantic matching (or other search-based/keyword message association techniques) to associate messages. A variety of semantic and search-based/keyword techniques for associating related messages will be discussed in further detail below in reference toFIGS.4and5A-5D.

According to a third embodiment, element-matching techniques may be employed to associate messages. For example, messages that match each other based on subject lines or senders/recipient lists, or which have similar quoted text within them, etc., may be intelligently associated together—even if the centralized system has not been provided with data that otherwise affirmatively associates the messages together as being a part of the same messaging thread or chain. This embodiment will be discussed in further detail below in reference toFIG.3G.

According to a fourth embodiment, “state-matching” techniques may be employed to associate messages. For example, certain third-party services which can integrate with the centralized communication system (hereinafter, a “Valid Third-Party Service”) may specifically tag a message as a “Reply” to another message, and, thus, the centralized system may associate such messages as a part of the same thread or chain, even if the action to send the initial Reply message took place outside of the centralized communication system, i.e., was made directly via the Valid Third-Party Service's system.

One or more of the four techniques outlined above may be used in combination with each other in order for the system to most effectively thread together disparate messages across multiple formats and/or multiple protocols in a way that is most beneficial for the individual user of the centralized communication system.

Referring now toFIG.3D, an example of a multi-format, multi-protocol threaded communication search results page360for a particular query is shown, according to one or more disclosed embodiments. At the top of the page360may be a search input box361. A user may, e.g., enter his desired query string into the search input box361and then click on the magnifying glass icon to initiate the search process. Search results row362may be used for providing the user with a choice of additional search-related features. For example, the user may be provided with a selection between a “global” search, i.e., searching everywhere in the application's ecosystem, and a “narrow” search, i.e., searching only through content on a screen or small collection of screens. As shown inFIG.3D, search results363may be displayed in a unified feed or grouped by type (e.g., messages, files, etc.), query type, search area selection (e.g., “global” v. “narrow”), or time. Each search result may optionally include an indication of the messages format365and/or a time stamp364to provide additional information to the user. A given implementation may also optionally employ an “Other Results” feed366as a part of the same user interface that displays the search results363. These results could come from sources other than traditional message-related sources, e.g., a user's personal file collection stored with a central database, personal profile information from contacts of the user, etc.

Referring now toFIG.3E, an example of a stitching view mode for a multi-format, multi-protocol communication system370is shown, according to one or more disclosed embodiments. According to some embodiments, across the top of the user interface may be located various user interface elements such as a “Back” button371, and other message action buttons372(e.g., reply, reply all, forward, delete, sleep, archive, etc.). Next, the active message373content may be displayed in a portion of the screen, including a subject line374, message content375, time stamp364, and optionally a quoted text button376, which may be activated by the user to display previous conversation history, such as old emails in the thread, full SMS trails, etc. A given implementation may also optionally employ a “Related Messages” feed377as a part of the same user interface that displays the selected message373. These related messages378could include parsed content from the body of the selected messages (i.e., previously recorded replies and forwards), as well as messages across other formats and protocols (represented by icon379), such as voice messages, SMS conversations, and phone call log entries.

Referring now toFIG.3F, an example of a stitching view mode with an expanded message for a multi-format, multi-protocol communication system380is shown, according to one or more disclosed embodiments. Related message preview381may be displayed on the screen, e.g., in response to the user selecting a particular related message378from the related messages feed377. Related messages previews can be selected by the user to open the full details of a message without leaving the threaded results screen. A quoted text button383may also be activated by the user to display additional content from the related message. Options to further explore original content may also be made available to the user via the related message381interface, e.g., taking the user to see the original SMS thread belonging to the single SMS message shown in the related message381interface.

Referring now toFIG.3G, an example of element matching for a stitching view mode for a multi-format, multi-protocol communication system is shown, according to one or more disclosed embodiments. As mentioned above, element matching may seek to associate otherwise unassociated messages by matching on subject lines, senders/recipient lists, quoted text, etc. Thus, as shown inFIG.3G, Message1390and Message2391may each include elements such as: a sender, a recipient list, a subject line, a timestamp, and a message body text. The matched elements392that the system may determine Message1390and Message2391to have in common may then include, but not be limited to: timestamp (e.g., within a particular range), sender, recipient list (e.g., a certain number of recipients in common), and quoted text (e.g., a certain amount of message body text in common). Based on these matched elements, the system may intelligently determine that Message1390and Message2391are associated with one another and belong as part of the same thread of communication. The messages may thus be displayed in an appropriate and beneficial manner to the user, even if Message1390and Message2391come from vastly different messaging protocols and/or have different formats.

Multi-Format, Multi-Protocol, Communication Indexing and Searching

FIG.4shows a flowchart400of one embodiment of a method of performing a multi-format, multi-protocol, contextualized communication search, according to one or more disclosed embodiments. First, the system may prompt the user to input his or her credentials so that he or she may be authenticated and authorized (Step405). Next, the sync server105and/or third-party servers106-109may verify and validate the user's credentials as being authorized to receive communications associated with a particular account(s) tied to a particular messaging service(s) (Step410). Next, the user's credentials may be encrypted and stored at the sync server105so that the user's messages may continue to be retrieved by the system (Step415). It is to be understood that any suitable authentication framework, such as OAuth, may be used to authenticate the user's credentials and that the credentials need not necessarily be stored at the sync server. Once the user's credentials have been verified and stored, the system may attempt to synchronize the user's multi-protocol, person-centric, multi-format unified messaging inbox feed with the various external communication servers hosting the user's messages from the various third-party messaging services, e.g., by using one or more third-party credentials of the first user stored at the sync server (Step420). Next, the system may receive a query from a particular user's client device (e.g., to pull new communications directed to the user) and determine that the client device has access to perform the query (Step425).

Assuming the client device has access, in one embodiment, the query will be sent to a central server(s) of the multi-format, multi-protocol, contextualized communication search system, and, based on the nature of the query, a semantic analysis and/or predictive analysis of the query terms may be performed (Step430). In such a “server-centric” approach, the central server(s) run search logic through a centralized content database, and the central server(s) may perform real-time relevancy ranking. The results (along with the rankings) may then be sent to the client, so that the client may display the results to a user. This “server-centric” approach may allow for enhanced speed and consistency across clients and services, and may also allow for greater richness in index data modeling. Other query implementations may utilize a more “client-centric” approach. In such a “client centric” approach, a user inputs a query on a client device, and then the client device may run search logic through a client database, allowing the client device to perform real-time relevancy ranking, and display the results on the client device. This option allows for enhanced user privacy, but may sacrifice speed. Still other query implementations may utilize a “hybrid” search architecture, which may comprise a combination of the “server-centric” and “client-centric” approaches outlined above. A “hybrid” architecture may be of particular value when the client device is either not connected to the Internet or when the two databases (i.e., the client database and server database) are not in perfect sync.

As discussed above, a semantic analysis may be performed on extant content on client devices, the system servers, and/or third-party content host servers in order to determine the particular keywords that are relevant and related to the subject matter of a given query(ies), document(s), or communication(s), etc. These keywords may be used to generate a “tag cloud” associated with the given query(ies), document(s), or communication(s), etc. These tag clouds may then themselves be used to generate further “predictive tag clouds,” based on the particular content of the words in the generated tag cloud, as will be described in further detail below. The tag clouds and predictive tag clouds may then be used to “stitch” together, i.e., associate, related query(ies), document(s), or communication(s), etc. into “clusters” (Step435).

Once the related query(ies), document(s), or communication(s), etc. have been connected together via the above-described searching process, the user's query may be executed. For example, if the user's query is asking for all content related to a particular second user, the system may search all ‘person-centric’ content across multiple data formats and/or protocols related to the particular second user (Step440). For example, if the user clicked on row308shown inFIG.3A, a row which is associated with user ‘Peter Ehrmanntraut,’ the system could retrieve all the identified emails, video messages, instant messages, voice messages, social media messages, etc. to or from user ‘Peter Ehrmanntraut,’ resulting in, e.g., the screen320fromFIG.3Bbeing displayed on a display screen of the client device of the user that issued the query.

If the user's query is asking for all content related to a particular topic(s) that the user has discussed with user ‘Peter Ehrmanntraut,’ the system may search all ‘tag-centric’ content across multiple data formats related to the particular topic(s) (Step445). For example, if the user typed the term ‘book’ into search box326shown inFIG.3B, the system could retrieve all the identified emails, video messages, instant messages, voice messages, social media messages, etc. from user ‘Peter Ehrmanntraut,’ having a tag cloud including the term ‘book’ or a predictive tag cloud including the term ‘book,’ resulting in, e.g., the screen360fromFIG.3Dbeing displayed on a display screen of the client device of the user that issued the query.

Once all the query-relevant, contextualized multi-format, multi-protocol data has been located by the server, packaged, and then sent to the client device issuing the query, the client device retrieves the information, reformats it (if applicable), ranks or sorts it (if applicable), and displays the information on a display screen of the client device (Step450).

FIG.5Ashows an example of communications clustering500, according to one or more disclosed embodiments. Exemplary communications clusters500are comprised of seven individual conversations,501-507. For example, Conversation #1501comprises an instant messaging conversation between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Peter Ehrmanntraut’ (appearing on the right-hand side of the conversation box). Conversation #1appears to be a conversation about sports generally, and baseball in particular. Conversation #2502comprises an email conversation that is also between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Peter Ehrmanntraut’ (appearing on the right-hand side of the conversation box). Conversation #2appears to be a conversation about dinner generally, and Indian food in particular. Conversation #3503comprises an instant messaging conversation between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Bob Withers’ (appearing on the right-hand side of the conversation box). Conversation #3appears to be a conversation about movies generally, and a movie about Jackie Robinson in particular. Conversation #4504comprises a video message conversation between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Bob Withers’ (appearing on the right-hand side of the conversation box). Conversation #4appears to be a conversation about movies generally, and Batman in particular. Conversation #5505comprises an instant messaging conversation between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Peter Ehrmanntraut’ (appearing on the right-hand side of the conversation box). Conversation #5appears to be a conversation about dinner generally, and pizza in particular. Conversation #6506comprises a voice message conversation between the user of the client device (appearing on the left-hand side of the conversation box) and user ‘Joe Dawson Withers’ (appearing on the right-hand side of the conversation box). Conversation #6appears to be a conversation about travel generally, and Italy in particular. Finally, Conversation #7507comprises a voice message conversation between the user of the client device (appearing on the left-hand side of the conversation box) and another user (appearing on the right-hand side of the conversation box), who, in this case, may not be a current contact of the user of the client device. Conversation #7appears to be a conversation about family generally, and moms and dads in particular. Note that, to attain semantic contextual information from communications in certain data formats (e.g., video or voice), an intermediary transcription step may be required to convert the audio content of the message into textual content that may be indexed, semantically and predictively analyzed, and, ultimately, clustered and searched upon.

Various conversations inFIG.5Aare shown as being “clustered” together, as represented by the bi-directional arrows connecting the various conversation boxes. Clustering may be used to connect conversations in a more rich and contextual fashion than is provided by a simple linear interface (i.e., message, reply, surreply, etc.). Some of the conversations in Figure appear clustered for obvious reasons, but others are clustered for more subtle contextual and semantic reasons. For example, Conversation #1501is stitched together with Conversation #2502and Conversation #5505because the other party to the conversation, ‘Peter Ehrmanntraut,’ is in common among each conversation. Conversation #1501is stitched together with Conversation #3503, however, because of a similarity in message protocol, i.e., both conversations are in an instant messaging protocol and because of a similarity in content, i.e., baseball and Jackie Robinson may be deemed by the system to be semantically related topics. It is to be understood that, based upon the query, certain communications that are clustered together may be excluded from the query. For example, even though Conversation #1501and Conversation #3503are clustered together, if the search query is for all content related to user ‘Peter Ehrmanntraut,’ then Conversation #3503may not be returned by the query since its only link to Conversation #1501was based on protocol type and subject matter content.

Moving on to Conversation #2502, it is further clustered with Conversation #6506based on the fact that each conversation mentions a country (India,′ in the case of Conversation #2502, and ‘Italy’ in the case of Conversation #6506), and these tags have been predictively semantically linked with one another in the example shown inFIG.5A, perhaps because they both relate to potential travel destinations, potential food categories, or the like. Conversation #2502, is further clustered with Conversation #5505based on the fact that each conversation relates to the topic of dinner.

Moving on to Conversation #3503, it is further clustered with Conversation #4504based on the fact that each conversation mentions a movie (Jackie Robinson,′ in the case of Conversation #3503, and ‘Batman’ in the case of Conversation #4504), and these tags have been predictively semantically linked with one another in the example shown inFIG.5A. Conversation #3503, is further clustered with Conversation #5505based on the fact that each conversation is in instant messaging format.

Moving on to Conversation #5505, it is further clustered with Conversation #6506based on the fact that each conversation mentions a topic that has been semantically-linked to the concept of ‘Italy’ (pizza,′ in the case of Conversation #5505, and the word ‘Italy’ itself in the case of Conversation #6506).

Finally, Conversation #6506, is further clustered with Conversation #7507based on the fact that each conversation is in a video messaging format.

FIG.5Bshows an example of communications semantic analysis and predictive analysis, according to one or more disclosed embodiments. Beginning on the left-hand side ofFIG.5B, an expanded view of Conversation #1501is shown. Based on a semantic analysis of the content of Conversation #1501, the tag cloud510has been generated, comprising the keywords relating to the main semantic topics expressed in Conversation #1501. As may be seen, tag cloud510comprises mainly nouns, including names, dates, places, and proper nouns. Less important words and connective words, such as “a,” “for,” “my,” “what,” “is,” etc. are not deemed semantically important enough to be included in tag cloud510representing the content of Conversation #1501.

Based off each word in tag cloud510, and additional predictive analysis may be performed, resulting in predictive tag cloud520. In the example ofFIG.5B, the predictive tag cloud for the word “San Francisco” is shown. The predictive tag clouds may be used by the system to stitch together conversations, documents, or communications that a user may not have even considered to be relevant to his or her query, thus revealing additional potential business and/or personal value to the user.

As the centralized messaging database grows, it will become possible for the system to rely more and more on its own data to drive the initial tag cloud and predictive tag cloud algorithms. For example, if a particular user always begins emails with, “Hope you're doing well,” the system could determine that it was not necessary to repeatedly index that phrase, and instead simply keep a note of a reference to the original phrase. This process of contextual learning may be employed for an individual user's content, as well as across global content stored in the centralized messaging database (e.g., the world may say, “Congratulations on the new baby!” phrase quite often). This process may allow for less duplication, smaller index sizes, etc.

Further, contextual learning may be used to determine that a particular user has recently started to use one phrase in place of another, e.g., if the user just spent a year living in London, he or she may begin to use the phrase “to let” instead of “for rent.” In such a situation, a machine learning system using contextual cues could determine that, for that the particular user only, the phrases “to let” and “for rent” are considered like terms and, therefore, would share word mapping. This way, when the user searches for “rent,” the system can include references to “let” as potentially relevant matches. Another machine learning technique(s) that may be employed include techniques to influence index term weight assignment. For example, a particular user's searches may indicate that “time” is not a significant search parameter for the user. In other words, the particular user may only really search for content within a one-week timeframe of the present date. The centralized system could monitor such behaviors and adjust the index weights at regular or semi-regular intervals accordingly to assign greater weight to the timestamp on recent content and reduce the weight when timestamps are “old” for that particular user, thus allowing the system to provide a more customized and relevant search experience. By employing these customized contextual learning techniques, the end result is that the same content, e.g., an email sent from User A to User B, could have two different index mappings in the centralized system so that both User A and User B can have an optimized search/threading experience. The system could also perform machine learning techniques based on historic patterns of communication to influence predictive threading. For example, in protocols where data is limited, e.g. SMS, the system could employ a historic look-back on the User's communication in order to determine the likelihood of a conversation to/from the User pervading across multiple protocols. That assigned weight pertaining to the likelihood of a conversation ‘jumping’ protocol could then impact the stitching results for that User. In this way, the system is able to apply machine learning techniques on an individual level in order to provide the most relevant search results to the user across formats and protocols.

FIG.5Cis a flowchart of one embodiment of a method for performing a “person-centric” content search across multiple data formats and/or protocols, according to one or more disclosed embodiments. The flowchart inFIG.5Cis labeled440to indicate that it represents a more detailed build out of Step440in the flowchart ofFIG.4. First, the system may receive a query requesting information relating to another particular person, ‘Person A’ (Step530). Next, the system may search its database(s) and/or the relevant third-party host servers across multiple data protocols and formats for conversations, messages, etc. relating to ‘Person A’ (Step535). The search may return messages sent to or from ‘Person A,’ as well as messages that mention ‘Person A,’ or even messages that mention businesses, acquaintances, or interests, etc. that are associated with ‘Person A.’ Next, the system may search its database(s) and/or the relevant third-party host servers across multiple data protocols and formats for documents relating to ‘Person A’ (Step540). As with the conversation-focused search, the document-focused search may return documents sent to or from ‘Person A,’ as well as documents created by or for ‘Person A’, or documents that mention ‘Person A,’ or even documents that mention businesses, acquaintances, or interests, etc. that are associated with ‘Person A.’ The results of “person-centric” content search may then be packaged and returned to the client device as appropriate.

FIG.5Dis a flowchart of one embodiment of a method for performing a “tag-centric” content search across multiple data formats and/or protocols, according to one or more disclosed embodiments. The flowchart inFIG.5Dis labeled445to indicate that it represents a more detailed build out of Step445in the flowchart ofFIG.4. First, the system may receive a query requesting information relating to a particular tag or set of tags, e.g., tag clouds510or520discussed above with respect toFIG.5B(Step550). Next, the system may search its database(s) and/or the relevant third-party host servers across multiple data protocols and formats for conversations, messages, etc. relating to the particular tag or set of tags (Step555). Next, the system may search its database(s) and/or the relevant third-party host servers across multiple data protocols and formats for documents relating to the particular tag or set of tags (Step560). The results of “tag-centric” content search may then be packaged and returned to the client device as appropriate. As may now be understood, certain user queries may be only “person-centric,” others may be only “tag-centric,” while still other queries may combine elements of both “person-centric” and “tag-centric” searching.

FIG.6is an example600of automated data visualization that may segment one or more data files into different data portions based on data protocols, according to one or more disclosed embodiments. In example600, a data file602may be processed by one or more machine learning models in order to generate isolated sections604and thereafter output predictive associations606based on tags of data protocols and/or formats identified in data file602by the machine learning models. This allows better searching, indexing, and/or segmenting of data file602based on corresponding child data assets and/or contents identified in data file602using the machine learning model(s) trained for data content, protocol, and/or format identification and segmentation.

In automated data visualization (ADV) content within data files and/or documents is identified, segmented, and/or broken apart from the corresponding files based on different data protocols and formats. For example, a word document may include text and pictures, or other media content including video, audio, etc. Further, an Excel or .xml spreadsheet may include multiple tables with different sections having text, graphs, pictures, and the like. Different data types and tables may therefore have different data assets, formats, protocols, and the like. However, traditional data extraction processes for individual files may be bound by either extracting regions of like properties (e.g., image portions of a larger image, or text from a document having an identified name, address, title, etc.) or by semantic labeling of identified content, which is schema driven (e.g., by identifying a portion of a data set video/picture, such as one that may include a cat and/or by generating another form of data such as text, audio, video, etc. that references a “cat”). These conventional operations may be limited by failing to address and/or operate when faced with multiformat data files, such as a spreadsheet with embedded images.

Thus, a machine learning model and/or engine may ingest a data file and break up the data file into one or more data portions and/or child data files that may be processed, searched, indexed, and the like. This may be done using data parsing and content identification logic based on one or more AI engines, rules, and/or machine learning models. Thus, AI and/or machine learning may identify and isolate independent data regions contained within a single data file or object. Once isolated, the utilities of the AI and/or machine learning models and engines may extract the child data assets into native formats that may or may not match the original data file type and/or format. The child data assets may correspond to content that may or may not conform to a specific predefined schema for the corresponding data file, such as data file602.

In this regard, data file602includes text data608, an image610, and a spreadsheet612. Each of these correspond to different data portions within data file602, and may therefore be child data assets and/or contents that may be parceled, extracted, and/or segmented from data file602. Using one or more machine learning models and/or operations, different data protocols and/or formats may be identified for different data portions in data file602corresponding to text data608, image610, and spreadsheet612, as well as any other child data assets or contents that may be contained within the corresponding data file, document, or the like. The machine learning or other AI models and/or systems may be trained and/or configured to identify such child data assets based on their corresponding object similarity, formats, and/or individual properties including tags, metadata, and/or data content.

Data file602may then be segmented and/or parceled into isolated sections604, where isolated sections604include isolated text data614, an isolated image616, and an isolated spreadsheet618corresponding, respectively, to text data608, image610, and spreadsheet612. In this regard, the machine learning model(s) and/or other AI system may be used to identify distinct objects within data file602, which may be based on correlations to other data files, formats, portions, and/or protocols. Further, analytics may be performed on the data, metadata, and/or file identifiers or tags in order to identify isolated sections604. Once identified and/or segmented, predictive associations606may be generated to associate each of isolated sections604with a corresponding content and/or segmented data portion in order for searching, indexing, and/or generating of those child assets and/or contents.

Predictive associations606therefore include text associations620, image associations622, and spreadsheet associations624. Each of these associations may be used to correlate the segmented and/or identified child data assets with other content and/or data assets, including data files and/or content within such data files. As such, text associations620may include isolated text data614associated with similar text patterns626, image associations622may include isolated image616associated with similar image patterns628, and spreadsheet associations may include isolated spreadsheet618associated with similar spreadsheet patterns630. Further, if predictive associations606are not correct and/or do not properly associate child content and/or assets in data file602with corresponding contents, protocols, and/or data, reprocess requests632may be executed. This may include utilizing one or more machine learning or other AI systems in order to re-associate portions of data file602with other corresponding data files, contents, and/or portions.

FIG.7is a flowchart700of a method for providing automated data visualization for data files based on different data protocols for portions of the data files, according to one or more disclosed embodiments. Note that one or more steps, processes, and methods described herein of flowchart700may be omitted, performed in a different sequence, or combined as desired or appropriate.

First, at Step702, a first data file having one or more first data portions and one or more second data files having one or more second data portions are obtained. The data files may correspond to a document, image, video, spreadsheet, or other computing file that may include different data portions. In this regard, each data portion may have a corresponding data format and/or protocol, such as .doc or .docx text data, .jpeg or other image data format, a video data format or protocol, .xml or other spreadsheet type data format, and the like. In this regard, each data file may include multiple different data portions having different types, formats, and/or protocols that may be separately segmented and/or searched.

At Step704, an analysis of the different data portions in the obtained data files is performed. The analysis may correspond to executing one or more machine learning models, engines, and/or systems that are trained to analyze, determine, and identify different data and/or file formats within data files, which allow for breaking down and parceling of data files based on different data portions and their corresponding formats and/or data protocols. For example, in a data file, such as a document, a user may view text, an image, a video, a spreadsheet, and/or other data portions. Each may correspond to distinct data objects in the file or document, however, conventional computing systems may not identify each data portion. Thus, one or more machine learning models may be used to identify such data portions, types, and/or protocols within the data file. The machine learning models may be trained using annotated and/or unannotated training data, as well as supervised or unsupervised training, based on other data files and/or documents.

At Step706, data types and/or protocols for each of the different data portions in the obtained data files are identified. The analysis may therefore identify the data portions using the machine learning model(s) based on corresponding data formats and/or protocols. This may be performed to identify child data assets in each data file, and may be based on a comparison with other data files and/or trained machine learning operations that correlate such data portions and/or protocols within similar data files. Once identified, each of these data portions may be segmented and parceled from the data files based on object similarity in the data chunks or portions for the data files. This allows for data portions to be flattened and separated in data files as child assets.

At Step708, the different data portions are associated with different contents based on the identified data types and/or protocols. The different data portions may therefore be correlated and associated with particular child assets as text, image, video, audio, spreadsheet, or other data formats, protocols, and/or contents. One or more machine learning models and/or operations may be used to correlate and associate data portions with particular contents, such as text, image, video, audio, etc., content, which allows for indexing of the data portions and/or adding or providing identifiers or metadata to the data portions and/or data files. This may provide improved searching of the data files and identifying particular content in data files. At Step710, associations are created with the different data portions and the different contents, and the obtained data files are segmented by the different data portions. The associations may be used to identify and/or label each data portion as particular content within the data files. Further, segmenting of the data files may be performed to segment content into particular data containers and/or child contents or assets, which may be independently searched, identified, and/or retrieved.

Examples

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 a first plurality of messages for a first user, wherein the first plurality of messages comprises: one or more messages in each of a first plurality of formats; and one or more messages sent or received via each of a first plurality of protocols; and create one or more associations between one or more of the first plurality of messages, wherein at least one of the one or more associations is between messages sent or received via two or more different protocols from among the first plurality of protocols, and wherein at least one of the one or more associations is between messages in two or more different formats from among the first plurality of formats.

Example 2 includes the subject matter of example 1, wherein the instructions further comprise instructions to cause the one or more processing units to receive a query requesting at least one message from the first plurality of messages.

Example 3 includes the subject matter of example 2, wherein the instructions further comprise instructions to cause the one or more processing units to generate a result set to the query.

Example 4 includes the subject matter of example 3, wherein the result set comprises the at least one requested message and one or more messages from the first plurality of messages for which associations have been created to the requested message.

Example 5 includes the subject matter of example 1, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform a semantic analysis on the first plurality of messages; and create one or more clusters of messages from the first plurality of messages, wherein a cluster of messages comprises two or more messages that are associated together, and wherein the instructions to create the one or more clusters of messages further comprise instructions to create the one or more clusters of messages based, at least in part, on the semantic analysis performed on the first plurality of messages.

Example 6 includes the subject matter of example 5, wherein the instructions to perform a semantic analysis on a first plurality of messages further comprise instructions to identify one or more keywords in one or more of the first plurality of messages.

Example 7 includes the subject matter of example 5, wherein the instructions to perform a semantic analysis on a first plurality of messages further comprise instructions to perform a predictive semantic analysis on one or more of the first plurality of messages.

Example 8 includes the subject matter of example 1, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform element matching on the first plurality of messages.

Example 9 includes the subject matter of example 8, wherein the instructions to perform element matching on the first plurality of messages further comprise instructions to: perform element matching on at least one of the following: sender, recipient list, subject, quoted text, and timestamp.

Example 10 includes the subject matter of example 1, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform state matching on the first plurality of messages.

Example 11 is a system that comprises: a memory; and one or more processing units, communicatively coupled to the memory, wherein the memory stores instructions to configure the one or more processing units to: obtain a first plurality of messages for a first user, wherein the first plurality of messages comprises: one or more messages in each of a first plurality of formats; and one or more messages sent or received via each of a first plurality of protocols; and create one or more associations between one or more of the first plurality of messages, wherein at least one of the one or more associations is between messages sent or received via two or more different protocols from among the first plurality of protocols, and wherein at least one of the one or more associations is between messages in two or more different formats from among the first plurality of formats.

Example 12 includes the subject matter of example 11, wherein the instructions further comprise instructions to cause the one or more processing units to receive a query requesting at least one message from the first plurality of messages.

Example 13 includes the subject matter of example 12, wherein the instructions further comprise instructions to cause the one or more processing units to generate a result set to the query.

Example 14 includes the subject matter of example 13, wherein the result set comprises the at least one requested message and one or more messages from the first plurality of messages for which associations have been created to the requested message.

Example 15 includes the subject matter of example 11, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform a semantic analysis on the first plurality of messages; and create one or more clusters of messages from the first plurality of messages, wherein a cluster of messages comprises two or more messages that are associated together, and wherein the instructions to create the one or more clusters of messages further comprise instructions to create the one or more clusters of messages based, at least in part, on the semantic analysis performed on the first plurality of messages.

Example 16 includes the subject matter of example 15, wherein the instructions to perform a semantic analysis on a first plurality of messages further comprise instructions to identify one or more keywords in one or more of the first plurality of messages.

Example 17 includes the subject matter of example 15, wherein the instructions to perform a semantic analysis on a first plurality of messages further comprise instructions to perform a predictive semantic analysis on one or more of the first plurality of messages.

Example 18 includes the subject matter of example 11, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform element matching on the first plurality of messages.

Example 19 includes the subject matter of example 18, wherein the instructions to perform element matching on the first plurality of messages further comprise instructions to: perform element matching on at least one of the following: sender, recipient list, subject, quoted text, and timestamp.

Example 20 includes the subject matter of example 11, wherein the instructions to create one or more associations between one or more of the first plurality of messages further comprise instructions to: perform state matching on the first plurality of messages.

Example 21 is computer-implemented method, comprising: obtaining a first plurality of messages for a first user, wherein the first plurality of messages comprises: one or more messages in each of a first plurality of formats; and one or more messages sent or received via each of a first plurality of protocols; and creating one or more associations between one or more of the first plurality of messages, wherein at least one of the one or more associations is between messages sent or received via two or more different protocols from among the first plurality of protocols, and wherein at least one of the one or more associations is between messages in two or more different formats from among the first plurality of formats.

Example 22 includes the subject matter of example 21, further comprising receiving a query requesting at least one message from the first plurality of messages.

Example 23 includes the subject matter of example 22, further comprising generating a result set to the query.

Example 24 includes the subject matter of example 23, wherein the result set comprises the at least one requested message and one or more messages from the first plurality of messages for which associations have been created to the requested message.

Example 25 includes the subject matter of example 21, wherein act of creating one or more associations between one or more of the first plurality of messages further comprises: performing a semantic analysis on the first plurality of messages; and creating one or more clusters of messages from the first plurality of messages, wherein a cluster of messages comprises two or more messages that are associated together, and wherein the act of creating the one or more clusters of messages further comprises creating the one or more clusters of messages based, at least in part, on the semantic analysis performed on the first plurality of messages.

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.”