US20150229683A1

Movatterモバイル変換

Info

Publication number: US20150229683A1
Application number: US14/695,510
Authority: US
Inventors: Harold Alan Liss; Ryo Chijiiwa
Original assignee: Yahoo Inc until 2017
Current assignee: Excalibur IP LLC; Altaba Inc
Priority date: 2007-09-11
Filing date: 2015-04-24
Publication date: 2015-08-13
Also published as: US20090070286A1; US9037970B2

Abstract

A social network site with enhanced user interaction functionality. In one implementation, a method includes providing a personal page corresponding to a first user, wherein the personal page includes a digital pet module region comprising a representation of an animate object, an indicator of a current state of the animate object, an action selector control, and an action history comprising a user identifier of a previous user and an action selected by the previous user using the action selector control; receiving an indication of a selected action from a current user; modifying the state of a digital pet object based on the selected action; and causing a browser client to render the digital pet module region, the modified state, and an updated action history including an identification of the current user and the action selected by the user.

Description

TECHNICAL FIELD

The present disclosure generally relates to social network sites.

BACKGROUND

Interactive systems connected by wide area networks, such as the Internet, have steadily evolved into vibrant mediums for social interaction. For example, social network sites are fast growing phenomena that provide an interactive medium through which users can grow a network of friends for sharing personal information, as well as for exchanging digital media such as music and videos. Social network sites have become an increasingly influential part of contemporary popular culture around the world. A social network site focuses on the building and verifying of online social networks for communities of people who share interests and activities, or who are interested in exploring the interests and activities of others. Most social network services are primarily web based and provide a collection of various ways for users to interact, such as chat, messaging, email, video, voice chat, file sharing, blogging, discussion groups, and the like.

In general, social networking services, such as MySpace, Facebook and Bebo, allow users to create a profile for themselves. Users can upload a picture of themselves and can often be “friends” with other users. In most social network sites, both users must confirm that they are friends before they are linked. For example, if Alice lists Bob as a friend, then Bob would have to approve Alice's friend request before they are listed as friends. Some social network sites have a “favorites” feature that does not need approval from the other user. Social networks usually have privacy controls that allow the user to choose who can view their profile or contact them. In connection with social network sites, users typically create personalized web pages that display personal information about the users (e.g., name, age, gender, location, etc.). The user may include text, images, photos, and other content to share with other users. The user may periodically add or change content to the personalized web page after it is created.

SUMMARY

The present invention provides a method, apparatus, and systems directed to a social network site with enhanced user interaction functionality. In particular implementations, the present invention provides interactive digital objects that facilitate or stimulate user interaction within a social network site. In one implementation, the social network site provides a pet module. When invoked, the pet module renders an object that is a representation of a living being (e.g., a pet) in a pet module region. In particular implementations, the pet module facilitates social interaction with one another's personal pages by allowing users to interact with the pet. In another implementation, the social network site provides a semi-autonomous digital object that attaches itself to a personal page profile. In a particular implementation, the semi-autonomous digital object manifests itself as a hot potato that obscures one or more regions of a user's personal page. When invoked, the hot potato module renders an object that is a representation of a potato. In particular implementations, the hot potato module facilitates social interaction with one another's personal pages by allowing users to throw the hot potato to other users.

DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example network environment in which particular implementations may operate.

FIG. 2 illustrates an example computing system architecture, which may be used to implement a physical server.

FIG. 3 illustrates example social network site components which may be used to implement particular functionalities described herein.

FIG. 4 illustrates an example personal page.

FIG. 5 illustrates an example data table.

FIG. 6 illustrates an example key table for a given user.

FIG. 7 illustrates an example permission table for a given user.

FIG. 8 illustrates an example process flow associated with creating a personal page.

FIG. 9A illustrates an example process flow associated with modifying a personal page using Asynchronous JavaScript and XML (Ajax).

FIG. 9B illustrates an example process flow associated with modifying a personal page without using Ajax.

FIG. 10 illustrates an example page for setting permissions of a user profile.

FIG. 11 illustrates a process flow associated with setting permissions.

FIG. 12 illustrates an example page showing a revision history for a particular user.

FIG. 13 illustrates an example page showing details of changes made by particular users.

FIG. 14 illustrates a process flow associated with displaying a revision history.

FIG. 15 illustrates an example page showing updates from all of the contacts of a given user.

FIG. 16 illustrates a process flow associated with displaying a revision history.

FIG. 17 illustrates a user interface including an example interactive digital pet object.

FIG. 18 illustrates a user interface including showing an example interactive pet object and an action selector control.

FIG. 19 illustrates a process flow associated with invoking a pet module.

FIG. 20 illustrates a page showing an example semi-autonomous hot potato.

FIG. 21 illustrates a page showing an example hot potato and trail of ashes information.

FIG. 22 illustrates a process flow associated with a decision to transfer a hot potato.

FIG. 23 illustrates a process flow associated with transferring a hot potato.

DESCRIPTION OF EXAMPLE EMBODIMENTSA. Example Network System ArchitectureA.1. Example Network Environment

FIG. 1 illustrates an example network environment in which particular implementations may operate. Particular implementations of the invention operate in a wide area network environment, such as the Internet. AsFIG. 1 illustrates, a particular implementations of the invention may operate in a network environment comprising asocial network site20 that is operatively coupled to anetwork cloud60.Network cloud60 generally represents one or more interconnected networks, over which the systems and hosts described herein can communicate.Network cloud60 may include packet-based wide area networks (such as the Internet), private networks, wireless networks, satellite networks, cellular networks, paging networks, and the like.

Client nodes

82 and84 are operably connected to the network environment via a network service provider or any other suitable means.

Client nodes

82 and84 may include personal computers or cell phones, as well as other types of mobile devices such as lap top computers, personal digital assistants (PDAs), etc.

Social network site

20 is a network addressable system that hosts a social network application accessible to one or more users over a computer network. The social network application may include web site and server functionality where users may request and receive identified web pages and other content over the computer network. The social network application may also allow users to configure and maintain personal web pages.

