FIELD OF THE INVENTIONEmbodiments of the invention described herein relate generally to communications systems, and, more specifically, to techniques for phrase-based user interfaces.
BACKGROUNDThe approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
The proliferation of communications tools and resources, such as instant messaging clients, text messages, email, and social networking sites, has created a demand to exchange messages about any imaginable subject at any possible time from any possible device. Unfortunately, this demand is stifled by the limitations of the available input mechanisms and interfaces. For example, while many users are very adept at generating messages via input at computer keyboards, mobile phone number pads, and touch screens, these input mechanisms may be unavailable or even undesirable for devices such as entertainment consoles, media centers, and gaming consoles.
One technique for providing messaging interfaces in devices that lack a keyboard is to present an on-screen interface in which each key of the keyboard is depicted as an on-screen control. The controls of the on-screen interface may be selectable, for instance, via a user input at a remote control or gaming pad, such as a combination of arrow button inputs and an “enter” button input. Another technique for providing messaging interfaces relies upon the utilization of number buttons on a remote control in a “T9 mode,” similar to the manner in which one uses a number pad on a mobile phone to generate text messages. Both techniques may be further enhanced by presenting the user with a short menu of “predictive text” as the user inputs words, so that the user need only input a few characters of most word.
Yet another technique involves presenting to the user, along with an on-screen keyboard interface, a menu comprising a limited number of “canned messages.” The text of these messages may be pre-defined by the manufacturer, or customized by the user. Thus, if the user expects to send a message such as “be right back” very often, the user may define a corresponding “be right back” canned message. The interface may then feature a canned message menu from which “be right back” and other defined phrases can be selected and inserted into any message.
Unfortunately, users often find the above described techniques to be cumbersome or limiting. In fact, in situations where users may only be willing to devote a limited amount of attention to generating a message, such as while gaming or watching video content, users may even find keyboards to be unduly cumbersome. Accordingly, users often do not take advantage of messaging services that are or could be provided.
BRIEF DESCRIPTION OF THE DRAWINGSThe present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of asystem100 in which the techniques described herein may be practiced;
FIG. 2 is a flow diagram200 illustrating an example process for generating a message via a messaging interface;
FIG. 3A is a sample view of anexample messaging interface300;
FIG. 3B is another sample view ofexample messaging interface300;
FIG. 3C is another sample view of anexample messaging interface300;
FIG. 4 is an examplemessage generation interface400 with an integrated programming guide; and
FIG. 5 is block diagram of a computer system upon which embodiments of the invention may be implemented.
DETAILED DESCRIPTIONIn the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
Embodiments are described herein according to the following outline:
1.0. General Overview
2.0. Structural Overview
3.0. Functional Overview
4.0. Example Interfaces
- 4.1. Example Interface with Word-Based and Icon-Based Elements
- 4.2. Scrolling Interface Controls/Switching Input Modes
- 4.3. Example Technique for Selection of Controls
- 4.4. Example Message Display Field
- 4.5. Example Interface with Phrase-Based Elements
- 4.6. Example Interface with Metadata-Based Elements
- 4.7. Example Interface with Integrated Programming Guide
5.0. Example Implementation Details
- 5.1. Context Awareness
- 5.2. Harvesting Phrase Data from Messages
- 5.3. Selecting Phrases for Inclusion as Phrase-Based elements
- 5.4. Context-Sensitive Metadata
- 5.5. Dynamic Interface Layout based on Predicted Next Elements
- 5.6. User of Selection of an Activity from Within the Message Generation Interface
- 5.7. Implementation in Non-Centralized Environments
6.0. Implementation Mechanism—Hardware Overview
7.0. Extensions and Alternatives
1.0. General OverviewApproaches, techniques, and mechanisms are disclosed for a phrase-based communication system in which users are presented with a dynamic messaging interface of selectable phrases. According to an embodiment, the phrases are selected using algorithms that identify phrases that are likely to be useful to the particular user and/or the context in which the user is creating a message. In this manner, a user is able to generate useful messages quickly, without being limited to stale and fixed canned messages.
In an embodiment, phrases for a messaging interface are learned from messages previously sent by other users. For example, a central server system may be responsible for relaying messages generated in accordance with the described technique. The central server system may analyze messages as they are sent to detect commonly used phrases. The central server system may then feed these commonly used phrases to the messaging interface. The messaging interface may then present the commonly used phrases in a list of selectable phrases, so as to allow the user of the interface to insert any of the commonly used phrases in a message simply by selecting the desired phrases. Commonly used phrases may be selected for all users of the central server system, or relative to individual communities of users. Commonly used phrases may further be selected relative to contexts, such as the time of year or an activity in which the user of the messaging interface is participating.
In an embodiment, phrases for a messaging interface are selected from metadata associated with the user's current context, as indicated by an activity in which the user is engaged while the user is generating the message. For example, the activity may be watching or accessing information about viewable and/or audible content, and the metadata may be information about that content. The messaging interface may, for instance, be launched while the user is watching a particular video via the device. Or, while utilizing the messaging interface to generate a message, the user may navigate a media guide and select a listing of information for a particular program therein. In both examples, the messaging interface may be populated with metadata for the particular video or program. The metadata may include, for example, a title, episode name, actor or actress name, broadcast date, and so on. The metadata itself may have been collected from a variety of sources, including without limitation a content provider, service provider, event organizer, distributor, reviewer, and/or other users. In an embodiment, metadata may be filtered or sorted based at least partially upon which metadata is most commonly used in messages sent by the user and/or a group of other users.
In an embodiment, the system may also or instead select elements for inclusion in a messaging interface for purposes such as advertising or market testing. In an embodiment, the messaging interface allows a user to select and insert elements other than phrases, including images, music, video, links, animations, calendar items, and so on. Some or all of these elements may be selected using the techniques described above. Thus, when this description discusses steps and processes with respect to “phrases,” it should be understood that the steps and processes are also applicable to a variety of other elements, with little or no modification.
In an embodiment, the messaging interface is implemented by a digital video recorder connected to a central server. While watching a video or television program, or while navigating a program guide listing information about a video or television program, the user may request that the digital video recorder provide the messaging interface. For example, the user may click on a button on a remote control that allows the user to create an email, text message, instant message, or social networking service status message. In response to this request, the digital video recorder communicates with a central server to obtain one or more lists of commonly-used phrases and metadata, based on the video or television program. The digital video recorder displays the messaging interface on a display connected to the digital video recorder. The digital video recorder builds the interface using controls such as ASCII characters, icons, canned messages, and a friends list. The digital video recorder further includes in the interface controls corresponding to the metadata and commonly-used phrases selected by the central server. The user navigates the interface to select elements to insert into the message, as well as to select one or more intended recipients. When the user has finished building the message, the digital video recorder sends the message to the central server for distribution. The central server delivers the message to its one or more intended destinations. The central server also analyses the message for the purpose of harvesting phrase data and metadata for future messaging interfaces.
In other aspects, the invention encompasses a computer apparatus and a computer-readable medium configured to carry out the foregoing steps.
2.0. Structural OverviewFIG. 1 is a block diagram of asystem100 in which the techniques described herein may be practiced.
System100 comprises aclient device110 connected via anetwork120 to acentral server system130.User105 operatesclient device110 via aninput mechanism112 to, among other purposes, generate and send messages torecipients160.Input mechanism112 is, for example, a remote control, gaming pad, touch pad, touch screen, keyboard, pointing device, mobile phone, or any other suitable input device capable of sending input toclient device110.
To facilitate the composing of messages,client device110 implements a graphical user interface (“GUI”)114 foruser105.Client device110 displays GUI114 on anoutput mechanism116.Output mechanism116 is, for example, a television, monitor, touchpad, tablet computing device, remote control with touchscreen display, Bluetooth-enabled personal digital assistant, wireless-enabled smartphone, smartphone, or any other device capable of responding to instructions from aclient device110 by displaying GUI114 touser105.Output mechanism116 receives instructions from GUI114 viacommunication link117, which may be wired or wireless, and which may furthermore be a direct link or involve one or more networked switches or routers. In an embodiment,output mechanism116 andclient device110 may be contained in a common device, e.g., a tablet computing device, smartphone, etc.
Central server system130 may comprise one ormore server devices132 responsible for communicating withclient device110 overnetwork120.Central server system130 may be any system capable of relaying messages from one party to another.Network120 may be implemented via any suitable combination of communication links, including the Internet, telephone lines, and/or wireless connections. In an embodiment,central server system130 may also be operated by a provider ofmetadata190—for example, a provider of an electronic programming guide, such as TiVo Inc. However, in other embodiments,central server system130 does not providemetadata190, asclient device110 may obtain such information from sources other thancentral server system130.
In an embodiment,user105 utilizesclient device110 while participating in an activity. Example activities include, but are not limited to, viewing, listening to, or accessing information about content such as television episodes, movies, songs, online videos, websites, concerts, and so on. Example activities further include, without limitation, playing video games and participating or accessing information about other real-time events. Watching a live television broadcast, listening to a downloaded song, blogging, vlogging, and attending a social event are all activities in which a user may participate, within the meaning of this description.
In an embodiment,user105 utilizesclient device110 to participate in this activity. For example,client device110 may be a television, media center, set-top box, gaming device, hand-held device, tablet computing device, digital video recorder, etc., used to consume multimedia content.User105 may trigger GUI114 at any time while consuming multimedia content. Or, as another example,user105 may trigger GUI114 while usingclient device110 while browsing multimedia information in a programming guide.Client device110 may present such multimedia content or information atoutput device116 or at one or more other output devices. In an embodiment, the multimedia content or information persists either visibly or invisibly in the background whileclient device110 presents GUI114, so that onceuser105 finishes with GUI114,user105 is returned to the multimedia content or information.
To facilitate participation in an activity,client device110 may interact with one ormore content providers140 and/orcentral server system130. For example,content providers140 may include broadcast television stations, cable providers, satellite video or music providers, Internet content providers, and so on.Content providers140 may transmit a variety ofcontent180 andmetadata190 aboutcontent180 toclient device110 through any of a variety of transmission means. As another example,central server system130 may provide client device withmetadata190 aboutcontent180 via, for instance, an Electronic Programming Guide. In an embodiment,central server system130 andcontent providers140 are the same entity.
Via GUI114,client device110 presents touser105 one or more sets of selectable interface controls118. Each of interface controls118 represents one or more elements that may be inserted into amessage160 to be generated byclient device110. Elements may include, without limitation, characters, phrases, images, or multimedia objects. By selecting a particular control,user105 may insert the element represented by the particular control intomessage160. Some ofcontrols118 may be used to implement an on-screen keyboard interface, as described previously. That is to say, some ofcontrols118 represent ASCII characters that would be found on a typical computer keyboard.User105 may swapindividual controls118 and sets ofcontrols118 in and out of GUI114 by selecting certain buttons at input mechanism112 (e.g. a scroll button) or selecting certain designated controls in GUI114. Thus, at any given time, only a portion of thecontrols118 available via GUI114 may be displayed touser105.
The elements represented by at least some ofcontrols118 are selected dynamically bycentral server system130. For example,central server system130 may employ a variety of algorithms, based on a variety of data, to identify elements that are most likely to be useful to the user in generatingmessage160. In this manner,system100 allowsuser105 to generate useful messages quickly, without being limited to stale and fixed canned messages.Central server system130 may also or instead select elements for purposes such as advertising or market testing.
Central server system130 includes one ormore data repositories134.Data repositories134 may be any source of data, including files, databases, and so on. In an embodiment, adata repository134 includes data indicating phrases harvested from messages170 sent by users in a group ofusers106 also connected tocentral server system130.Data repository134 may further include data indicating usage trends for these phrases. Based at least on this data,central server system130 identifies certain phrase-based elements175 for which GUI114 should present controls118.User105 may then usecontrols118 to insert some or all of phrase-based elements175 intomessage160.
In an embodiment,data repository134 includesmetadata190 that can be associated with activities. Example metadata is described in section 5.4.Central server system130 utilizes this metadata to identify context-sensitive metadata elements to add to GUI114. To this end,central server system130 receives context data fromclient device110 or any other suitable source. The context data indicates at least some aspect of an activity or activities in whichuser105 is currently participating.Central server system130 may then retrievemetadata190 associated with the appropriate context. For example, where the activity involves watching an event or content,client device110 may share an event or content identifier with the central server system. Based on the event or content identifier, thecentral server system130 may retrieve metadata for the event or content.Central server system130 then identifies some or all of the retrieved metadata as metadata-basedelements190 for which GUI114 should present controls118.User105 may then usecontrols118 to insert certain of metadata-basedelements190 intomessage160.
Once generated,message160 may be relayed to one or moreother users106, as designated byuser105, via a variety of means. For example, as depicted,client device110forwards message160 tocentral server system130, which then forwardsmessage160 to the designated one or moreother users106. In an embodiment,central server system130 may further minemessage160 for additional information to include indata repository134, including updated popularity data or contextual data for phrases selected byuser105, as well as new phrases165 to be utilized as elements in subsequent message generation interfaces byuser105 and/orother users106.
FIG. 1 is merely an example of a system in which the techniques described herein may be practiced. Other systems in which the techniques described herein may be practiced may include more or fewer components in different arrangements. Example alternative arrangements are discussed throughout this description. Also, the division of work between components may vary from embodiment to embodiment. For example, some or all of the functions described as being performed bycentral server system130 andcontent providers140 may instead be performed byclient device110 based on a local version ofdata repository134. For simplicity, many examples given throughout this description will be described in terms of a messaging interface, such as GUI114, that is provided by aclient device100 functioning, at least in part, as an entertainment device through which a user accesses information provided by acentral server system130 about video content fromcontent providers140. However, any techniques described in such terms are equally applicable to any messaging interface provided by any client device.
3.0. Functional OverviewFIG. 2 is a flow diagram200 illustrating an example process for generating a message via a messaging interface.
Atblock210, a client device, such asclient device110, receives input indicating a request by a user to generate a message. The input may be received, for example, via a button at an input mechanism, such asinput mechanism112. Or, as another example, the input may be received via the user navigating an on-screen interface and selecting an interface control associated with generating a message. Such a button or control may be labeled, for instance, with an envelope icon, Instant Messaging icon, text such as “TXT,” “IM,” “Twitter,” “Facebook,” “Email,” and so on.
Atblock220, the client device receives data listing commonly-used phrases from a server, such ascentral server system130. The list of commonly used phrases may have been generated based at lest partially using messages previously sent through the server by other users. Example techniques for generating lists of commonly used phrases are discussed in section 5.3 below, as well as in other sections of this description. In an embodiment, the list is retrieved in response to the input ofblock210.
In an embodiment, the client device retrieves the list in response to only certain requests by a user to generate a message. For example, the client device may retrieve a new list every tenth time the user requests to generate the message, or only if a certain amount of time has elapsed since the user last generated a message. In an embodiment, the client device periodically retrieves or receives a new list, for instance, every hour or every day. When the client device does not retrieve a new list in response to the input ofblock210, the client device re-uses lists that have been previously retrieved. However, the client may still re-order or filter a re-used list based upon context data and usage trends known to the client device.
In an embodiment, the client device adds each received list to a local data repository of commonly-used phrases. The client device may further receive as part of this step updated usage history data, based upon which the client may select, filter, and order phrases from the local repository.
Atblock230, the client device receives context-sensitive metadata associated with one or more activities from a server, such as a server belonging tocentral server system130,content provider140, an event organizer, a content producer, and/or a content distributor. The one or more activities are one or more activities in which the user is currently engaged or about which the user is currently accessing information during or just immediately prior to use of the message generation interface. The metadata received by the client device may include, for instance, metadata such as described in section 5.4 below, as well as throughout this application.
In an embodiment, the metadata is received in response to the input ofblock210. The client device sends context information to the server indicating one or more aspects (such as event or content identifiers) of one or more activities. The activities may be known to the client device via a variety of means, such as discussed in section 5.1 below, and in other sections of this description. In an embodiment, the client device may be entirely unaware of any activities in which the user is participating. Instead, the server may be aware of or capable of learning an appropriate context, based on techniques such as described herein. In such embodiments, the client device simply requests that the server provide metadata for the one or more activities already known to the server.
In an embodiment, the client device receives metadata that may be associated with one or more activities prior to the input ofblock210, such as in an electronic programming guide. The client device then stores the metadata locally in one or more repositories of metadata. The client device may then retrieve metadata for any appropriate context from local storage in response to the input ofblock210. The client device may further receive popularity data to associate with some or all of the metadata, to assist in ordering the metadata by likelihood of use.
Atblock240, the client device renders a message generation interface, such as GUI114, on a display device, such asoutput device116. The message generation interface comprises a plurality of user selectable controls, such ascontrols118, each corresponding to a different element, or “building block,” that may be inserted in the message. At least some of the controls correspond to the commonly used phrases and/or metadata received inblocks230 and240. Other controls may correspond to standard ASCII characters and pre-set elements selected by a user or manufacturer, including canned messages and icons. The controls may be of any shape, size, and/or arrangement, and may further include textual or graphical labels indicative of the elements to which they correspond. Some example controls and interfaces are described in section 4.0 below.
Atblock250, the client device receives input from the user indicating selection of a control that corresponds to an element that may be added to the message. In response to the input, the client device adds the element corresponding to the selected control to the message being generated. The user may select controls using a variety of means, depending upon which input mechanism the user has available. For example, certain input mechanisms may allow a user to select a control using common “point-and-click” or touch-screen techniques. As another example, when the input mechanism is a traditional remote control, the client device may highlight a certain control to indicate that it is in focus. The user may utilize buttons at the remote control, such as arrow or number buttons, to navigate the interface by changing which control is in focus. Once a desired control is in focus, the user may press a predefined button on the remote control, such as an “enter” or “okay” button, to send input to the client device indicating selection of the desired control.
Atblock260, the client device receives input from the user indicating the selection of one or more recipients of the message. Such input may comprise, for instance, selection of one or more controls in the messaging interface corresponding to recipient addresses. For instance, the client device may include in the messaging interface controls corresponding to the addresses of recipients to whom the user commonly sends messages, the addresses of users in a “friend” list for the user, and/or the addresses of users in a social network to which the user belongs. The client device may have previously collected these addresses from the user and/or downloaded these addresses from a server, such ascentral server system130 or a server for a social network to which the user belongs.
The input ofblock260 may also or instead comprise selection of a “To” control using means such as described above, followed by selection of controls corresponding to the alphanumeric characters of a recipient's address. The interface may include a “wizard” that streamlines the process of composing a recipient's address by, in response to selection of the “to” control, presenting the user with a list of different messaging services, such as Twitter, Facebook, Gmail, and so on. The user may thus compose a recipient's address by entering a user name and selecting an appropriate service.
In an embodiment, the message generation interface includes a field or fields in which the client device displays one or both of the message(s) thus far generated and the intended recipients. Thus, asblocks250 and260 are performed, the client device may update the field to include selected elements and recipients. However, the messaging interface need not necessarily display such fields.
Blocks250 and260 may be repeated one or more times, thus allowing the user to compose a message comprising a plurality of elements. Repetition ofblocks250 and260 may occur at any time up until the occurrence ofblock270. Atblock270, the client device receives a terminal input indicating that the user is done with the message. This input further requests that the client device send the message to the identified recipients. This input may take many forms, including, for instance, selection of an “OK” control in the message generation interface or selection of a “Send” button at the input mechanism.
Atblock280, the client device causes the generated message to be sent to the designated recipients. The client device may perform this step in a number of ways, including relaying the message and list of recipients to the server ofblock220, as well as sending the message to each of the intended recipients directly.
Atblock290, the server ofblock220 mines the sent message for phrases, so as to find new phrases to add to its repository of phrases, as well as to adjust popularity scores for phrases and metadata already in its repository(ies). In embodiments where the sent message was not relayed through the server, the client device may report the sent message to the server.
Flow200 illustrates but one example embodiment of the techniques described herein. Other embodiments may include more or fewer steps, in different orders. For example, the client device may omit block220 or block230 to provide an interface that includes only commonly used phrases, or only metadata associated with activities. As another example, blocks220 and/or230 may be performed before the input ofblock210 as well as after the input ofsteps250 or260. As another example, block260 may be performed at any time relative to blocks220-250.
4.0. Example Interfaces4.1. Example Interface with Word-Based and Icon-Based Elements
FIG. 3A is a sample view of anexample messaging interface300, according to an embodiment.Messaging interface300 illustrates but one of many possible techniques by which aclient device110 may implement a GUI114 for generatingmessage160. Other messaging interfaces may include more or fewer controls and fields, organized in any variety of arrangements.
Messaging interface300 comprises a plurality of selectable controls311-314,318-319,321-324,328-329,331-334,338-339,341-344,348-349,379,381,382, and391-394. A user may select these controls using any of a variety of selection techniques, including, without limitation, touch screen input, point-and-click input, input from buttons that have been mapped to designated controls, and so on. One such technique is described in section 4.3, below.
Messaging interface300 further comprises abuilding block form301 for generating a message.Building block form301 comprises controls311-314,321-324, and331-334, each of which represents a different element that may be added to a message. Each of the controls inbuilding block form301 are displayed with a visual indication—e.g. text or an image—of its corresponding element. For example,control313 is labeled with the text “Tonight,” thereby indicating thatcontrol313 represents the word “Tonight.” As another example,control331 is labeled with a graphic that resembles a heart. Accordingly,control331 may represent, for instance, a heart icon, a romantic emoticon, or even a word such as “loves.”
Controls311-314,321-324, and331-334 are organized into threedifferent control groups310,320, and330. Each control group represents a different type of element that may be inserted into a message.Control group310 includes controls representative of “noun” elements.Control group320 includes controls representative of “verb” elements.Control group330 includes controls representative of “icon” elements.
In an embodiment, controls311-314,321-324, and331-334 represent elements stored locally in one or more data sources atclient device110. Each element is stored with data indicating the element's type. Controls311-314,321-324, and331-334 may represent pre-defined elements and/or user-defined elements. In an embodiment, some or all of controls311-314,321-324, and331-334 are instead selected from repositories of phrases and/or metadata that have been harvested using techniques as described herein.
When a user selects a particular one of controls311-314,321-324, and331-334, the user indicates his or her selection of the element corresponding to the particular control. Based on this selection, the corresponding element may be added to the message being generated.
Messaging interface300 further comprises amessage display field370 for indicating to the user the contents of a message as it is being generated. As the user selects controls311-314,321-324, and331-334, the corresponding represented elements are added to themessage display field370.Message display field370 is further described in section 4.4 below.
Messaging interface300 further comprises arecipient block form340 and arecipient display field380.Recipient block form340 comprises controls341-344, each of which represents a different potential recipient or group of recipients. The potential recipients or groups of recipients represented may be selected from a contact database. This contact database may be stored local toclient device110 or at any other suitable location. The contact database may have been compiled using any of a variety of means, such as direct user input, recipient harvesting from previous messages sent by the user, and/or importation from an email service or social network. The user may, at any time, select one or more of controls341-344. In response, the recipient(s) represented by the selected control(s) are added to a list of intended recipients. This list of intended recipients is displayed to the user viarecipient display field380.
In an embodiment, the user may selectrecipient display field380. In response to this selection, the user may be presented with a mechanism for deleting recipients and/or manually entering the address of a recipient.
When the user has completed the message, the user may select sendcontrol382 to indicate that the message is complete. Upon receiving input indicating selection ofsend control382,client device110 may take any suitable action to cause the generated message to be sent to the selected recipients. Alternatively, should the user decide not to send the generated message, the user may select cancelcontrol381.
4.2. Scrolling Interface Controls/Switching Input ModesIn an embodiment, at any given time, only a portion of the controls available to a rendered interface will be visible on the display device. For example,interface300, as depicted inFIG. 3A, displays to the user only a limited number of building block controls311-314,321-324, and331-334 and recipient block controls341-344. However, many more elements or recipients are available for selection. For simplification of the interface, at any given time,interface300 may display controls for only a portion of the available message elements and recipients. Controls for the remaining elements and recipients are not displayed.
Interface300 is therefore configured to dynamically swap in hidden controls. For example, scrolling controls318-319,328-329,338-339, and348-349 may be used to swap in new controls forcontrol group310,control group320,control group330, andrecipient block form340, respectively. The controls may be swapped in according to any suitable order, including orders based on frequency of use, randomness, and predicted usefulness. The controls displayed initially ininterface300 may also be selected based on these and other factors, or the initial controls may correspond to the controls last displayed during the immediately previous instantiation ofinterface300.
Moreover,interface300 comprises amode switching form390, which in turn comprises controls391-394. Controls391-394 each represent a different input mode forinterface300. For each input mode,interface300 presents different types, arrangements, and/or numbers of controls. For example,control391 represents an alphanumerical input mode, in which interface300 presents keyboard-like controls for selection and insertion into the generated message. The control representing the current input mode may be highlighted. Thus, as depicted inFIG. 3A,interface300 is operating in a “words” mode, which mode is represented bycontrol392.
For convenience, any control that could, through user interaction withinterface300, be rendered ininterface300, is herein said to be part ofinterface300 or included ininterface300, even though the control is not necessarily ever displayed to the user. Suitable user interaction for causing a control to be rendered may include any suitable user input, including selection of scrolling, mode-switching, or like controls, as explained above.
4.3. Example Technique for Selection of ControlsAccording to an embodiment, a user may select some or all of the controls ininterface300 via navigational input that brings a control into focus, followed by input that indicates selection of the control currently in focus. At any given time, one of the plurality of selectable controls is highlighted, or “in focus.” As depicted inFIG. 3A, for example,control313 is in focus. In an embodiment, a control that is in focus may be displayed in a different manner than other controls, thereby indicating to the user that the control is in focus. For example,control313 is displayed with both bolded text and a bolded border. However, in other embodiments, a control may be indicated as being in focus using any suitable visual effect, such as a color change, shape change, and/or glowing effect.
While a particular control is in focus, the user may indicate selection of the highlighted control by submitting a designated input. For example, the user may press an “Enter,” “OK,” or like button. In response to this input, the element represented by the highlighted control is added to the message.
4.4. Example Message Display FieldAs depicted inFIG. 3A,message display field370 is subdivided into blocks371-375, each of which corresponds to an element that has been added or may be added to the message. However,message display field370 need not be subdivided. In an embodiment, the number of blocks inmessage display field370 is pre-fixed. In an embodiment, a new block is added tomessage display field370 any time the user selects an element to add to the message. In an embodiment, blocks may be added tomessage display field370 dynamically, via selection ofcontrol379. In an embodiment, the block into which the next selected element is to be inserted is displayed as being “in focus.” For example, block374 is highlighted to indicate that it is in focus. In an embodiment, the user may change which block is in focus by selecting a different block using any suitable control-selection technique. In this manner, blocks with currently assigned elements may be overwritten.
If the message grows too large formessage display field370, certain elements may be hidden fromfield370. In an embodiment,interface300 may further include controls that allow the user to bring hidden elements into view. In an embodiment, hidden elements are brought into view automatically, either in response to navigational input submitted by the user whilemessage display field370 is in focus, or in response to the passage of a certain amount of time, so as to yield a ticker effect.
4.5. Example Interface with Phrase-Based Elements
FIG. 3B is another sample view ofexample messaging interface300, according to an embodiment.FIG. 3B is, for the most part, similar toFIG. 3A, except thatinterface300 is depicted as operating in a “phrases” input mode, as indicated by highlightedinput mode control393.
As depicted inFIG. 3B,building block form301 ofinterface300 comprises acontrol group350 corresponding to a “phrase” element type.Control group350 comprises controls351-357, each of which represents a different phrase element that may be inserted into the message being generated.Control353 is currently in focus. Controls351-357 may represent any of the following combinations of elements: 1) pre-defined canned phrases; 2) user-defined canned phrases; 3) phrases derived from context-sensitive metadata; and 4) phrases learned from previous messages. Each of these elements may be retrieved from a local data repository or from a centralized server system.
Controls351-355 and357 are labeled with the entire texts of their respective represented phrases. However, for lengthy phrases, such as represented bycontrol356, a control may only be labeled with a portion of the text for a phrase. In an embodiment, the text label ofcontrol356 automatically scrolls over time to allow the user to read the full phrase. The automatic scrolling may occur constantly, or only whencontrol356 is in focus.
Control group350 further comprises afiltering form305, which in turn comprises filtering controls306-309.Filtering form305 allows a user to select different categories of phrases to include inbuilding block form301. When filteringcontrol306 is selected, for instance,building block form301 may include controls that represent phrases harvested from messages sent by or to the user. When filteringcontrol307 is selected,building block form301 may include controls that represent phrases harvested from messages sent by or to users that have been identified as “friends” of the user. When filteringcontrol308 is selected,building block form301 may include controls that represent phrases harvested from messages sent by or to users that have been identified as “fans” of an activity in which the user is currently engaged or content that the user is currently viewing. When filteringcontrol309 is selected,building block form301 may include controls that represent phrases harvested from messages sent by or to all users of a central server system through which the user relays messages.
In an embodiment, some or all of the above filtering conditions may further involve constraining or prioritizing phrases to the context of a certain activity in which the user is presently engaged. For example, the user may be watching a certain television show. While also watching the television show, other users may have sent messages that included famous quotes from the television show. These quotes may be automatically harvested from those messages and then utilized as elements ininterface300. The quotes may be given preference or even exclusively selected over other phrases harvested from phrases used outside of the context of the activity. Note that constraint or prioritization based on such a context may be implicit, or may be selected via one or more additional controls.
In some embodiments,filtering form305 comprises more or fewer filtering controls, while in other embodiments,interface300 may lackfiltering form305 altogether.
Control group350 further comprises controls358-359 for scrolling to hidden controls, like the scrolling controls discussed in section 4.2 above.
Additional differences betweenFIG. 3A andFIG. 3B include: block374 is no longer highlighted, but includes the text “must see . . . ”; and block375 is highlighted. These changes may have resulted, for example, from the user's selection ofcontrol353 whileblock374 was highlighted. In response to this selection,client device110 may have added the phrase element “Must See Must See Must See!” to the message in the position ofblock374. Note that the text displayed inblock374 has been abbreviated due to size constraints. In an embodiment, this text may periodically scroll so as to reveal the entire text of the element. Further in response to the selection ofcontrol353 whileblock374 was highlighted, the client device may have automatically shifted the focus ofmessage display field390 to the next empty block, in this case block375.
4.6. Example Interface with Metadata-Based Elements
FIG. 3C is another sample view of anexample messaging interface300, according to an embodiment.FIG. 3C is, for the most part, similar toFIG. 3A. However,interface300 is depicted as operating in a “metadata” input mode, as indicated by highlightedinput mode control394.
As depicted inFIG. 3C,building block form301 ofinterface300 comprises acontrol group360 corresponding to a “metadata” element type.Control group360 comprises selectable controls361-367, each of which represents a different metadata element that may be inserted into the message being generated.Control363 is currently in focus.
Controls361-367 may represent any metadata elements associated with an activity in which the user is currently engaged. The metadata may pertain to any aspect of the activity. For example, the activity ofFIG. 3C involves an episode of a television show. Other example metadata elements are described in section 5.4.
In an embodiment, some or all of the metadata elements are selected from a local data repository containing information provided by a content or metadata provider. For example,client device110 may select the metadata elements from an electronic programming guide populated with data provided by content provider(s) and/or a central server system, such assystem130. In an embodiment,client device110 automatically requests some or all of the metadata elements associated with an activity from a content or metadata provider, in response to theuser launching interface300 while participating in the activity.
As withFIGS. 3A and 3B,interface300 displays controls for only a small number of the available metadata elements.Controls368 and369 may be used to scroll in controls for other metadata elements.
In an embodiment,interface300 may enhance controls that represent non-textual elements, such ascontrols366 and367, using a number of techniques. For example, when the user brings a control that represents an image into focus, such ascontrol366,interface300 may temporarily enlarge the image. Or, wherecontrol366 is labeled with a cropped version of an image,interface300 may display the full image in an enlarged format as the user bringscontrol366 into focus. As another example, when the user brings a control representing an audio or video element into focus, such ascontrol367,interface300 may play the audio or video element. For example,control367 may represent a video preview or recap of a television episode, which interface300 may play when the user highlightscontrol367.
An additional difference betweenFIG. 3B andFIG. 3C is the inclusion of new controls345-347 in place of controls341-343 in recipients block340.Control345 represents an element corresponding to a user-defined group of recipients labeled “Family.”Control346 represents an element corresponding to a group of recipients labeled “Twitter.” For example, selection of this control may indicate that the user wishes to send the generated message to his or her Twitter account, from which it may be accessed by a subscribed group of recipients.Control347 represents an element corresponding to a group of recipients labeled “Fans.” For example, selection of this control may indicate that the user wishes to send the generated message to other users who have indicated that they are a fan of the television show that the retrieved metadata elements describe.
4.7. Example Interface with Integrated Programming Guide
FIG. 4 is an examplemessage generation interface400 with an integrated programming guide, according to an embodiment.Messaging interface400 illustrates but one of many possible techniques by which aclient device110 may implement a GUI114 for generatingmessage160. Other messaging interfaces may include more or fewer controls and fields, organized in any variety of arrangements.
Messaging interface400 comprises aninformation panel460 to assist a user in composing a message.Information panel460 displays information about an event—in this case, an episode of a television series. The user may quickly locate this information and add it to the generated message. In an embodiment,information panel460 appears persistently ininterface400. In an embodiment,information panel460 is by default hidden frominterface400 to make room for other controls, such as described throughout this disclosure. However, in such an embodiment,information panel460 may be brought up at any time via selection of, for instance, an interface control ininterface400 or a “Guide” button oninput mechanism112.
Information panel460 comprises a number of controls and fields461-469.Control461 represents a metadata element corresponding to the name of the television series.Control462 represents a metadata element corresponding to the title of the episode.Controls463aand463brepresent metadata elements corresponding to cast members of the television series.Control464 represents a metadata element corresponding to the air date and time of the episode.Control465 represents a metadata element corresponding to the channel number on which the episode will air.Control466 represents a metadata element corresponding to the name of the broadcast network on which the episode will air. In response to a user selecting any one ofcontrols461,462,463a,463b,464,465, and466 by the user,interface400 adds the respective represented element to the generated message.
Field467 includes a description of the episode. Various elements of the description are underlined, thereby indicating that the underlined portions are themselves selectable controls. For instance, the user may select any of the following elements from the description to the message: “Jim,” “Pam,” “Michael,” “kayaking lessons,” “Dwight,” “revolt,” “Scranton Branch,” or “foiled.”Client device110 may have decided to render these elements offield467 as selectable for a variety of reasons. For example, the metadata itself may have included markups indicating that above-listed elements in the description should be emphasized. As another example,client device110 orcentral server system130 may include one or more global or context-sensitive databases of terms that should be emphasized in textual descriptions. Such a database may be static, or may change over time based on an analysis of messages sent by users. As yet another example,client device110 may include logic for analyzing textual descriptions grammatically, semantically, and/or syntactically to identify significant markers. In some embodiments,field467 is itself a selectable control. In such embodiments, in response to selection offield467, the entire description may be inserted into the message.
Controls463cand467apermit a user to scroll to addition cast members and textual descriptions, respectively.Controls469 permit a user to navigate to a different television show in an adjacent time slot on the same channel.Controls468 permit a user to navigate to a different television show in the same time slot but on another channel.Information panel460 may include more or fewer controls for navigating to other events. Moreover, the types of information and controls depicted inFIG. 4 are merely illustrative of the many types of information and the many types of selectable controls that may be included ininformation panel460. In an embodiment, for example,information panel460 may include controls representing phrases commonly used by other users while watching the indicated program.
Interface400 comprises analphanumerical control form410, in which the user may select alphanumerical characters to insert into the message. In an embodiment, each alphanumerical character is considered a separate element of the message. In an embodiment, consecutively selected alphanumerical characters are grouped together as a single element, which element may be harvested from the message and subsequently utilized as the basis of a phrase-based control.
Interface400 further comprises amode switching form490, similar tomode switching form390 ofFIGS. 3A-3C. Mode switching form comprises controls491-494, each of which represents a different input mode forinterface400. For each input mode,interface400 presents different types, arrangements, and/or numbers of controls. For example, highlightedcontrol491 represents an alphanumerical input mode, in which interface400 presents the keyboard-likealphanumerical control form410. In other modes corresponding to other controls492-494,alphanumerical control form410 is replaced by forms for inserting icons into the message, inserting slang phrases harvested from other users, and selecting recipients, respectively. Additional modes are also possible.
Interface400 further comprises: arecipient display field480, similar torecipient display field380; asend control482, similar to sendcontrol382; a cancelcontrol481, similar to cancelcontrol381; and amessage display field470, similar tomessage display field370 ofFIGS. 3A-3C.Message display field470, in turn, comprises blocks471-476, which correspond to elements selected by the user to insert into the message.
5.0. Example Implementation Details5.1. Context AwarenessIn an embodiment, one or both ofclient device110 andcentral server system130 employs any of a variety of techniques to identify a context in which the messaging interface114 is being used. Based on this context, the interface may be customized to include controls for context-based metadata elements. Additionally, or in the alternative, controls may be ranked based on the context, so that the phrases most likely to be useful within the context appear with minimal (or without any) scrolling.
In an embodiment, the context is identified by determining one or more activities in which the user is participating at the time the user requested access to the interface. Once these activities have been determined, any of a variety of aspects of the activities may yield metadata for interface controls, as previously discussed. Additionally, or in the alternative, data describing any of a variety of aspects of the activities may be compared to historical usage data collected for commonly used phrases to determine which of the phrases are most relevant to the current context.
In an embodiment, context awareness atcentral server system130 is facilitated by context awareness atclient device110.Client device110 is aware of at least some aspects of an activity in which the user is participating simply becauseclient device110 is instrumental in that activity. For example, in the case that client device is a media or entertainment device, the activity may involve watching or accessing information about certain content throughclient device110 itself.Client device110 may relay information identifying that content tocentral server system130.Central server system130 may then use the content-identifying information to lookup suitable metadata and/or rank phrases for return toclient device110.
By the same token, whenclient device110 is already aware of content-identifying information,client device110 may itself utilize that information to lookup suitable metadata and/or rank phrases in a local data repository.Client device110 may have populated this local data repository from metadata and/or phrases received periodically fromcontent providers140 orcentral server system130. Furthermore, each entry of metadata and/or phrases in the local data repository may have been stored in association with context data, such as content identifiers or activity identifiers. In the case of phrases, for instance, the context data may associate a frequency of use for each phrase with each of a plurality of context identifiers.Client device110 may utilize this stored context data to assist in its selection and ranking of metadata and phrases.
In an embodiment,client device110 is simply made aware of an activity, withoutuser105 explicitly usingclient device110 to participate in or access information about the activity. For example,client device110 may be a touch screen control panel or smartphone.Client device110 may retrieve information indicating the current activity from another device, such as a digital video recorder, via Bluetooth, WiFi, or similar technologies. Or, as another example,client device110 may utilize data from user input, calendar items, sensors, and/or location services to look up an appropriate activity in a database.
Alternatively,client device110 may rely uponcentral server system130 to determine the activity on its own. For example,central server system130 may be sending an audio or video stream toclient device110, and thus be aware of the content being shared in that stream. In such an embodiment,central server system130 requires no information fromclient device110 to be able to select metadata or rank phrases based on said content. In fact, in such an embodiment,central server system130 may be responsible for sharing content identifiers withclient device110, as needed byclient device110 to perform context-aware tasks. Or,client device110 may be left entirely unaware of the context identifying information known tocentral server system130.Central server system130 may also determine context from, among other considerations, the afore-mentioned data from user input, calendar items, sensors, and/or location services.
5.2. Harvesting Phrase Data from Messages
In an embodiment, any device that sends, receives, or relays messages may harvest those messages for phrases to add to a repository of phrases. Phrases may be of any length, up to and including the length of the entire message. The device may be configured to identify phrases using grammatical, semantic, syntactic, or any other suitable clues. For example, the device may identify every word as a separate phrase. As another example, the device may identify every clause as a phrase. The device may further identify the same portion of the message as being part of several phrases. For example, from the phrase “You have to see it to believe it,” the device may identify, among other phrases, some or all of the following phrases: “you have to,” “see it,” “believe it,” “see it to believe it,” “you have to see it,” and “You have to see it to believe it.” For each identified phrase that is not already in the relevant phrase repository, the device adds the identified phrase to the repository.
In an embodiment, for each phrase identified in a message, a device may further update a usage history associated with the repository of phrases, regardless of whether the phrase is new to the repository of phrases. For example, the device may maintain a usage history indicating the number of times each phrase has been used. In an embodiment, the device may also or instead maintain a popularity score that is weighted over time, so that more recent uses of the phrase impact the score more than older uses of the phrase. The usage history may further include data indicating the number of times each phrase has been used within one or more contexts, as identified through the techniques discussed above. Alternatively, a separate phrase repository may be maintained for each context.
In an embodiment, any device that collects phrase data as described above may share some or all of that data with other devices in a messaging network to assist those devices in building their own data repositories for generating messaging interfaces. For example,central server system130 may periodically send updated phrase data for storage atclient device110. As another example,client device110 may periodically share updated phrase data withcentral server system130 and/or other client devices operated by other users.
5.3. Selecting Phrases for Inclusion as Phrase-Based ElementsWhen a device, such asclient device110 orcentral server132, generates a list of commonly used phrases for use as phrase-based elements in a messaging interface, the device may filter or rank the phrases, so as to ensure that the phrases most likely to be relevant to a user are more easily accessible (e.g. with minimal scrolling) in the interface. Thus, while in certain embodimentscentral server132 may generate a list of commonly used phrases simply by retrieving all phrases fromdata repository134, in other embodiments,central server132 may select only those phrases whose usage histories match certain criteria. For example, selection may be limited only to those phrases that have a certain popularity score or higher. As another example, selection may be limited only to those phrases that have been used in a certain context. In an embodiment comprising multiple data repositories, having a different phrase repository for each of a plurality of contexts, selection may be limited only to phrases appearing in the repository associated with a current context. In an embodiment, the selected phrases are also ordered based at least partly upon popularity or context data.
For example, a group of users may frequently exchange messages comprising the phrase “BwrDrgn!” while playing a video game named “Warcraft,” but use the phrase infrequently elsewhere.Central server system130 may have harvested this phrase using the above described techniques, and further compiled a usage history for the phrase. If user A were to launch a messaging interface while watching a newscast,central server system130 would either rank the phrase very low, or not select the phrase at all. Thus, if at all, user A would only be presented with a selectable control corresponding to the phrase “BwrDrgn!” after much scrolling. By contrast, if user B were to launch the messaging interface while playing “Warcraft” or a similar video game,central server system130 would rank the phrase highly. Thus, user B would be presented with a selectable control corresponding to the phrase after much less scrolling, if any.
5.4. Context-Sensitive MetadataAs used herein, metadata may be described as being associated with an activity if the metadata is data or any other type of information that describes or illustrates any aspect of the activity. Aspects of an activity may include, without limitation, events, viewable or audible content involved in the activity, times, dates, participants, locations, sponsors, fees, and so on. Metadata elements may take the form of alphanumerical characters, symbols, words, phrases, images, videos, audio, and/or calendar objects.
For example, metadata elements associated with the activity of watching a television show activity may be derived from metadata for the television show, including, without limitation, a series name (e.g., control361), an episode name (e.g., control364), an episode number, an air date and/or time (e.g., control365), an original broadcast date, character names (e.g., controls362 and363), images (e.g., control366), audio or video clips (e.g., control367), the names of actors, actresses, writers, directors, and/or producers, and so on. Similar metadata elements may be associated with watching a movie or listening to music.
5.5. Dynamic Interface Layout Based on Predicted Next ElementsIn an embodiment, a client device may automatically change the layout of a messaging interface after certain elements are inserted into the message, based on filters such as grammatical rules and/or usage patterns. The rules or filters may be used to predict which elements or types of elements will likely follow one or more of the previously entered elements. Accordingly, the interface may be customized after each element is selected, so that the types of elements predicted to come next are more readily accessible for selection.
As a simple example, the last selected control may automatically be scrolled out of view ininterface300, based on the assumption that the control is not likely to be selected twice in a row. As another example, after the user selects a “noun” control fromcontrol group310 ofinterface300, control group320 (representative of verbs) may be swapped into the place ofcontrol group310, based on the assumption that a verb will most likely be selected after a noun. In fact, in an embodiment, only one control group is shown at any given time, but the control group is rotated into the interface based on the afore-mentioned predictions. Mode switching controls similar to controls391-394 may be used to swap in the desired controls when the prediction is incorrect.
In an embodiment, the actual layout of the messaging interface may remain the same, but the control that is in focus may automatically change to a different control group. In an embodiment, controls may be re-ordered after each selection, based on scores or rules predicting the likelihood of each corresponding element occurring after the previous one or more elements. This re-ordering will often result in an entirely new set of controls being swapped into view.
In some embodiments, each message is generated according to one of one or more message templates. For example, the message template may dictate which types of elements can be inserted at what position in the message. One template may dictate, for instance, a simple pattern of pronoun-verb-subject. Many other templates are also possible. In such embodiments, the layout may change after the insertion of one element so as to prioritize those controls that represent the next type of element in the template. In an embodiment, a user may select between multiple templates at any time while composing a message.
5.6. User of Selection of an Activity from within the Message Generation Interface
In an embodiment, the client device retrieves context-sensitive metadata-based elements in response to input received after the client has already rendered a message generation interface. In such an embodiment, the user may identify a context after launching the messaging interface. For example,information panel460 ofinterface400 allows a user to select different contexts (e.g., different television shows) from within a messaging interface. As another example, a messaging interface may allow a user to select a calendar date. In response to selection of the calendar date, controls representing metadata associated with that date may be inserted into the interface. The interface may be updated any time the user selects a new context, both to add new metadata and to filter or re-order phrase-based elements.
5.7. Implementation in Non-Centralized EnvironmentsIn some embodiments, some or all of the functions described herein as being performed bycentral server system130 may instead be performed byclient device110, including the sending of messages and the harvesting of phrases. For example,client device110 may build its own phrase repository and usage history based at least partly on messages previously received atclient device110 from other users.Client device110 may further include its own repository of context-sensitive metadata, which metadata may or may not be periodically updated based on data received fromcontent providers140. Based on these repositories of phrases and metadata,client device110 may therefore be entirely capable of performing some or all of the techniques described herein for selecting and ordering elements.
In such embodiments, the usefulness of locally-stored phrase repositories and usage histories may be further enhanced by having each client device share its phrase repository(ies) and usage history(ies) with other client devices. This sharing may be accomplished by a variety of synchronization or distributed sharing techniques.
6.0. Implementation Mechanism—Hardware OverviewAccording to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.
For example,FIG. 5 is a block diagram that illustrates acomputer system500 upon which an embodiment of the invention may be implemented.Computer system500 includes abus502 or other communication mechanism for communicating information, and ahardware processor504 coupled withbus502 for processing information.Hardware processor504 may be, for example, a general purpose microprocessor.
Computer system500 also includes amain memory506, such as a random access memory (RAM) or other dynamic storage device, coupled tobus502 for storing information and instructions to be executed byprocessor504.Main memory506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed byprocessor504. Such instructions, when stored in non-transitory storage media accessible toprocessor504, rendercomputer system500 into a special-purpose machine that is customized to perform the operations specified in the instructions.
Computer system500 further includes a read only memory (ROM)508 or other static storage device coupled tobus502 for storing static information and instructions forprocessor504. Astorage device510, such as a magnetic disk or optical disk, is provided and coupled tobus502 for storing information and instructions.
Computer system500 may be coupled viabus502 to adisplay512, such as a cathode ray tube (CRT), for displaying information to a computer user. Aninput device514, including alphanumeric and other keys, is coupled tobus502 for communicating information and command selections toprocessor504. Another type of user input device iscursor control516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections toprocessor504 and for controlling cursor movement ondisplay512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
Computer system500 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes orprograms computer system500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed bycomputer system500 in response toprocessor504 executing one or more sequences of one or more instructions contained inmain memory506. Such instructions may be read intomain memory506 from another storage medium, such asstorage device510. Execution of the sequences of instructions contained inmain memory506 causesprocessor504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such asstorage device510. Volatile media includes dynamic memory, such asmain memory506. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.
Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprisebus502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Various forms of media may be involved in carrying one or more sequences of one or more instructions toprocessor504 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local tocomputer system500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data onbus502.Bus502 carries the data tomain memory506, from whichprocessor504 retrieves and executes the instructions. The instructions received bymain memory506 may optionally be stored onstorage device510 either before or after execution byprocessor504.
Computer system500 also includes acommunication interface518 coupled tobus502.Communication interface518 provides a two-way data communication coupling to anetwork link520 that is connected to alocal network522. For example,communication interface518 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example,communication interface518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation,communication interface518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link520 typically provides data communication through one or more networks to other data devices. For example,network link520 may provide a connection throughlocal network522 to ahost computer524 or to data equipment operated by an Internet Service Provider (ISP)526.ISP526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”528.Local network522 andInternet528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals onnetwork link520 and throughcommunication interface518, which carry the digital data to and fromcomputer system500, are example forms of transmission media.
Computer system500 can send messages and receive data, including program code, through the network(s),network link520 andcommunication interface518. In the Internet example, aserver530 might transmit a requested code for an application program throughInternet528,ISP526,local network522 andcommunication interface518.
The received code may be executed byprocessor504 as it is received, and/or stored instorage device510, or other non-volatile storage for later execution.
7.0. Extensions and AlternativesIn the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention, and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.