Source: http://www.google.com/patents/US8219126?ie=ISO-8859-1
Timestamp: 2015-07-30 21:14:59
Document Index: 459205032

Matched Legal Cases: ['arty 130', 'arty 130', 'arty 140', 'arty 140', 'arty 140', 'arty 140', 'arty 140', 'arty 140', 'arty 140', 'arty 140']

Patent US8219126 - Provisioning my status information to others in my social network - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA device, system, and method are directed towards sending a status of a user in a social network to a recipient. A status of the user is received over a channel. The recipient is selected based on a membership in the social network, a preference of the recipient, or a type of the status. Another channel...http://www.google.com/patents/US8219126?utm_source=gb-gplus-sharePatent US8219126 - Provisioning my status information to others in my social networkAdvanced Patent SearchPublication numberUS8219126 B2Publication typeGrantApplication numberUS 12/728,178Publication dateJul 10, 2012Filing dateMar 19, 2010Priority dateDec 22, 2006Also published asUS8224359, US9083794, US20080155080, US20100228826, US20120284338Publication number12728178, 728178, US 8219126 B2, US 8219126B2, US-B2-8219126, US8219126 B2, US8219126B2InventorsCameron Marlow, Neal Sample, Chris KalaboukisOriginal AssigneeYahoo! Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (58), Non-Patent Citations (9), Referenced by (10), Classifications (23), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetProvisioning my status information to others in my social network
US 8219126 B2Abstract
A device, system, and method are directed towards sending a status of a user in a social network to a recipient. A status of the user is received over a channel. The recipient is selected based on a membership in the social network, a preference of the recipient, or a type of the status. Another channel is selected based on information about a mode of communication between the recipient and the user and/or another member related to the user in the social network. The status may be modified from one type to another type based on the recipient. The status is forwarded to the recipient over the other channel. Forwarding may comprise unicasting, multicasting, and/or delaying sending the status until the other channel is available. A channel may include an application protocol.
1. A method performed by a network device for managing a communication over a network, the network device executes instructions that embody the method and enable actions by the network device, comprising:
receiving at least one status of a user of a mobile device in a social network;
selecting from the social network at least one recipient for the at least one status;
modifying a media type of the at least one status based at least on the selected at least one recipient in the social network;
forwarding the at least one status having the modified media type to the selected at least one recipient;
determining a plurality of application protocols associated with the at least one recipient based on information about the at least one recipient in a plurality of address books of the user of the mobile device;
selecting an application protocol from the plurality of application protocols based at least on an availability of the application protocol; and
wherein the at least one status having the modified media type is forwarded to the at least one recipient over the selected application protocol.
2. The method of claim 1, wherein the at least one status of the user of the mobile device is received over a first channel, and wherein the at least one status having the modified media type is forwarded to the at least one recipient over a second channel.
3. The method of claim 2, wherein the first channel is a first application protocol, and the second channel is a second application protocol.
4. The method of claim 1, wherein the at least one status comprises a hierarchy of statuses, and wherein modifying the media type of the at least one status further includes providing a specificity of the at least one status based on a level of the hierarchy of statuses that is further based on an association of the at least one recipient with a particular community in the social network.
5. The method of claim 1, wherein forwarding the at least one modified status to the at least one recipient further comprises:
further modifying the media type of the at least one status based on one of the plurality of application protocols, a preference of the at least one recipient, and information about a device receiving the at least one status over the one application protocol; and
sending the at least one status having the modified media type to the at least one recipient over the one application protocol, based on a priority of the at least one status.
receiving information about a plurality of social networks, wherein the user of the mobile device is in one of the plurality of social networks, and the at least one recipient is in another one of the plurality of social networks; and
using the received information to combine the plurality of social networks into the social network.
7. A mobile device for managing a communication over a network, comprising:
a transceiver device to send and receive data over the network; and
a processor device, in communication with the transceiver and executing instructions at the mobile device that perform actions, comprising:
sending over the transceiver at least one status of a user of the mobile device; and
enabling a network device to perform further actions, including:
selecting from a social network at least one recipient for the at least one status;
8. The mobile device of claim 7, wherein the at least one status of the user of the mobile device is sent over a first channel, and wherein the at least one status having the modified media type is forwarded to the at least one recipient over a second channel.
9. The mobile device of claim 8, wherein the first channel is a first application protocol, and the second channel is a second application protocol.
10. The mobile device of claim 7, wherein the at least one status comprises a hierarchy of statuses, and wherein modifying the media type of the at least one status further includes providing a specificity of the at least one status based on a level of the hierarchy of statuses that is further based on an association of the at least one recipient with a particular community in the social network.
11. The mobile device of claim 7, wherein forwarding the at least one status having the modified media type to the at least one recipient further comprises:
further modifying the media type of the at least one status based on at least one of the plurality of application protocols, a preference of the at least one recipient, and information about a device receiving the at least one status over the one application protocol; and
12. The mobile device of claim 7, wherein the actions further comprise:
enabling the network device to receive information about a plurality of social networks, wherein the user of the mobile device is in one of the plurality of social networks, and the at least one recipient is in another one of the plurality of social networks; and
enabling the network device to use the received information to combine the plurality of social networks into the social network.
13. A system for managing a communication over a network, comprising:
a mobile device that executes provided instructions to perform actions comprising:
enabling an input of at least one status of a user of the mobile device in a social network; and
a network device that executes provided instructions to perform actions comprising:
receiving the at least one status of the user of the mobile device;
14. The system of claim 13, wherein the at least one status of the user of the mobile device is received over a first application protocol, and wherein the at least one status having the modified media type is forwarded to the at least one recipient over a second application protocol.
15. The system of claim 13, wherein the at least one status comprises a hierarchy of statuses, and wherein modifying the media type of the at least one status further includes providing a specificity of the at least one status based on a level of the hierarchy of statuses that is further based on an association of the at least one recipient with a particular community in the social network.
16. A non-transitory processor readable medium having processor executable instructions for managing a communication over a network, the processor executable instructions configured to enable a processor device that executes the instructions to enable actions, comprising:
17. The non-transitory processor readable storage medium of claim 16, wherein the at least one status of the user of the mobile device is received over a first channel, and wherein the at least one status having the modified media type is forwarded to the at least one recipient over a second channel.
18. The non-transitory processor readable storage medium of claim l7, wherein the first channel is a first application protocol, and the second channel is a second application protocol.
This utility patent application is a Continuation of pending U.S. patent application Ser. No. 11/615,920 filed on Dec. 22, 2006, the benefit of which is claimed under 35 U.S.C. �120, and is further incorporated herein by reference.
The present invention relates generally to mobile communications and, more particularly, but not exclusively to providing a status of a user in a social network to another user of the social network over a network.
One aspect of our everyday lives that may benefit from online social networking technology involves communicating information about a member in the social network to another member in the social network, thereby enhancing the use of the social network and providing more relevance to the social network.
For example, some social networking websites, such as Twitter™ and/or Dodgeball™ may provide a status of a user in the social network. Moreover, some Instant Messaging (IM) applications may provide an idle/active status of a user of the IM application. However, because of limitations in technology, the information about a member may not be sent to a destination that the other member can easily access. Therefore, it is with respect to these considerations and others that the present invention has been made.
FIG. 2 shows one embodiment of a client device that may be included in a system implementing one or more embodiments of the invention;
FIG. 3 shows one embodiment of a network device that may be included in a system implementing one or more embodiments of the invention;
FIG. 4 illustrates a logical flow diagram generally showing one embodiment of a process for sending a status of a user in a social network; and
FIG. 5 illustrates another logical flow diagram generally showing one embodiment of a process for sending a status of a user in a social network.
As used herein, the terms “social network” and “social community” refer to a concept that an individual's personal network of friends, family colleagues, coworkers, and the subsequent connections within those networks, can be utilized to find more relevant connections for a variety of activities, including, but not limited to dating, job networking, service referrals, content sharing, like-minded individuals, activity partners, or the like. Such social network may be created based on a variety of criteria, including, for example, an address book, a social event, an online community, or the like.
As used herein, the term “member” refers to a user who is included in any collection. The term “group” refers to a collection of members who are participating in an event. As such the term “member of an event” refers a member of a group associated with the event.
The term “content” refers to any digital data directed towards a user of a computing device, including, but not limited to audio data, multimedia data, photographs, video data, still images, text, graphics, animation files, voice messages, text messages, or the like.
The terms “ID,” “user ID,” or “identity” refers to an identifier for a member. The identifier may include any information useable in identifying the member, including an alphanumeric string, picture, sound, movie clip, or the like.
As used herein, the term “channel” refers to any mechanism for communicating over a network, including any combination of sending/receiving applications, application protocol or other network protocols, sending/receiving operating systems or platforms, or the like. The term “application protocol” refers to any network protocols specified at the Open Systems Interconnection (OSI) layer 7.
Briefly stated the various embodiments are directed towards sending a status of a user in a social network to a recipient. Various embodiments are directed to providing a generalized abstract interface for conveying the status of a member in a social network to a subset of friends in the social network. In one embodiment, a status of the user is received over a channel. The recipient is selected based on a membership in the social network, a preference of the recipient, or a type of the status. Another channel is selected based on information about a mode of communication between the recipient and the user and/or another member related to the user in the social network. The status may be modified from one type to another type based on the recipient. The status is forwarded to the recipient over the other channel. Forwarding may comprise unicasting, multicasting, and/or delaying sending the status until the other channel is available. A channel may include an application protocol.
FIG. 1 shows components of an environment in which one or more embodiments of the invention may be practiced. Not all the components may be required to practice the invention, and variations in the arrangement and type of the components may be made without departing from the spirit or scope of the invention. As shown, system 100 of FIG. 1 includes local area networks (“LANs”)/wide area networks (“WANs”)-(network) 105, wireless network 110, Status Sharing Server (SSS) 106, mobile devices (client devices) 102-104, client device 101, and third party 130.
One embodiment of mobile devices 102-104 is described in more detail below in conjunction with FIG. 2. Generally, however, mobile devices 102-104 may include virtually any portable computing device capable of receiving and sending a message over a network, such as network 105, wireless network 110, or the like. Mobile devices 102-104 may also be described generally as client devices that are configured to be portable. Thus, mobile devices 102-104 may include virtually any portable computing device capable of connecting to another computing device and receiving information. Such devices include portable devices such as, cellular telephones, smart phones, display pagers, radio frequency (RF) devices, infrared (IR) devices, Personal Digital Assistants (PDAs), handheld computers, laptop computers, wearable computers, tablet computers, integrated devices combining one or more of the preceding devices, and the like. As such, mobile devices 102-104 typically range widely in terms of capabilities and features. For example, a cell phone may have a numeric keypad and a few lines of monochrome LCD display on which only text may be displayed. In another example, a web-enabled mobile device may have a touch sensitive screen, a stylus, and several lines of color LCD display in which both text and graphics may be displayed.
Mobile devices 102-104 also may include at least one other client application that is configured to receive content from another computing device. The client application may include a capability to provide and receive textual content, media content, and the like. The client application may further provide information that identifies itself, including a type, capability, name, and the like. In one embodiment, mobile devices 102-104 may uniquely identify themselves through any of a variety of mechanisms, including a phone number, Mobile Identification Number (MIN), an electronic serial number (ESN), or other mobile device identifier. The information may also indicate a content format that the mobile device is enabled to employ. Such information may be provided in a message, or the like, sent to SSS 106, client device 101, or other computing devices.
Mobile devices 102-104 may also be configured to communicate a message, such as through Short Message Service (SMS), Multimedia Message Service (MMS), instant messaging (IM), internet relay chat (IRC), Mardam-Bey's IRC (mIRC), Jabber, and the like, between another computing device, such as SSS 106, client device 101, each other, or the like. However, the present invention is not limited to these message protocols, and virtually any other message protocol may be employed. For example, the client application may enable a user to interact with the browser application, email application, VOIP applications, or the like.
Mobile devices 102-104 may further be configured to include a client application that enables the end-user to log into an end-user account that may be managed by another computing device, such as SSS 106. Such end-user account, for example, may be configured to enable the end-user to receive emails, send/receive Instant Message (IM) messages, SMS messages, access selected web pages, participate in a social networking event, or the like. However, participation in various social networking events may also be performed without logging into the end-user account.
In addition, mobile devices 102-104 may include another application that is configured to enable the mobile user to share and/or receive content, and to display the content. In one embodiment, each of mobile devices 102-104 may share with and/or receive the content from SSS 106 and/or from another one of mobile devices 102-104. For example, content may be shared between the mobile devices using MMS, WAP, or the like. In one embodiment, a mobile device may receive a message indicating the content is available for viewing and/or annotating at a website, or the like.
In conjunction with sharing content, mobile devices 102-104 may enable an interaction with each other, through sharing various messages, and generally participating in a variety of integrated social experiences beyond merely voice communications. In one embodiment, mobile devices 102-104 may enable the interaction with a user associated with an event. For example, a user of one of mobile devices 102-104 may create a group that includes identified members. In one embodiment, members of the group may elect to share content, such as photographs, video clips, audio clips, text messages, emails, or the like, with other members of the group. Moreover, mobile devices 102-104 may enable any of the members of the group to also add other members to the group.
Mobile devices 102-104 may also communicate with non-mobile client devices, such as client device 101, or the like. In one embodiment, such communications may include providing information about the content to a user of client device 101, or the like.
Client device 101 may include virtually any computing device capable of communicating over a network to send and receive information, including social networking information, or the like. One embodiment of client device 101 is described in more detail below in conjunction with FIG. 2. Generally however, the set of such devices may include devices that typically connect using a wired or wireless communications medium such as personal computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, or the like. In one embodiment, client device 101 may be configured to access a website, or other location, of shared content, and to annotate the content, add additional content, or the like.
In one embodiment, one of client devices 101-104 may send a status of a user of the device to at least one other device over network 110 and/or network 105. In one embodiment, the status may be sent to SSS 106 over network 110 and/or network 105. In one embodiment, one of client devices 101-104 may send the status to SSS 106 over one channel, such as over an SMTP protocol, and SSS 106 may send the status to another one of client devices 101-104 over another channel, such as over an SMTP protocol. Thus, in one embodiment, the other one of client devices 101-104 may receive the status over a push mechanism. In another embodiment, SSS 106 may provide a pull mechanism for the other one of client devices 101-104 to pull the status (e.g., using polling, a timer, or the like). In another embodiment, the other one of client devices 101-104 may display the received status in a variety of format, including by priority, by type, in chronological, reverse chronological order, in a gestalt fashion, such as by changing an image of an avatar representing the user, or the like. Client devices 101-104 may employ a process similar to that described below in conjunction with FIG. 5 to perform at least some of its actions.
Wireless network 110 may further employ a plurality of access technologies including 2nd (2G), 3rd (3G) generation radio access for cellular systems, WLAN, Wireless Router (WR) mesh, and the like. Access technologies such as 2G, 3G, and future access networks may enable wide area coverage for mobile devices, such as mobile devices 102-104 with various degrees of mobility. For example, wireless network 110 may enable a radio connection through a radio network access such as Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (WCDMA), and the like. In essence, wireless network 110 may include virtually any wireless communication mechanism by which information may travel between mobile device s 102-104 and another computing device, network, and the like.
Network 105 is configured to couple SSS 106 and its components with other computing devices, including, mobile devices 102-104, client device 101, and through wireless network 110 to mobile devices 102-104. Network 105 is enabled to employ any form of computer readable media for communicating information from one electronic device to another. Also, network 105 can include the Internet in addition to local area networks (LANs), wide area networks (WANs), direct connections, such as through a universal serial bus (USB) port, other forms of computer-readable media, or any combination thereof. On an interconnected set of LANs, including those based on differing architectures and protocols, a router acts as a link between LANs, enabling messages to be sent from one to another. Also, communication links within LANs typically include twisted wire pair or coaxial cable, while communication links between networks may utilize analog telephone lines, full or fractional dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Networks (ISDNs), Digital Subscriber Lines (DSLs), wireless links including satellite links, or other communications links known to those skilled in the art. Furthermore, remote computers and other related electronic devices could be remotely connected to either LANs or WANs via a modem and temporary telephone link. In essence, network 105 includes any communication method by which information may travel between SSS 106, client device 101, and other computing devices.
One embodiment of SSS 106 is described in more detail below in conjunction with FIG. 3. Briefly, however, SSS 106 may include any computing device capable of connecting to network 105 to enable determination (e.g. creation and/or modification) of a user's social network based on user input. SSS 106 may also be configured to determine the social network of a user(s) based on a plurality of address books, buddy list or other social network information from a plurality of other social networks. SSS 106 may also receive a status from at least one of client devices 101-104 over a channel. SSS 106 may select a recipient and/or another channel to forward the status to the recipient. Before sending the status over the other channel, SSS 106 may also modify the status based on, among other things, social network information, preferences of a recipient, receiving device information, channel information, or the like. SSS 106 may then send the status to at least one of client devices 101-104 over the other channel using a variety of mechanisms, including unicasting, multicasting, broadcasting, multiplexed broadcasting, peercasting, or the like.
As is apparent to one skilled in the art, the status received by SSS 106 is associated with a particular user, but not necessarily with any particular channel. Thus, various embodiments of the invention provide a generalized interface to send a status independent of particular channels. SSS 106 may employ a process similar to that described below in conjunction with FIG. 4 to perform at least some of its actions.
Devices that may operate as SSS 106 include personal computers desktop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, servers, and the like.
Third party 130 may include any computing device capable of connecting to network 105 to provide social networking information and/or receive a status of a user. Third party 140 may include act substantially similar to client device 101, except that third party 140 may be an external service (e.g., web service, application service) configured to provide the status of a user over a variety of other channels. For example, third party 140 may subscribe to receive at least one status for at least one user. Third party 140 may act as a recipient or may forward requests by other recipients. The status may be sent to third party 140 over a variety of channels. In one embodiment, third party 140 may request a status by polling SSS 106 using, for example, and Application Programming Interface (API), such as XML-RPC, or the like. Third party 140 may provide this status in a variety of formats to at least one other device. For example, third party 140 may show the user's status on the user's home page in a third party website, for example.
Although FIG. 1 illustrates SSS 106 as a single computing device, the invention is not so limited. For example, one or more functions of SSS 106 may be distributed across one or more distinct computing devices. For example, sending statuses between users of a social network, managing various social networking tasks, including sharing of content, managing IM session, SMS messages, email messages, posting of content, or the like for an event, may be performed by a plurality of computing devices, without departing from the scope or spirit of the present invention.
FIG. 2 shows one embodiment of client device 200 that may be included in a system implementing one or more embodiments of the invention. Client device 200 may include many more or less components than those shown in FIG. 2. However, the components shown are sufficient to disclose an illustrative embodiment for practicing the present invention. Client device 200 may represent, for example, mobile devices 102-104 of FIG. 1.
As shown in the figure, client device 200 includes a processing unit (CPU) 222 in communication with a mass memory 230 via a bus 224. Client device 200 also includes a power supply 226, one or more network interfaces 250, an audio interface 252, video interface 259, a display 254, a keypad 256, an illuminator 258, an input/output interface 260, a haptic interface 262, and an optional global positioning systems (GPS) receiver 264. Power supply 226 provides power to mobile device 200. A rechargeable or non-rechargeable battery may be used to provide power. The power may also be provided by an external power source, such as an AC adapter or a powered docking cradle that supplements and/or recharges a battery.
Client device 200 may optionally communicate with a base station (not shown), or directly with another computing device. Network interface 250 includes circuitry for coupling client device 200 to one or more networks, and is constructed for use with one or more communication protocols and technologies including, but not limited to, global system for mobile communication (GSM), code division multiple access (CDMA), time division multiple access (TDMA), user datagram protocol (UDP), transmission control protocol/Internet protocol (TCP/IP), SMS, general packet radio service (GPRS), WAP, ultra wide band (UWB), IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMax), SIP/RTP, or any of a variety of other wireless communication protocols. Network interface 250 is sometimes known as a transceiver, transceiving device, or network interface card (NIC).
Video interface 259 is arranged to capture video images, such as a still photo, a video segment, an infrared video, or the like. For example, video interface 259 may be coupled to a digital video camera, a web-camera, or the like. Video interface 259 may comprise a lens, an image sensor, and other electronics. Image sensors may include a complementary metal-oxide-semiconductor (CMOS) integrated circuit, charge-coupled device (CCD), or any other integrated circuit for sensing light.
Optional GPS transceiver 264 can determine the physical coordinates of client device 200 on the surface of the Earth, which typically outputs a location as latitude and longitude values. GPS transceiver 264 can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS or the like, to further determine the physical location of client device 200 on the surface of the Earth. It is understood that under different conditions, GPS transceiver 264 can determine a physical location within millimeters for mobile device 200; and in other cases, the determined physical location may be less precise, such as within a meter or significantly greater distances. In one embodiment, however, mobile device may, through other components, provide other information that can be employed to determine a physical location of the device, including for example, a MAC address, IP address, or the like.
Mass memory 230 includes a RAM 232, a ROM 234, and other storage means. Mass memory 230 illustrates another example of computer storage media for storage of information such as computer readable instructions, data structures, program modules or other data. Mass memory 230 stores a basic input/output system (“BIOS”) 240 for controlling low-level operation of mobile device 200. The mass memory also stores an operating system 241 for controlling the operation of mobile device 200. It will be appreciated that this component may include a general purpose operating system such as a version of UNIX, or LINUX™, or a specialized client communication operating system such as Windows Mobile™, or the Symbian� operating system. The operating system may include, or interface with a Java virtual machine module that enables control of hardware components and/or operating system operations via Java application programs.
Memory 230 further includes one or more data storage 244, which can be utilized by client device 200 to store, among other things, applications 242 and/or other data. For example, data storage 244 may also be employed to store information that describes various capabilities of mobile device 200. The information may then be provided to another device, including being sent as part of a header during a communication, sent upon request, or the like. Moreover, data storage 244 may also be employed to store content and/or social networking information including text messages, address books, group member lists, or the like. At least a portion of the content and/or event information may also be stored on storage medium 266, such as a disk drive, removable storage, or the like within mobile device 200.
Applications 242 may include computer executable instructions which, when executed by mobile device 200, provide such functions as calendars, contact managers, task managers, transcoders, database programs, word processing programs, screen savers, security applications, spreadsheet programs, games, search programs, and so forth. Applications 242 may further include Message Managers (MM) 245 and Social Network Manager (SNM) 246.
SNM 246 includes any component configured to create social network information, send/receive social network information (e.g., over network interface 250), or otherwise manage social network information. In one embodiment, SNM 246 may receive a definition of s social network (e.g., as an address book, a user relationship graph, a buddy list) over network interface 250 from, for example, SSS 106 of FIG. 1. SNM 246 may store this information storage medium 266, RAM 232, or other data source. SNM 246 may provide the information over display 254, or the like. SNM 246 may enable selection of a community and/or a user from a social network. In one embodiment, SNM 246 may pull the social network information over network interface 250 periodically. In another embodiment, SNM 246 may pull the information as needed (e.g., when a user requests the information).
MM 245 represents any of a variety of applications configured to transmit, receive, and/or otherwise process messages and other network content, including, but not limited to SMS, MMS, IM, email, VOIP, browsers, or the like, and to enable telecommunication with another user of another networked device. For example, MM 245 may include any of a variety of browser applications, which may be run under control of operating system 241 to enable and manage requesting, receiving, and rendering markup pages such as WAP pages (sometimes referred to as WAP cards), SMGL, HTML, HDML, WML, WMLScript, JavaScript, and the like.
MM 245 may further include an IM application that is configured to initiate and otherwise manage an instant messaging session, including, but not limited to AOL Instant Messenger, Yahoo! Messenger, .NET Messenger Server, ICQ, and the like. In one embodiment, the IM application within MM 245 may be configured to employ a SIP/RTP to integrate IM/VOIP features. For example, the IM application may employ SIMPLE (SIP for Instant Messaging and Presence Leverage), APEX (Application Exchange), Prim (Presence and Instant Messaging Protocol), Open XML-based XMPP (Extensible Messaging and Presence Protocol), more commonly known as Jabber and OMA (Open Mobile Alliance)'s IMPS (Instant Messaging and Presence Service) created specifically for mobile devices, or the like.
MM 245 may also include text messaging application(s) that enables client device 200 to receive and/or send text messages to another device. In one embodiment, the text messaging application(s) may also provide an alerting mechanism that indicates to a user of client device 200 when a text message is received. The text messaging application(s) may also allow the user to compose a text response message, and to send the text response message over a network. The text messaging application(s) may operate to manage SMS text messages, MMS messages, Enhanced Message Service (EMS) messages, or the like, where graphics, video clips, sound files, or other content may be communicated between client device 200 and another networked device.
In any event, any one or more of the messaging applications within MM 245 may be employed to enable a user of client device 200 to create a status message, select a social network, community in the social network, and/or a recipient in the social network, and send the status message over network interface 250. In one embodiment, the status message may be created and/or otherwise entered by a user of client device 200 using a variety of mechanism, including video interface 259, audio interface 252, biometric sensor 262, or the like. In one embodiment, MM 245 may retrieve social networking information and information about a recipient from SNM 246. MM 245 may employ a process similar to that described below in conjunction with FIG. 5 to perform at least some of its actions.
In one embodiment, MM 245 may provide an API, or other interface to other components of client device 200 to provide the status. For example, in one embodiment, other applications and/or components of applications 242 may receive a reading from biometric sensor 262. Biometric sensor 262 may be any component configured to receive an analog or digital input about a user, including a user temperature, thermo-graphical image, pulse, electrical impedance, fingerprint, blood glucose level, retina scan, or the like. In one embodiment, the input may be converted into a label, image, or other information. The input and/or the converted information may be sent to MM 245, using for example, an API. MM 245 may provide the status over network interface 250.
In one embodiment, other applications and/or components of applications 242 (including MM 245) may intermittently poll for information from other components of client device, such as GPS source 264, and/or video interface 259. Based on this polled information, the other application may determine a status of the user. The status may then be sent to MM 245 for further processing.
FIG. 3 shows one embodiment of a network device, according to one embodiment of the invention. Network device 300 may include many more components than those shown. The components shown, however, are sufficient to disclose an illustrative embodiment for practicing the invention. Network device 300 may represent, for example, SSS 106 of FIG. 1.
The mass memory also stores program code and data. One or more applications 350 are loaded into mass memory and run on operating system 320. Examples of application programs may include transcoders, schedulers, calendars, database programs, word processing programs, HTTP programs, including XmlHTTPRequest (XHR), Asynchronous JavaScript and XML (AJAX), JavaScript Object Notation (JSON) programs, customizable user interface programs, IPSec applications, encryption programs, security programs, account management, and so forth. Status Manager 353 and Message Servers 354 may also be included as application programs within applications 350.
Status/Social Network Data Store (SNDS) 352 stores a plurality of received content. In one embodiment, SNDS 352 may be a database, a file structure, or the like. SNDS 352 may store a definition of a social network, including the relationship between members of the social network, as a graph, tree, list, or other data structure. SNDS 352 may store unique IDs for all members of a social network, or the like. SNDS 352 may also store a status associated with a member. For example, a member may send the member's status to network device 300 over network interface 310 using a channel. SNDS 352 may associate the status to the member, and may provide the status to another component for forwarding the status to another member of the social network over network interface 310 using another channel.
Status Manager (SM) 353 includes any component configured to receive a status (e.g., over network interface 310 or from SNDS 242), determine a recipient, modify the status based on, among other things, social network information, preferences of a recipient, receiving device information, channel information, or the like. SM 353 may be configured to retrieve the identity of the recipient from SNDS 352. SM 353 may determine a channel to send the status based on, for example, and available channel, or the like. For example, when a client device associated with a member of a social network become activated, the client device may send a message to SM 353 over network interface 310 to indicate that the client device is active and that the channel associated with the client device is available. Similarly, when a receiving application program becomes active, the program may also send a similar message. In any case, SM 353 may direct MS 354 to send the status to at least one recipient over a network interface 310 using a (available) channel (e.g., over one the application protocol SMTP, SMPP, SMS, etc).
Message Server(s) (MS) 354 include virtually any communication server that may be configured to enable communications between networked devices, including email servers, Simple Mail Transfer Protocol (SMTP) servers, Short Message Peer-to-Peer Protocol (SMPP) servers, SMS servers, various text messaging servers, VOIP servers, IM servers, MMS servers, RSS servers, audio servers, web servers, or the like. MS 354 may employ SNDS 352 to store or otherwise manage content that may be communicated over a network. MS 354 may be configured to receive a status from SM 353.
SN 353 and/or MS 354 may employ a process similar to that described below in conjunction with FIG. 5 to perform at least some of its actions.
The operation of certain aspects of the invention will now be described with respect to FIGS. 4-5. FIG. 4 illustrates a logical flow diagram generally showing one embodiment of a process for sending a status of a user in a social network. Process 400 may also be performed by SSS 106 of FIG. 1.
Process 400 begins, after a start block, at block 402 where a social network is determined. In one embodiment, the social network may be determined based on information about a plurality of other social networks, including in the form of address books, buddy lists, user databases, or other lists of users. The information may be received over a network, for example, from a third-party, from a database, form an email server, IM server, or the like. The information about the plurality of other social networks may be used to combine into the determined social network. For example, a list of all interconnections between all members may be created from the information. In one embodiment, some of the plurality of other social networks may have members that are not in other ones of the plurality of social networks. For example, a user who intends to send a status may be in one of the social networks to be combined, while a recipient may be in a completely different social network to be combined. Processing then continues to block 404.
At block 404, a at least one recipient is subscribed to receive a status of a user in a social network. In one embodiment, the recipient may be a member of the social network. In one embodiment, the user may be in a contact list of the recipient. In one embodiment, the recipient may subscribe himself to receive the status of the user. For example, the recipient may indicate that the recipient wishes to receive a status of the user in the social network. The indication may be sent from an application program on a client device to a status sharing manager or the like. In one embodiment, the recipient may be allowed to receive the status if the user has indicated that the recipient should be allowed to receive the permission. In another embodiment, the user may subscribe the recipient to receive the status. In one embodiment, a table entry, database entry or the like, indicating that the recipient is to receive a status of the user is maintained, updated, or the like, based on the subscription. In one embodiment, when the recipient is subscribed, the recipient may also indicate the types of status that the recipient wishes to receive, the mode of delivery, or the like. Processing next continues to block 406.
A block 406, a status of the user is received over a channel. In one embodiment, a user inputs the status using a program, interface, or the like, on a client device. The user sends the status of the user over the channel to a server, such as SSS 106 of FIG. 1. In one embodiment, the channel may include an application program protocol. The channel may be associated with a particular network protocol, a particular application type for sending the status, an application type for receiving the status, a particular operating system or other platform information associated with the recipient of a status over the channel, or the like. Processing next continues to block 408.
At block 408, a recipient is selected from a plurality of recipients based on a membership in the social network. In one embodiment the plurality of recipients may be determined as those members of the social network who have subscribed to receive a status from the user. In one embodiment, the recipient may be selected based on a degree of separation between the recipient and the user in the social network. For example, the recipient may be one degree of separation from the user (e.g., the recipient is in the user's address book, buddies list, social network of friends).
In an alternate embodiment, the recipient may be selected (additionally) based on the type of status being sent, the content of the status being sent, the priority of the status being sent, or the like. For example, a message of an emergency type may be sent to all recipients, or recipients associated with an emergency care social network. In any case, processing next continues to block 410.
At block 410, another channel associated with the recipient is determined. In one embodiment, a recipient may be associated with a plurality of channels. For example, a user may have the recipient in a plurality of address books, buddy lists, or other list of users. Each list may be associated with a different channel for communicating with the users in the list. In one embodiment, the different channels associated with a recipient may be aggregated in the social network. For example, user A may have the recipient in an IM buddy list, but user B may have the recipient in an phone book on a user B′s mobile phone. Both the IM channel, and the phone channel (e.g., phone, SMS) may be associated with the recipient in the social network.
In any case, at least one of the other channel is selected to be used to send the status of the user to the recipient. In one embodiment, the selection of the other channel is based on an availability of the other channel. For example, the recipient may be actively using an application program (e.g., email, IM, logged into a social networking website). Therefore, the channel associated with the application program may be indicated as active.
In one embodiment, the other channel is different from the channel. For example, the user may send the status to the status sharing server over one application protocol (e.g., IM), but the other channel determined for the recipient is a different application protocol (e.g., email).
In an alternate embodiment, the other channel may also be based on the type of the status, content of the status, and/or priority of status. For example, a message of an emergency type and/or high priority may be determined to be sent over an emergency channel, such as over a VOIP and/or Private Branch Exchange (PBX) phone channel to the telephone number “9-1-1.” For example, a text message may be converted to voice using a text-to-voice conversion, and may use a PBX system such as Asterisk to connect to the “9-1-1” message to send the voice message and or any other relevant information, such as location, time, or the like associated with the device. Processing next continues to block 412.
At block 412, the status is modified based on the other channel. In one embodiment, the status may be received as a first type of media. The first type of media may be appropriate for sending over the channel. The status may be converted into second type of media appropriate for transmission and receipt over the other channel. For example, the status may be received as HTML over an HTTP channel. The status may be converted into plain text (e.g., removing tags). The plain text message may be sent over an SMS channel. The determination of the second type of media may be based on a variety of mechanisms and/or factors. For example, a media type may be associated with a channel type (e.g., a plain text type may be associated with SMS channel, an HTML type may be associated with an email channel, a voice type may be associated with a VOIP channel, a picture or image type may be associated with a channel enabled to send messages to a video enabled mobile device). In one embodiment, the status may be converted using a text-to-voice if the first media type is text, and the second media type voice. In one embodiment, the status may be converted using a voice-to-text if the first media type is voice, and the second media type text. Processing next continues to block 414.
At block 414, the status is modified based on a preference of the recipient. In one embodiment, the received at least one status may be modified from a received media type to another media type based on the preference. In one embodiment, the recipient may indicate that the recipient wishes to receive media of a particular type, status of a particular area of interest (e.g., status with the keywords “film”, or category of “film”), or the like. In one embodiment, the recipient may indicate that media of a particular type should be sent over a particular type of channel. For example, the recipient may indicate that the recipient wishes to receive voice statuses that was originally sent over a VOIP channel, but wishes to receive plain text sent over an SMS channel. In another example the recipient may wish to receive all status only over an IM channel, and thus statuses must be converted into a format suitable for IM (e.g., plain text, XML). In general, any number of rules, criteria, or conditions may be used to specify the preference. In one embodiment, the media types includes at least one of a text message type, a voice message type, an image type, a video type, or a multimedia type. In one embodiment, the at least one status is transcoded into a voice version of the at least one status. Processing next continues to block 416.
At block 416, the status is modified based on a relationship between the recipient and the user in the social network. In one embodiment, the at least one status is partitioned based on a relationship between the user and the recipient in the social network. In one embodiment, the at least one status may be filtered based on a membership of the recipient and/or the user in a group/community in the social network, a status of the message, or the like. For example, the at least one status may be a composite status of “at school/bored/math class/see my blog post about math,” wherein the character “/” represents a separator between statuses. Each of the status my be associated with one type, level of access, or the like. The composite status may be partitioned into “at school” for those recipients in a general community of the social network “at school/bored” for those recipients in a friends list, “at school/bored/math class” for those friends who are also in the same class with the user, and the like. Moreover, a recipient in a community about a special interest (e.g., “how to excel at math”) may receive only a particular type of message (e.g., “see my blog post about math”).
In one embodiment, the at least one status my be a hierarchical status, such as an ordered list, tree, or the like. The degree and/or specificity of the message may be based on a social network relationship (e.g., membership of recipient and/or user in the social network). For example, for the status “at school/bored/math class/see my blog post about math,” the status may be partitioned to a level of the hierarchy based on a degree of separation between. The relationship between the level of the hierarchy (e.g., the number of statuses and/or the degree of detail/specificity/privacy of the status) may be inversely related to the degree of separation. The level of the hierarchy may begin from the beginning of the hierarchy (e.g., a head node of a tree, the first status in a list, or the like). For example, for one degree of separation recipients, “at school/bored/math class/see my blog post about math” is sent; for two degrees “at school/bored/math class” is sent; for three degrees “at school/bored” is sent, or the like. Thus, in one embodiment, partitioning may comprise providing a level of the hierarchy of statuses based on the membership of the recipient in the social network.
In another embodiment, the user may specify that the status should also identify the channel over which the status was received, based on a relationship between the user and the recipient in the social network. For example, a recipient who is closely related to the user in the social network (e.g., with few degrees of separation between the two), may receive information to identify the channel. In any case, processing next continues to block 418.
At block 418, the status is modified based on information about a device to receive the status. In one embodiment, the information may be converted into a type of media appropriate for receipt by the device. For example, an HTML status sent by a user may be converted into WML before being sent to a mobile device. In another embodiment, the status may be converted to take into account the location of the device. The location may be based on a GPS coordinate sent from the device, an IP address of the device, or the like. The status may be converted into a language specific to the location based on a machine translation technique, for example. The status may convert time and/or date in the message into a local time for the device. The status may include a distance from the user who sent the status and the device's location based on a distance measure (e.g., Euclidian, Manhattan distance). Processing then continues to block 420.
At block 420, the status is sent to the recipient over the other channel. The status may be sent to the selected recipient using the specific protocol/mechanism particular to the channel. For example, an IM channel may use an IM client/forwarder to send the message over an IM protocol. In one embodiment, the message may be determined to be sent over a plurality of channels of the same type. For example, the message may be determined to be sent over a plurality of IM channels. In this case, the status may be sent using a multiplexed broadcasting or other multicasting mechanism, wherein the status is sent in parallel, in series, or the like. Combining the sending using a multiplexed broadcasting mechanism may reduce the overhead in initiating the protocol, converting the statuses from step 412 (e.g., the status is only converted once for the type of channel), or reduce other resource usages. In some embodiments, where the channel supports multicasting, the status may also be sent in parallel, using, for example IP multicasting, broadcasting, peercasting, or the like.
In one embodiment, sending the status over the other channel may be delayed until a status of the other channel is determined to be available. For example, the other channel may be a mobile device. The channel may determined to be available if the mobile device is activated, is within a certain range or the like. The status may not be sent until the channel is determined to be available.
In yet another embodiment, sending the status may including sending a history of statuses (e.g., the last N status), including the current status. In one embodiment, conflicting statuses may be filtered out based, for example, on a time of creation of the status. For example, a more recent mood status of “Happy” may override a more distant mood of “Sad.” The history of status may be sent to the recipient over the other channel as described above. In any case, processing then returns to a calling process for further processing.
In another embodiment, the status may be saved, logged, analyzed, or the like. The saved information may be used to determine suggestions of, for example, possible recipients for a status, a history of statuses, or the like. For example, at block 408, based on the content and/or type of the status and/or based on the user, a recipient who has received the same or similar type of status and/or received a status from the user in the past may be determined as a possible recipient. The status may be sent to the possible recipient based on, for example, whether the user has indicated that possible recipient or any possible recipients should receive the status, or based on whether the possible recipient has indicated that the possible recipient prefers to receive such a status. Processing then continues to block 410.
FIG. 5 illustrates another logical flow diagram generally showing one embodiment of a process for sending a status of a user in a social network. Process 500 may also be performed by client devices 101-104 of FIG. 1.
Process 500 begins, after a start block, at block 502 where an input of a status of a user in a social network is received. The input may be entered using an application program on a client device, such as one of client devices 101-104 of FIG. 1, for example. The user may enter text, multimedia, or the like to indicate the user's status. For example, if the user is sad, the user may select a sad face icon, may take a picture of the user's face, may record “I am sad,” or the like. The user may select a phrase, image, or the like from a selection list, pull-down list, or the like. The list may pre-populated with previous entries the user and/or members of the user's community has entered. In one embodiment, the information is associated with the user (e.g., the user's ID, the client device). In any case, after entry of the input, the input is received by the client device. Process next continues to block 504.
At block 504, a selection of a community in the social network is enabled. A list of the user's community may be presented on the client device. For example, a phone list may be provided to the user on a mobile device. In another embodiment, a graphical view of the social network showing, for example, hierarchical groups in the social network may be presented using, for example, a tree view, or the like. The user is enabled to select the appropriate community using a variety of mechanisms, including voice input, key entry input, touch screen input, or the like. Processing then continues to block 504.
At block 506, a recipient to receive the status is selected from the community. In one embodiment, the user is enabled to select at least one of the recipient from the selected community. For example, a contact list may be provided, and the user may be enabled to select the recipient from the list, using, for example, a scroll-and-select method, a touch screen input, a key entry input, or the like. In one embodiment, an identifier of the recipient is received by the client device. Processing next continues to block 508.
At block 508, the status is forwarded to the recipient over a plurality of channels, wherein at least one of the plurality of channels is associated with the recipient. In one embodiment, the status may be forwarded over a network to a server, over a first channel. The status channel may select at least one other channel, and may send the status to the recipient over the other channel. For example, the client device may send the status over an IM protocol, and the server (e.g., SSS 106) may send the status over an email/SMTP protocol to the recipient. The process for forwarding the status is described in more detail in process 400 of FIG. 4, above. In another embodiment, the client device may send the status directly to the recipient over a plurality of channels. For example, in one embodiment, the client device may also act as a status sharing server, and may select for example, an IM channel and an SMS channel. The client device may send the status to both channels. Processing then returns to a calling process for further processing.
It should be noted that while process 500 is described as operating on one recipient, process 500 may operate on a plurality of recipients without departing from the scope of the invention. For example, at block 504 a plurality of communities may be selected. At block 506, a plurality of recipients may be selected. At block 508, a status may be forwarded to a plurality of recipients over at least one channel. For example, the status may be sent to a server over an IM channel. The status may then be sent to a first and second recipient over an SMS channel. Processing then continues as described above.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6260148 *Jul 26, 1999Jul 10, 2001Microsoft CorporationMethods and systems for message forwarding and property notifications using electronic subscriptionsUS6501834 *Nov 21, 2001Dec 31, 2002At&T Corp.Message sender status monitorUS7120455May 20, 2004Oct 10, 2006Cellco PartnershipMethod and system for mobile instant messaging using multiple interfacesUS7272662 *Nov 30, 2001Sep 18, 2007Nms Communications CorporationSystems and methods for routing messages to communications devices over a communications networkUS7548756Aug 8, 2006Jun 16, 2009Cellco PartnershipMethod and system for mobile instant messaging using multiple interfacesUS7603111Jan 4, 2006Oct 13, 2009Lg Electronics Inc.System for mobile instant messaging service using mobile communication terminal and method thereofUS7730135Oct 29, 2007Jun 1, 2010Genesys Telecommunications Laboratories, Inc.Method and apparatus for intelligent routing of instant messaging presence protocol (IMPP) events among a group of customer service representativesUS7730143 *Dec 29, 2006Jun 1, 2010Aol Inc.Prohibiting mobile forwardingUS7752268 *Sep 25, 2003Jul 6, 2010Oracle America, Inc.Method and system for presence state assignment based on schedule information in an instant messaging systemUS7844055 *Jun 25, 2002Nov 30, 2010Link Us All, LlcDetecting and transporting dynamic presence information over a wireless and wireline communications networkUS7996467 *Aug 29, 2006Aug 9, 2011Oracle International CorporationTechniques for applying policies for real time collaborationUS20020024947 *Jul 26, 2001Feb 28, 2002Omer LuzzattiCommunications availabilityUS20020083136Dec 22, 2000Jun 27, 2002Whitten William B.Method of authorizing receipt of instant messages by a recipient userUS20030009530Sep 3, 2002Jan 9, 2003Laurent PhilonenkoInstant message presence protocol for facilitating communication center activityUS20040073643 *Oct 10, 2002Apr 15, 2004Hayes David J.Communication system for providing dynamic management of contacts and method thereforUS20040162881Apr 18, 2003Aug 19, 2004Digate Charles J.System and method for immediate and delayed real-time communication activities using availability data from and communications through an external instant messaging systemUS20050027669 *Jul 31, 2003Feb 3, 2005International Business Machines CorporationMethods, system and program product for providing automated sender status in a messaging sessionUS20050044143Aug 19, 2003Feb 24, 2005Logitech Europe S.A.Instant messenger presence and identity managementUS20050091329Nov 24, 2004Apr 28, 2005Neoplanet, Inc.Messaging system for indicating status of a sender of electronic mail and method and computer program product thereforUS20050117570 *Jan 3, 2005Jun 2, 2005Zoran CetusicWireless communication techniquesUS20050153724 *Jan 12, 2004Jul 14, 2005Vij Gajinder S.Method and apparatus for sharing user information in a group communication networkUS20050235035 *Apr 15, 2004Oct 20, 2005International Business Machines CorporationCommunication status management system and methodUS20060031234 *Feb 10, 2005Feb 9, 2006Brodi BeartuskSystems and methods for a collaborative group chatUS20060265463 *Aug 4, 2006Nov 23, 2006Elan AmirSystems and methods for remotely updating e-mail message status information for messages forwarded from a host system e-mail account across a firewall to a wireless handheld deviceUS20060271696Aug 8, 2006Nov 30, 2006Cellco Partnership D/B/A Verizon WirelessMethod and system for mobile instant messaging using multiple interfacesUS20070143472 *Dec 21, 2005Jun 21, 2007International Business Machines CorporationMethod for improving the efficiency and effectiveness of instant messaging based on monitoring user activityUS20070198725 *Oct 6, 2004Aug 23, 2007Morris Robert PSystem and method for utilizing contact information, presence information and device activityUS20070226357 *Mar 22, 2006Sep 27, 2007Mcmurry Kathleen AProviding an Aggregate Reachability StatusUS20070293212Jun 15, 2007Dec 20, 2007Neltura Technology, Inc.System and methods for using online community identities of users to establish mobile communication sessionsUS20080132259Dec 5, 2007Jun 5, 2008Eric VinSystem and method of providing access to instant messaging services via a wireless networkUS20080141138 *Dec 6, 2006Jun 12, 2008Yahoo! Inc.Apparatus and methods for providing a person's statusUS20080153531 *Dec 22, 2006Jun 26, 2008Palm, Inc.Presence Engine and a Method of Operating a Presence Engine for Encoding or Decoding Availability Status into a Signal Representative of an Audio SignalUS20080153538 *Dec 22, 2006Jun 26, 2008Palm, Inc.Terminating Device and a Method of Operating a Terminating Device Configured to Communicate Availability Status Directly Between Terminating DevicesUS20080155080 *Dec 22, 2006Jun 26, 2008Yahoo! Inc.Provisioning my status information to others in my social networkUS20080155567 *Dec 22, 2006Jun 26, 2008Palm, Inc.Data Processing Apparatus and a Method of Operating Data Processing Apparatus for Generating Representations of Availability Status for Application ProgramsUS20080261630 *Apr 23, 2007Oct 23, 2008Research In Motion LimitedIndicating user presence on a messaging networkUS20090063467Aug 30, 2007Mar 5, 2009Fatdoor, Inc.Persona management in a geo-spatial environmentUS20090117936 *Oct 24, 2008May 7, 2009Samsung Electronics Co. Ltd.Method and mobile terminal for displaying terminal information of another party using presence informationUS20090119400 *Jul 30, 2008May 7, 2009Kabushiki Kaisha ToshibaPresence Management SystemUS20090186638Jun 29, 2007Jul 23, 2009Hye-Won YimApparatus and method for providing mobile instant messaging serviceUS20090234922 *Nov 30, 2005Sep 17, 2009Aol LlcAutomatically Enabling the Forwarding of Instant MessagesUS20090276436Nov 5, 2009Nokia CorporationMethod, apparatus, and computer program product for providing service invitationsUS20100009664 *Jul 11, 2008Jan 14, 2010Telefonaktiebolaget Lm Ericsson (Publ)Methods, telecommunications node, and user equipment for transmission of user identifierUS20100056109Mar 4, 2010Research In Motion LimitedMethod, system and apparatus for messaging between wireless mobile terminals and networked computersUS20100151845 *Dec 15, 2008Jun 17, 2010Rountree Collin LegaultPresence based communication controlUS20100177812 *Jul 15, 2010Palm, Inc.Managing availability status in a communications networkUS20100203900 *Nov 16, 2009Aug 12, 2010Sony CorporationHandheld electronic deviceUS20100205267Apr 20, 2010Aug 12, 2010Research In Motion LimitedInstant Messaging Device/Server ProtocolUS20100211604Jan 18, 2008Aug 19, 2010Alistair James CampbellFacilitating Arrangement in a Communication SystemUS20100228582Mar 6, 2009Sep 9, 2010Yahoo! Inc.System and method for contextual advertising based on status messagesUS20100262661Apr 9, 2009Oct 14, 2010Research In Motion LimitedMethod and system for establishing a presence context within a presence platformUS20110040844Feb 17, 2011Cisco Media Solutions, Inc.Communication Systems and Methods with Social Network FilteringUS20110041063 *Feb 17, 2011Byoung Wook LeeMethod and apparatus for providing social network serviceUS20110059727 *Sep 10, 2009Mar 10, 2011Michael-Anthony LisboaSimple Mobile Registration: A mechanism enabling people to use electronic mobile devices and their messaging capabilities-instead of the traditionally used personal computer-to sign-up or register in real time for access to services and applications delivered via mobile devicesUS20110143724 *Jun 16, 2011Michael ZubasAlternate Voicemail Deposit Notification for Roaming Mobile DevicesUS20110171934 *Jul 6, 2009Jul 14, 2011Sk Telecom Co., Ltd.Method of providing communication function for communication group, and mobile communication terminal and presence server for the sameUS20110289149Nov 24, 2011Technion Research & Development Foundation Ltd.Methods and systems for managing a multi participant eventUS20120046029 *Aug 20, 2010Feb 23, 2012Dany SylvainMethod for performing configurable actions based upon mobile device detection* Cited by examinerNon-Patent CitationsReference1"Add Online Presence to Your Web Pages", Yahoo! Messenger, 2008, (1 page).2"Dodgeball.com: Get Started", Dodgeball.com, 2008, (2 pages).3"What is Twitter?", Twitter.com, 2008 (3 pages).4"What is Twitter?: FAQ", Twitter.com, 2008, (2 pages).5"Your First Time on imood.com", imood.com, Jun. 13, 2008, (2 pages).6Non-Final Office Action for U.S. Appl. No. 11/615,920, Oct. 6, 2010.7Office Communication for U.S. Appl. No. 11/615,920, mailed Mar. 11, 2011.8Office Communication for U.S. Appl. No. 11/615,920, mailed Sep. 21, 2011.9Official Communication for U.S. Appl. No. 11/615,920 mailed Mar. 26, 2012.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8762472 *Aug 15, 2013Jun 24, 2014Wetpaint.Com, Inc.Personalization based upon social value in online mediaUS8856228Nov 30, 2009Oct 7, 2014The Invention Science Fund I, LlcSystem and method for comparison of physical entity attribute effects on physical environments through in part social networking service inputUS8856238 *Feb 9, 2012Oct 7, 2014Microsoft CorporationRepresenting remotely available users through working elsewhere statusUS8984082Jun 23, 2014Mar 17, 2015Wetpaint.Com, Inc.Personalization based upon social value in online mediaUS9083794 *Jul 17, 2012Jul 14, 2015Yahoo! Inc.Provisioning my status information to others in my social networkUS20110125842 *May 26, 2011Searete Llc, A Limited Liability Corporation Of The State Of DelawareSystem and method for comparison of physical entity attribute effects on physical environments through in part social networking service inputUS20110283180 *Nov 17, 2011Yoshihiro SuzukiCommunication method, information terminal apparatus, display apparatus, and communication system comprising theseUS20120284338 *Nov 8, 2012Yahoo! Inc.Provisioning my status information to others in my social networkUS20130212252 *Feb 9, 2012Aug 15, 2013Microsoft CorporationRepresenting remotely available users through working elsewhere statusUS20140067953 *Aug 15, 2013Mar 6, 2014Wetpaint.Com, Inc.Personalization based upon social value in online media* Cited by examinerClassifications U.S. Classification455/466, 379/88.17, 709/207, 709/206, 455/412.1, 379/88.13, 709/223International ClassificationH04L12/58, G06F15/16Cooperative ClassificationH04M2203/655, H04M2203/4536, H04M3/5322, H04M3/42374, H04L43/0817, H04L12/581, H04L12/66, H04L51/04, H04L67/24European ClassificationH04L12/58B, H04L12/66, H04M3/42S2, H04M3/53T, H04L51/04Legal EventsDateCodeEventDescriptionMay 7, 2012ASAssignmentOwner name: YAHOO! INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MARLOW, CAMERON;SAMPLE, NEAL;KALABOUKIS, CHRIS;SIGNING DATES FROM 20061220 TO 20061222;REEL/FRAME:028167/0770Sep 4, 2012CCCertificate of correctionRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services