In particular implementations,social network site20 comprises one or morephysical servers22 and one or more data stores24. The one or morephysical servers22 are operably connected tocomputer network60 via arouter26. The one or morephysical servers22 host functionality that allows users to interact with the social network, such as uploading and retrieving content from

client nodes

82 and84. In one implementation, the functionality hosted by the one or more physical servers may include web or HTTP servers, FTP servers, and the like.

Physical servers

22 also host functionality directed to asocial network site20 described herein. In one implementation, adata store24 may store user account information, including core information such as user identifiers, passwords, names, etc., as well as other user related information such as user profile data, addresses, preferences, financial account information, pointers to uploaded content and pointers to one or more modules for processing content, etc. A givendata store24 may also store content such as digital content data objects and other media assets. A content data object or a content object, in particular implementations, is an individual item of digital information typically stored or embodied in a data file or record. Content objects may take many forms, including: text (e.g., ASCII, SGML, HTML), images (e.g., jpeg, tif and gif), graphics (vector-based or bitmap), audio, video (e.g., mpeg), or other multimedia, and combinations thereof. Content object data may also include executable code objects (e.g., games executable within a browser window or frame), podcasts, etc. Structurally,content data store24 connotes a large class of data storage and management systems. In particular implementations,content data store24 may be implemented by any suitable physical system including components, such as database servers, mass storage media, media library systems, and the like.

A.2. Example Server System Architecture

The server host systems described herein may be implemented in a wide array of computing systems and architectures. The following describes example computing architectures for didactic, rather than limiting, purposes.

FIG. 2 illustrates an example computing system architecture, which may be used to implement a physical server. In one embodiment, hardware system200 comprises aprocessor202, acache memory204, and one or more software applications and drivers directed to the functions described herein. Additionally, hardware system200 includes a high performance input/output (I/O) bus206 and a standard I/O bus208. Ahost bridge210

couples processor

202 to high performance I/O bus206, whereas I/O bus bridge212 couples the two buses206 and208 to each other. Asystem memory214 and a network/communication interface216 couple to bus206. Hardware system200 may further include video memory (not shown) and a display device coupled to the video memory.Mass storage218, and I/O ports220 couple to bus208. Hardware system200 may optionally include a keyboard and pointing device, and a display device (not shown) coupled to bus208. Collectively, these elements are intended to represent a broad category of computer hardware systems, including but not limited to general purpose computer systems based on the x86-compatible processors manufactured by Intel Corporation of Santa Clara, Calif., and the x86-compatible processors manufactured by Advanced Micro Devices (AMD), Inc., of Sunnyvale, Calif., as well as any other suitable processor.

The elements of hardware system200 are described in greater detail below. In particular,network interface216 provides communication between hardware system200 and any of a wide range of networks, such as an Ethernet (e.g., IEEE 802.3) network, etc.Mass storage218 provides permanent storage for the data and programming instructions to perform the above described functions implemented in thelocation server22, whereas system memory214 (e.g., DRAM) provides temporary storage for the data and programming instructions when executed byprocessor202. I/O ports220 are one or more serial and/or parallel communication ports that provide communication between additional peripheral devices, which may be coupled to hardware system200.

Hardware system200 may include a variety of system architectures; and various components of hardware system200 may be rearranged. For example,cache204 may be on-chip withprocessor202. Alternatively,cache204 andprocessor202 may be packed together as a “processor module,” withprocessor202 being referred to as the “processor core.” Furthermore, certain embodiments of the present invention may not require nor include all of the above components. For example, the peripheral devices shown coupled to standard I/O bus208 may couple to high performance I/O bus206. In addition, in some embodiments only a single bus may exist, with the components of hardware system200 being coupled to the single bus. Furthermore, hardware system200 may include additional components, such as additional processors, storage devices, or memories.

As discussed below, in one implementation, the operations of one or more of the physical servers described herein are implemented as a series of software routines run by hardware system200. These software routines comprise a plurality or series of instructions to be executed by a processor in a hardware system, such asprocessor202. Initially, the series of instructions may be stored on a storage device, such asmass storage218. However, the series of instructions can be stored on any suitable storage medium, such as a diskette, CD-ROM, ROM, EEPROM, etc. Furthermore, the series of instructions need not be stored locally, and could be received from a remote storage device, such as a server on a network, via network/communication interface216. The instructions are copied from the storage device, such asmass storage218, intomemory214 and then accessed and executed byprocessor202.

An operating system manages and controls the operation of hardware system200, including the input and output of data to and from software applications (not shown). The operating system provides an interface between the software applications being executed on the system and the hardware components of the system. According to one embodiment of the present invention, the operating system is the Windows® 95/98/NT/XP/Vista operating system, available from Microsoft Corporation of Redmond, Wash. However, the present invention may be used with other suitable operating systems, such as the Apple Macintosh Operating System, available from Apple Computer Inc. of Cupertino, Calif., UNIX operating systems, LINUX operating systems, and the like. Of course, other implementations are possible. For example, the server functionalities described herein may be implemented by a plurality of server blades communicating over a backplane.

A.3. Example Social Network Site Functionality

FIG. 3 illustrates example functional components of a social network site which may be used to implement particular functionalities described herein. Thesocial network site20 components include apage creator302, amodule executer304 operatively coupled to adata store306, acontact manager308 operatively coupled to adata store310, and a Hypertext Transfer Protocol (HTTP) server.

As described in more detail below,page creator302 generates personal pages for users based on layout information (e.g., user profile information, etc.) and a base template. Layout information is described in more detail below in connection withFIG. 4. Themodule executer304 is configured to access modules (e.g., from data store306) and execute one or more modules in order to obtain module information from local resources such asdata store306, from separate platforms such ascontact manager308, or from one or more remote resource.Contacts manager308 manages the relationships for the users of thesocial network site20, and may perform contact related functions such as accessing friend lists, contact lists, and/or presence information fromdata store310 or from other external data sources.

In particular implementations, each module is a functional software program (e.g., code, code objects, application, etc.) that themodule executer304 may invoke to obtain module information. For example,module executer304 may execute a contacts module that communicates withcontact manager308 to fetch contact information for a given user. Such contact information may include, for example, who is viewing the personal page of the user or who is currently on-line. As described in more detail below,module executer304 may execute other modules such as media player modules, revision history modules, blurt modules, video game modules, photo modules, conversation modules, etc.

AlthoughFIG. 3 illustrates the foregoing components as separate systems, the functionality represented by each component may be combined into other systems. Furthermore, the functionality represented by each depicted component may be further separated. Still further, implementations of the invention may operate in network environments that include multiples of one or more of the individual systems and sites disclosed herein. In addition, other implementations may operate in network environments where one or more of the system described herein have been omitted.

B. Managing Access to the Social Network Site

In one implementation, a user may access thesocial network site20 and establish a user account. To establish an account, the user provides a set of core information, which, in one implementation, may include profile data such as user identification (ID), a password, name, gender, age, a location, etc. In particular implementations, the name may include a first name, a last name, alias name, etc. As described in more detail below, once an account is established, some of the core information (e.g., name, gender, age, location, etc.) may be displayed to the public on the personal page of the user. In particular implementations, the core information may be stored in adata store24 or in any other suitable user account database(s). After an initial authentication, the user may be granted subsequent accesses automatically using cookie-based mechanisms. For example, after a user has been authenticated,social network site20 may create or update an encrypted cookie and provide it to the client application, such as a browser, that the user is using to access thesocial network site20. The cookie is automatically appended to subsequent requests, which the social network site can decrypt and authenticate to validate subsequent accesses.

In one implementation, thesocial network site20 may authenticate a given user by requiring the user to provide user-unique information such as a user ID and password, which maps to the user account. In particular implementations, the user ID may be authenticated using various types of authentication mechanisms (e.g., Yahoo ID and password, Open ID, Microsoft Passport, etc.). The social network ID may be any data string such as an email address (e.g., a Yahoo! email address), an existing or new user ID (e.g., Yahoo ID (YID)), open ID (e.g., a Uniform Resource Locator (URL)), etc.

In one implementation, thesocial network site20 may utilize one level of identity (e.g., user ID and password) for purposes of authentication. In particular implementations, thesocial network site20 may allow other users to create stub-accounts for new users and invite them to join. In one implementation, a stub-account may be a temporary account that a new user may convert into a regular user account if the new user accepts the invitation to join. For example, in one implementation, thesocial network site20 may set up stub-accounts for new users, where a given user may be identified by an email address until the user logs in and claims the stub-account. In one implementation, the original social network ID (e.g., email address) may be subsequently replaced with a newly created social network ID (e.g., a Mosh ID (MUID)). As such, the user may access the social network using the new social network ID. In particular implementations, each previous social network ID of the user may become an alias ID for the current social network ID. In other words, the profile data of the user may be associated with an email or any other suitable data string. As such, the owner of the personal page as well as trusted users may still access the personal page of the owner using the alias ID. Also, other users may locate the owner or send the owner messages or invitations using the alias ID (e.g., email address).

C. Example Personal Page

As introduced above,social network site20 provides personal pages for users and applies wiki-based technology to enable other users to modify the personal page of a given user. As described above, wiki functionality, generally, enables a given webpage to be collaboratively modified and edited by multiple users. In particular implementations, the only users other than the owner of the personal page that may modify the personal page of the owner are trusted users. In a particular implementation, the owner of the personal page approves the trusted users. In another implementation, the owner of the personal page may define one or more rules that automatically define a trusted user.

C.1. Elements of the Personal Page

FIG. 4 illustrates the components of an example personal page. AsFIG. 4 illustrates, apersonal page400 includes acore information region402 and one or

more module regions

404,405,406,408, and410. As indicated above, thecore information region402 displays core information, which, in one implementation, may include profile data such as user identification (ID), a password, name, gender, age, a location, etc. In one implementation, the displayed module regions404-410 can be generated bymodule executor304. For example,module executor304 may be passed a command identifying a user ID, and a module identifier (such as a core information module). Themodule executor304 may then invoke module code or retrieve a script and construct the information to be displayed as a set of HTML code. The generated HTML code may then be returned topage creator302 for incorporation in the HTML page returned to the requesting user.

Each module region404-410 may display information unique and/or specific to the module type. For example, onemodule region404 may display a blurt, which is a statement (e.g., word or phrase of the day) that the owner may write. In particular implementations, trusted users may edit the owner's blurt, and the owner may approve or reject the edit. In one implementation, the blurt module may display a blurt trail showing the different blurts associated with a given owner. In one implementation, the blurt module may display a blurt aggregation page showing the blurts of all contacts. Anothermodule region405 may display a pet module region showings an interactive digital pet. When invoked, a pet module renders an object that is a representation of an animated object (e.g., a pet) in a pet module region. As described in more detail below in connection withFIGS. 17-19, the pet module facilitates social interaction among users by providing a structured mechanism by which users can interact by allowing users to select an action from an action menu to be applied to the digital pet.

Anothermodule region406 may display a media player for playing a selected media file or media file play list including music, videos, etc. Anothermodule region408 may display a revision history log. Anothermodule region410 many display a slideshow of digital photographs uploaded by the page owner. As described in more detail below, the module regions404-410 display information based on modules. In particular implementations, a module may be code sections, code objects, applications, scripts, etc. that include computer-readable instructions operable to cause a processor to perform a set of actions. Using a player module as an example, the player module may cause a processor to fetch and play music from a local or internal source. The player module may provide user controls on a player displayed in the player module region (e.g., module region404).

C.2. Generating and Modifying a Personal Page

As described in more detail below, the owner and trusted users may modify the personal page of the owner by adding or removing modules, moving module locations, and/or by modifying information in regions of existing modules. Thesocial network site20 performs the changes by updating one or more data structures, such as table entries that describe various attributes of the module information associated with the owner of the personal page. For example, in particular implementations, thesocial network site20 may utilize a data table that stores user associated data (e.g., user profile data), a key table for looking up information in the data table based on keys, and a permission table for storing permissions.

C.2.a. Data Table

FIG. 5 illustrates an example data table. AsFIG. 5 shows, the data table includes multiple table entries, each including information directed to one or more attributes of a personal page or a module associated with a personal page. In one implementation, the first column shows owner fields. For ease of illustration, the data table shown inFIG. 5 shows a single owner. As such, the data in the same row of the indicated owner is associated with the personal page of that owner. The data table may include other entries associated with the owners of other personal pages. Alternatively, in particular implementations, a unique data table may be partitioned from each owner.

In one implementation, the data table may include editor fields, which show which user has modified or attempted to modify the personal page of the owner (i.e., the other fields of that row). AsFIG. 5 shows the editor may be the owner or other users. As described above, in one implementation, the only users, other than the owner who may modify the personal page of the owner, are trusted users that have been approved or otherwise configured by the owner (e.g., friends, family, etc.).

AsFIG. 5 shows, the data table also includes key fields that store keys, which are strings corresponding to some information item. The value fields store values of information associated with particular keys. The time stamp fields indicate the time a given entry was added. The status fields indicate whether or not the owner has approved or rejected a given change, or whether the entry is obsolete. The difference fields store other information such as metadata or edits that may be associated with a given module. A given data field may also be null or empty for some module fields, depending on the specific module to which the entry corresponds.

In particular implementations, modifications made by users to a given personal page may result in one or more entries in the data table and/or key table. For example, referring to the first or top row, an owner “S” is the user who owns the personal page being changed, and editor “R” is the user making the changes to that personal page. The key that was changed (or added) is “Candy”, and the value of “Candy A” associated with that key at time “1.” As a subsequent time, referring to the second row from the top, editor “W” changed the value associated with the same key “Candy” to “Candy B” at time “2.” As shown in the status field, owner “S” has approved the change. As such, the status field indicates “Approved.” In one implementation, once the owner has approved a given change, any previous entries become obsolete, as indicated in the status field of the first row. In one implementation, before a given change is approved or rejected, the status field indicates “Pending.”

If the owner rejects a give change, the status field will indicate “Rejected.” In one implementation, if a given change is rejected, the associated module region will show the previously approved value or no value if none has been approved. In one implementation, if a given entered value is deemed inappropriate either by the user or by policy, the change will not be initiated and the status field will indicate “Rejected.”

FIG. 5 shows other example keys such as a pet key, photo key, and layout key. As described in more detail below, the data table may be utilized to add or remove modules from a personal page. This is achieved by adding a new entry to the data table. In one implementation, the value field associated with the key “Layout” stores data indicating which specific modules are to be displayed on a personal page, where the module regions are to be positioned in the personal page, and where other associated information is to be positioned within the module region.

C.2.b. Key Table

FIG. 6 illustrates an example key table for a given user. AsFIG. 6 shows, the data table includes owner fields, key fields, label fields, and module fields. In one implementation, the label fields indicate the label that will be displayed (e.g., “Candy”), and the module fields indicate the module IDs of the modules associated with the key. In particular implementations, the fields of the key table are customizable fields. As such, key tables for different users have different fields, depending on the modules associated with the keys.

C.2.c. Permission Table

FIG. 7 illustrates an example permission table for a given user. AsFIG. 7 shows, the data table includes owner fields, action fields, and setting fields. In one implementation, a given owner field may identify the ID of the user whose profile the settings are for. In one implementation, a given action field may specify the type of operations users can perform on the page and may specify one or more potential target actions (e.g., “edit module A,” “view module B,” etc.). In one implementation, a given setting field may contain a value that represents a class of users who can perform the action(s). In particular implementations, values for settings may include “friends,” “only me,” “anyone,” or categories of friends such as “friends” or “family.”

The following process flows describe various implementations involving the data table, key table, and permission table, and describe how the social network site utilizes information in these tables to enable users (e.g., a given owner and trusted users) to create and modify a personal page.

In one implementation, the owner of a page can add someone as a friend, which confers editing permission on that person for the owner's personal page under the default settings of one implementation of the system. The friend can then return and edit the owner's personal page. After the friend has edited the owner's personal page, the owner can reject or approve the change. If approved, the change stays present. If rejected, the change is removed from the owner's profile. The primary affordance for approving or rejecting changes is a revision history page for the owner's profile, which is described in more detail below in Section D (Revision History Module). In a given implementation, permission can be toggled on or off for any given friend. In particular implementations, only friends can have permission to edit any owner's page. That is, anonymous, non-friend users cannot edit an owner's page.

C.3. Creating a Personal Page

FIG. 8 illustrates an example process flow associated with constructing a personal page in response to a user request. AsFIG. 8 shows, thepage creator302 receives a request for a personal page (802). In one implementation, the request may include an owner ID corresponding to the owner of the personal page, and a requestor ID. In one implementation, the requestor ID may be the social network ID of the user requesting the personal page. In one implementation, the requestor may be the owner of the personal page. In particular implementations, the requestor may be a user who is creating the personal page for another user. Thepage creator302 then checks the permission associated with the request (804). In one implementation, if the requesting user does not have viewing permissions, a generic layout may be used instep808 below.

Thepage creator302 then accesses layout information (806). The layout information is an encoded string that encodes layout information associated with the personal page. The layout information may include one or more module identifiers and region identifiers encoded using JavaScript Object Notation. In one implementation, the layout information is defined relative to a base template. For example, the base template may include several pre-defined regions, such as quadrants and upper and lower regions. The layout information may define which modules are to be displayed in which base template region.

To access layout information,page creator302 searches the key table for the layout entries corresponding to the owner of the personal page. As discussed above, as modifications are made, additional table entries are added. In one implementation, thepage creator302 identified all matching table entries including the layout key and finds the latest entry that has not been rejected by the personal page owner. In a particular implementation, aspage creator302 andmodule executor304 retrieve data from the data table it stores the entries in a cache to facilitate fast access for subsequent requests. For example, for a given owner, thepage creator302 can obtain all of the associated keys, labels, and modules from the key table. Based on the keys, thepage creator302 can obtain all of the values and other pertinent information from the data table. Thepage creator302 then performs calculations such as sorting the data entries by key, identifying latest versions, etc. Thepage creator302 then segregates data entries by module, referring to key table, and then caches the module relations, values, etc.

Thepage creator302 then constructs the personal page based on the layout information and a base template (808). To perform this step, in one implementation, thepage creator302 causes themodule executer304 to execute one or more modules identified in the encoded layout information associated with each module. In particular implementations, execution of different types of modules results in the generation of HTML, scripts, and/or other code sections for inclusion in the page returned to the requesting user. For example, one module may return user contacts information. Another module may fetch conversation threads. Another module may fetch player information, etc. In particular implementations, the information may be retrieved from local sources (e.g., from

local databases

306,310, etc.) or from external sources (e.g., a web service). A contacts module may fetch user profile data such as contacts, etc., via the contact manager. After the modules generate resulting code sections, they pass the code sections to thepage creator302. After thepage creator302 receives the information, thepage creator302 merges the code section information with a base template. Thepage creator302 then returns the personal page to the client of the owner via HTTP server312 (810).

C.4. Modifying a Personal Page

FIG. 9A illustrates an example process flow associated with modifying a personal page using Asynchronous JavaScript and XML (Ajax) technology. Ajax is a web development technique used for creating interactive web applications. Ajax enables web pages to feel more responsive to users by exchanging small amounts of data with a server that performs database transactions behind the scenes. As such, the entire web page need not be reloaded or re-rendered each time the user requests a change. Overall, this increases the interactivity, speed, functionality, and usability of a web page.

In particular implementations, modules and personal page functionality have client-side scripts, such as Ajax scripts, that allow the modules to be modified on the client side. Ajax enables a user to quickly modify content in a given module region. When a user changes one or more attributes of the personal page, an Ajax script transmits data characterizing the change tosocial network site20. When a given change is finalized, Ajax receives a status and implements code to carry out the change, which may include adding HyperText Markup Language (HTML) code to the module region and rerendering the relevant portions of the module region. In addition, the modification also results in a new data table and/or key table entry.

AsFIG. 9A shows, theHTTP server312 receives a modification request (902) resulting from execution of an Ajax script embedded in the personal page. In one implementation, the modification request includes an editor ID, owner ID, module ID, module specific parameters characterizing the modification, etc. Thepage creator302, responsive to the request, causes themodule executer304 to invoke the appropriate module or code (904). In one implementation, if the requestor is not the owner of the personal page, themodule executer304 performs a permission check, referring to the permission table. For example, themodule executer304 may determine whether the requestor is a trusted user. In particular implementations, different modules require different permission checks. Permission checks are described in more detail below in connection withFIG. 11. If the requestor has the permission to make the change, themodule executer304 performs the requested change (e.g., add or remove a module, edit information in an existing module region, etc.). In a particular implementation, themodule executor304 also adds a new data table and/or key table entry for the modification. As discussed above, each entry includes the owner of the page, the editor, a key, a value, a time stamp, and optionally other information. Thepage creator302 returns a status message to the client (906). On the client side, Ajax code carries out the modification in the appropriate module region of the personal page in response to receiving the status code. In one implementation, thepage creator302 sends an HTML code snippet to the client, and the Ajax code appends the HTML code to an existing element on the personal page, or replaces the HTML code of the existing element.

FIG. 9B illustrates an example process flow associated with modifying a personal page without using Ajax. TheHTTP server312 receives an HTTP request requesting the modification (901)

Steps

902 and904 ofFIG. 9B are similar to

steps

902 and904 ofFIG. 9A, where the HTTP server then receives a modification request (902), and themodule executer304 invokes the appropriate module or code (904). The HTTP server then redirects the browser back to the personal page, which is re-rendered with the new information (907).

C.5. Setting Permissions

In one implementation, the owner of a given personal page may determine what aspects of the personal page may be viewed or edited, and by whom. In one implementation, only the owner may modify core profile information.FIG. 10 illustrates an example page for setting permissions of a user profile. AsFIG. 10 shows, the owner can select who can view or edit the profile, or who can participate in conversations (e.g., friends, family, anyone, etc.).FIG. 10 is merely an example and does not limit what permissions the owner may set.

FIG. 11 illustrates a process flow associated with determining permission to modify a page. Themodule executer304 obtains permission information associated with the owner (e.g., a permission setting for the action) (1102). Themodule executer304 then obtains the relationship of the owner and editor (1104). In one implementation, themodule executer304 may obtain the relations from thecontact manager308. Themodule executer304 determines if the relationship matches the permission (1106). For example, the relationship matches the permission if the editor is the owner, or, if the owner has granted permission to the editor. If there is not a match, themodule executer304 denies the request (1108).

If there is not a match, themodule executer304 determines if the permission for the action has been revoked. In particular implementations, the owner may blacklist other individual users. For example, Alice has friends Bob and Eve. Alice has set her profile's edit permissions to “friends.” Now Bob and Eve can modify Alice's profile, but it turns out Eve likes to put malicious content on Alice's page. Alice can revoke edit permissions from Eve. Alice then adds Charlie as a friend. Charlie and Bob can modify Alice's profile (because they are “friends”) but Eve cannot (because she was blacklisted). In one implementation, Eve's permission setting may be stored in the contacts manager. If the permission for the action has been revoked, themodule executer304 denies the request (1108). Otherwise, if the permission for the action has not been revoked, themodule executer304 performs the appropriate database transaction (1112).

D. Revision History Module

In one implementation, thesocial network site20 provides users with a revision history module that tracks the activity of users that view or edit the personal page of a given owner.FIG. 12 illustrates an example page showing a revision history for a particular user. AsFIG. 12 shows, the page shows a series of edits to the user's personal page in reverse chronological order from top to bottom. Each line item indicates which module has been added or removed or what aspects of an existing module region have been changed. Each line item also indicates if the owner has approved or rejected a given change, or provides a selection for the owner. For example, referring to line items5-8 and10 from the top, the owner has approved those changes. Referring to the second line item from the bottom of the page, another user has written a guestbook entry. The far right shows a “[Reject] [Approve]” selection, which the owner may select. In one implementation, the page may also provide links to show details of the modifications.FIG. 13 illustrates an example page showing details of changes made by particular users. For example, the first set of edits were made by another user, and the second set of edits were made by the owner.

In one implementation, the “Approve” option may be omitted, where edits are implicitly approved and rejecting edits removes the edit. In particular implementations, the revision history module may provide a “Reject as Spam” action to differentiate abusive or malicious edits from simply unwanted edits.

FIG. 14 illustrates a process flow associated with displaying a revision history. AsFIG. 14 shows, themodule executer304 executes a revisions history module to obtain all edits from the data table for contacts to which the owner has access (1402). In one implementation, the revision history module performs a permission check during this step. In one implementation, the revision history module may shows only content for contacts profiles to which the user has access (e.g., visibility permissions). The revisions history module then iterates over the data (1404). Specifically, in one implementation, themodule executer304 identifies the relevant keys in all entries associated with the owner and invokes a key value renderer to return a description of the edits. In one implementation, some edits such as rejected edits may be filtered out. The revisions history module then aggregates the data (1406). In one implementation, themodule executer304 sorts the data by time stamp during the aggregation. Themodule executer304 then displays the data in reverse chronological order.

In one implementation, the revisions history module determines the last editor for a particular module of a profile. In one implementation, the revisions history module may determine the last editor of the entire personal page. In one implementation, themodule executer304 may determine the most prolific editor.

In one implementation, the revision history module may perform a pulse function, where the revision history module performs a revision history on a global basis (e.g., the edits of all of a given owner's contacts).FIG. 15 illustrates an example page showing updates from all of the contacts of a given user. AsFIG. 15 shows, for all contacts, edits are made to the personal pages of other users.

FIG. 16 illustrates a process flow associated with displaying a revision history. AsFIG. 16 shows, the revision history module obtains all contacts of a given user (1400) and then obtains all of the edits made by the contacts to other users (1401). The revision history module then obtains all edits from the data table for contacts to which the owner has access (1402). In one implementation, the revision history module performs a permission check during this step. In one implementation, the revision history module may shows only content for contacts profiles to which the user has access (e.g., visibility permissions). The revision history module then iterates over the data (1404). In one implementation, themodule executer304 identifies the relevant keys in all entries associated with the owner and invokes a key value renderer to return a description of the edits. In one implementation, some edits such as rejected edits may be filtered out. The revision history module then aggregates the data (1406). In one implementation, themodule executer304 sorts the data by time stamp during the aggregation. The module executer then displays the data in reverse chronological order.

E. Interactive Digital Pet Object

In one implementation, thesocial network site20 provides an interactive digital pet. In a particular implementation, the interactive digital pet is provided as a module that a user can add to his or her personal page. When invoked, the pet module renders an object that is a representation of an animated object (e.g., a pet) in a pet module region. In particular implementations, the pet module facilitates social interaction among users by providing a structured mechanism by which users can interact by allowing users to select an action from an action menu to be applied to the digital pet, as described below.

FIG. 17 illustrates a user interface including an example interactive digital pet object. AsFIG. 17 shows, thepet module region405 displays a representation of an interactivedigital pet object1702, pet attribute information, and one or more action controls1704. In the implementation shown, the pet attribute information may include a pet name, creation or birth date, a current state or mood, a history of one or more actions taken and by whom, etc. For example,FIG. 17 shows an interactivedigital pet object1702 with the name “The Mosh Pet”1706, when the interactivedigital pet object1702 was created (born) “3 days ago”1708, when the interactivedigital pet object1702 was last fed1710. The pet attribute information further includes the current state (here, “happy”)1712, and the identity of the last action applied to the interactivedigital pet object1702 and the user who applied thatlast action1714. AsFIG. 17 illustrates, themodule region405, in a particular implementation, provides a thumbnail image or avatar associated with the user, and a user identifier encoded as a hypertext link that, when clicked, resolves to the user's personal page. WhileFIG. 17 shows one possible representation or image of a pet, other representations are possible. For example, a user may create and apply customized pets by creating one to a plurality of images and associating the images, during an upload process, with a state or range of states.

FIG. 18 illustrates a user interface including showing an exampleinteractive pet object1702 and possible actions available under an action selector control. AsFIG. 18 shows, theaction selector control1714 may be a pull-down menu showing various action selections. For example, such selections may include feed, pet, mosh, snorgle, lick, smack, poke, zap, kill, etc. In one implementation, any action taken may effect the status or mood of the interactivedigital pet object1702. As indicated, the action selected by a given user will affect the mood of the interactivedigital pet object1702. For example, if someone pokes the interactivedigital pet object1702, the mood might be angry. If someone feeds the interactivedigital pet object1702, the mood might be happy. As such, if the mood changes (e.g., happy), the image of the interactivedigital pet object1702 will indicate the mood (e.g., a smile). In one implementation, the state of the interactivedigital pet object1702 may be determined based on an aggregation of actions applied to it. In a particular implementation, the state information may be based on the history of actions stored in the data tables discussed herein.

As discussed above, the pet module tracks who has taken an action upon the interactivedigital pet object1702, when the action was taken, and what the action was. AsFIG. 18 shows, in one implementation, the pet module may display the last action taken and by what user in the module region. In one implementation, the pet module may display a link to the personal page of the user who last interacted with the interactivedigital pet object1702. In another implementation, the pet module may display a history of the last N actions applied to the interactivedigital pet object1702, or may optionally display links to the personal pages of all of the users who interacted with the interactivedigital pet object1702 and their respective actions. Displaying this information allows the owner to view the actions and to decide whether to contact one or more of the users identified in the action history. For example, the page owner may reciprocate and interact with the interactivedigital pet object1702 of the user who took the last action or other users who took actions. In this manner, the interactivedigital pet object1702 and history data facilitates or promotes interaction between users by providing a structured mechanism for interaction that is simple and fun.

FIG. 19 illustrates a process flow associated with invoking a pet module using an Ajax script implemented within the context of a browser client. As described above, Ajax is a web development technique used for creating interactive web applications. An Ajax script can be configured to cause a browser client to interact with a remote server to obtain additional information that can be added to the page without having the entire page re-rendered or refreshed. AsFIG. 19 shows, in response to user interaction with the interactivedigital pet object1702 by selecting an action using action selector control1714 (e.g., feed),social network site20 receives a module request generated by a script (e.g., Javascript) executing within the context of the page (1902). In one implementation, the module request includes an editor ID, owner ID, module ID, module specific parameters (such as the current state of the interactivedigital pet object1702 and the action selected by the user).Social network site20, responsive to the module request, causes themodule executer304 to invoke a digital pet module (1904). In one implementation, when the digital pet module is invoked, it accesses the data tables discussed above, using the module ID and owner ID as a key, to obtain state information such as current mood, last action taken and by whom, time stamp, customized image if applicable, and optionally other information.FIG. 5 illustrates two entries for a pet object where users (labeled R and W, for didactic purposes) have applied actions to a pet of a page owner, S. The value string includes the action taken by the user, and the resulting state of the interactive digital object. In one implementation, the pet module updates the data table in the database by adding a new entry including the owner ID, editor ID, module ID, action taken, a time stamp, and the new current state.

Themodule executor304 may compute a new state for the interactivedigital pet object1702 by accessing the current state of the most recent entry in the data tables, and computing a new state based on the action received in the module request. For example, if the user fed the interactivedigital pet object1702, the current mood may be changed (e.g., to a happy mood, etc.). After a new state is computed, social network site30 returns a status message to the client identifying the new state and possibly other information that is used to modify the information rendered in the pet module region (1906). On the client side, Ajax script carries out the modification in thepet module region405 of the personal page in response to receiving the status code. If the new state requires a new image,social network site20 may also return a URL to the image corresponding to the new state. The Ajax script may insert the new URL into the HTML code of the module causing the new image to be fetched and rendered. In other implementations, Javascript can be used to transmit the module request, andsocial network site20 can transmit a redirection or HTTP refresh message that causes the browser client to refresh the rendered page by transmitting an HTTP request for the viewed page. In another implementation, clicking on theaction selector control1714 causes the browser client to transmit an HTTP request for a new page.

F. Hot Potato Module

In one implementation, thesocial network site20 provides a hot potato module. When invoked, the hot potato module renders an object that is a representation of a hot potato in a hot potato module region. In particular implementations, the hot potato module facilitates social interaction with one another's personal pages by allowing users to throw the hot potato to other users, as described below.

FIG. 20 illustrates a page showing an example semi-autonomous hot potato. AsFIG. 20 shows, the hot potato module region displays ahot potato object2002 andinformation2004 associated with thehot potato object2002. In one implementation, the hot potato module may render thehot potato object2002 in the hot potato module region as shown. In one implementation, the hot potato module may render thehot potato object2002 as an overlay to any one or more other module regions. In other words, the renderedhot potato object2002 need not be rendered in any predefined region. In one implementation, the hot potato module may render other images instead of a potato. For example, the hot potato module may render slime that overlays other module regions. While the hot potato module may render a semi-autonomous hot potato as described herein, the hot potato module may also render an autonomous hot potato such as a rendering involving a rich site summary (RSS) feed renderer, etc.

FIG. 21 illustrates a page showing an example hot potato and trail of ashes information. In one implementation, a trail of ashes list is a list of users having personal pages on which thehot potato object2002 has been rendered. AsFIG. 21 shows, the hot potato module may display the list or trail of ashes. In one implementation, the list may include a number of users up to a predefined limit N (e.g., the last 10 users).FIG. 21 shows one specific implementation of the trail of ashes that is specific to one instance of ahot potato object2002. In other implementations, different hot potato objects may have different trails of ashes as the hot potato objects travel through different personal pages.

FIG. 22 illustrates a process flow associated with a decision to transfer determining whether to throw ahot potato object2002. AsFIG. 22 shows, in response to a user selecting to throw thehot potato object2002 to another user, theHTTP server312 receives a throw request from the client of a user (2202). In one implementation, the throw request may include an editor ID, owner ID, module ID, etc. Thepage creator302, responsive to the request, causes themodule executer304 to invoke the hot potato module or code. In one implementation, when the hot potato module is invoked, it randomly selects a contact from the contact list of the user on whose personal page thehot potato object2002 is rendered (2204). The hot potato module then transfers thehot potato object2002 to the personal page of the selected user (2206). In one implementation, completion of throwing thehot potato object2002 to the randomly selected contact may be contingent on having the permissions required to add thehot potato object2002 to the personal page of that contact. In one implementation, the hot potato module may perform a permission check similar to the permission check described above in connection withFIG. 11. In one implementation, if the thrower does not have the required permission, thehot potato object2002 may be “deflected” back to the personal page of the thrower. In one implementation, when a user throws thehot potato object2002 at another user, it is possible that the hot potato module may randomly select the same user. In other words, it is possible that thehot potato object2002 may get thrown back or stays at the personal page of the user. In one implementation, if the hot potato module transfers a hot potato module to a personal page that already contains a different instance of the potato module, the hot potato module overwrites the older hot potato module with the newer hot potato module. As such, in particular implementation, there is no more hot potatoes on the social network site than the number of personal pages.

In one implementation, if the owner of the current personal page on which thehot potato object2002 is rendered does not attempt to throw or fails to successfully throw thehot potato object2002 within a predetermined time period (e.g., 10 minutes), the hot potato module may automatically invoke itself and pass thehot potato object2002 to a random visitor. In implementation, the hot potato module may pass thehot potato object2002 in a non-random manner. For example the hot potato module may pass the hot potato object to the first or next visitor of the owner's personal page.

FIG. 23 illustrates a process flow associated with transferring ahot potato object2002. In one implementation, the hot potato module transfers thehot potato object2002 from the personal page of one user to that of another user by modifying the layout key of the respective users as described below. The hot potato module first creates a new hot potato key with the target as owner (2302). In one implementation, the target is the randomly selected user described above (step2204 ofFIG. 22), and the editor is the previous owner (e.g., the owner of the personal page from which thehot potato object2002 is transferred).

The hot potato module then creates a new layout entry to remove the hot potato module from the editor profile associated with the personal page of the editor (previous owner) (2304). The hot potato module then creates a new layout entry to add the hot potato module to the target profile associated with the personal page of the target (new owner) (2306). In one implementation, the value field in the data table may include the latest owner in the trail of ashes list. In one implementation, the value field in the data table may not include the current owner in the list, where the previous owner is added to the trail of ashes list. As described above, the trail of ashes list is a list of users having personal pages on which thehot potato object2002 has been rendered. In one implementation, the ID if the latest owner is added to a delimited string of user IDs for the last N users hit with thehot potato object2002.

As described herein, embodiments of the present invention provide an extremely interactivesocial network site20 where trusted users may modify not only their own personal page but also the personal pages of other users. These capabilities facilitate and promote interaction among users thereby promoting use of thesocial network site20.

The present invention has been explained with reference to specific embodiments. For example, while embodiments of the present invention have been described as operating in connection with HTML and HTTP, the present invention can be used in connection with any suitable protocol environment. Other embodiments will be evident to those of ordinary skill in the art. It is therefore not intended that the present invention be limited, except as indicated by the appended claims. For example, a user may represent an organization (e.g., school, church, etc.) where the personal page is associated with the organization.

Claims

1-20. (canceled)

21. A method comprising:

providing, over a network via a computing device, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region;

receiving, at the computing device, an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions;

controlling, via the computing device, an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and

causing, over a network via the computing device, a client program to render the personal page in compliance with said controlled action.

22. The method ofclaim 21, further comprising:

requesting, over the network, a new uniform resource locator (URL) associated with the digital object based on the selection; and

receiving, over the network, the new URL, said new URL corresponding to the modified state of the digital object, wherein said controlled action corresponds to the new URL.

23. The method ofclaim 21, further comprising:

generating new Hyper Text Markup Language (HTML) code for the digital module region upon receiving said selection indication, said HTML code controlling at least said action of the digital object.

24. The method ofclaim 23, further comprising:

creating new data table information for the personal page upon generating the new HTML code; and

storing, over the network, said new data table information in a database location associated with the digital object module region for the personal page.

25. The method ofclaim 21, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object.

26. The method ofclaim 21, wherein said state modification of the digital object comprises displaying information selected from a listing consisting of: text, images, video, changes to the page layout, and changes to the digital module region information.

27. The method ofclaim 21, wherein said action enables a second user to edit the interactive digital object.

28. The method ofclaim 27, further comprising:

communicating a request to the user of the personal page, said request comprising information associated with a requested edit of the digital object by the second user; and

receiving, from the user, permission information associated with whether the edit is allowed.

29. The method ofclaim 21, wherein said digital module region comprises a module selected from a list consisting of: a media player module, revision history module, blurt module, video game module, photo module and conversation modules.

30. The method ofclaim 29, wherein said interactive digital object respectively comprises an interactive object selected from a list consisting of: a media object, revision object, blurt object, video game object, photo object and conversation object.

31. A non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, that when executed by a processor associated with a computing device, perform a method comprising:

providing, over a network, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region;

receiving an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions;

controlling an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and

causing, over a network, a client program to render the personal page in compliance with said controlled action.

32. The non-transitory computer-readable storage medium ofclaim 31, further comprising:

33. The non-transitory computer-readable storage medium ofclaim 31, further comprising:

34. The non-transitory computer-readable storage medium ofclaim 33, further comprising:

35. The non-transitory computer-readable storage medium ofclaim 31, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object.

36. The non-transitory computer-readable storage medium ofclaim 31, wherein said state modification of the digital object comprises displaying information selected from a listing consisting of: text, images, video, changes to the page layout, and changes to the digital module region information.

37. The non-transitory computer-readable storage medium ofclaim 31, further comprising:

receiving, from the user, permission information associated with whether the edit is allowed, wherein said action enables a second user to edit the interactive digital object.

38. The non-transitory computer-readable storage medium ofclaim 31, wherein said digital module region comprises a module selected from a list consisting of: a media player module, revision history module, blurt module, video game module, photo module and conversation modules, wherein said interactive digital object respectively comprises an interactive object selected from a list consisting of: a media object, revision object, blurt object, video game object, photo object and conversation object.

39. A system comprising:

a processor;

a non-transitory computer-readable storage medium for tangibly storing thereon program logic for execution by the processor, the program logic comprising:

providing logic executed by the processor for providing, over a network, a personal page of a user, said personal page comprising core information associated with profile data associated with the user and a digital module region comprising an interactive digital object, said digital module region of the personal page displaying information unique to a type of the digital object, said digital module region controlled by allowed interactions in connection with a displayed action selector within the digital module region;

receiving logic executed by the processor for receiving an indication of a selection from the displayed action selector, said indication corresponding to at least one of said allowed interactions;

controlling logic executed by the processor for controlling an action of the digital object based on said selection, said action comprising modifying a state of the digital object and the displayed information within the digital module region; and

rendering logic executed by the processor for causing, over a network, a client program to render the personal page in compliance with said controlled action

40. The system ofclaim 39, wherein said action of the interactive digital object facilitates social interaction between the user of the personal page and at least a second user visiting the personal page, wherein said user and said second user can communicating via modifications to the interactive digital object.