Graph server querying for managing social network information flow

Information

  • Patent Grant
  • 10628502
  • Patent Number
    10,628,502
  • Date Filed
    Friday, December 2, 2011
    13 years ago
  • Date Issued
    Tuesday, April 21, 2020
    4 years ago
Abstract
An online social network is managed using one server for database management tasks and another server, preferably in a distributed configuration, for CPU-intensive computational tasks, such as finding a shortest path between two members or a degree of separation between two members. The additional server has a memory device containing relationship information between members of the online social network and carries out the CPU-intensive computational tasks using this memory device. With this configuration, the number of database lookups is decreased and processing speed is thereby increased.
Description
BACKGROUND

The present invention generally relates to a system and method for managing an online social network, and more specifically, to a system and method for managing information exchange between members of an online social network.


Online social networking sites have been rapidly gaining in popularity, and operators of online social networking sites have been adding servers and switches to their infrastructure to keep up with the increasing demand. Keeping up with the increasing demand has, however, proved to be difficult for two reasons. First, online social networking sites are virally marketed, as current members actively solicit nonmembers to sign up and join the network, and as a result, its growth has been very rapid. Second, the load on the social networking site is dependent not only on the total number of members but also on the total number of relationships. Because a member typically has multiple relationships, this means that the load increase associated with each new member is much greater than typical.


SUMMARY

The present invention deals with the system load demands by improving the processing efficiencies of the online social networking site. The improvement in the processing efficiencies is achieved by providing one or more graph servers to be used in combination with the site's application server. The application server is configured to handle database management tasks, and the graph servers are configured to handle CPU-intensive computational tasks.


More specifically, the application server manages a database that contains member profile information and member relationship information. The graph servers keep track of how the members are socially connected to one another (hereinafter referred to as, “social network map”) in a dedicated memory device, and process and respond to queries from the application server using the social network map stored in the dedicated memory device. The social network map that is stored in the dedicated memory device of the graph servers is updated to reflect any changes to the member relationship information that are made in the database.


Because the present invention processes relationship information using a social network map that is stored in a dedicated memory device, the number of database lookups is decreased and an improvement in the processing speed is achieved. Depending on the number of relationships that are tracked, a dramatic improvement in the processing speed might be achieved with the present invention.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a diagram that conceptually represents the relationships between members in a social network;



FIG. 2 is a block diagram illustrating the system for managing an online social network according to an embodiment of the present invention;



FIG. 3 is a sample adjacency list that is maintained by the graphs servers of the present invention;



FIG. 4 is a flow diagram illustrating the method for processing a request by one member to view the profile of another member in the system of FIG. 2;



FIG. 5 is a flow diagram illustrating the method for determining whether a member can be contacted by another member in the system of FIG. 2; and



FIG. 6 is a flow diagram illustrating the method for processing a search request in the system of FIG. 2.





DETAILED DESCRIPTION

A social network is generally defined by the relationships among groups of individuals, and may include relationships ranging from casual acquaintances to close familial bonds. A social network may be represented using a graph structure. Each node of the graph corresponds to a member of the social network. Edges connecting two nodes represent a relationship between two individuals. In addition, the degree of separation between any two nodes is defined as the minimum number of hops required to traverse the graph from one node to the other. A degree of separation between two members is a measure of relatedness between the two members.



FIG. 1 is a graph representation of a social network centered on a given individual (ME). Other members of this social network include A-U whose position, relative to ME's, is referred to by the degree of separation between ME and each other member. Friends of ME, which includes A, B, and C, are separated from ME by one degree of separation (1 d/s). A friend of a friend of ME is separated from ME by 2 d/s. As shown, D, E, F and G are each separated from ME by 2 d/s. A friend of a friend of a friend of ME is separated from ME by 3 d/s. FIG. 1 depicts all nodes separated from ME by more than 3 degrees of separation as belonging to the category ALL.


Degrees of separation in a social network are defined relative to an individual. For example, in ME's social network, H and ME are separated by 2 d/s, whereas in G's social network, H and G are separated by only 1 d/s. Accordingly, each individual will have their own set of first, second and third degree relationships.


As those skilled in the art understand, an individual's social network may be extended to include nodes to an Nth degree of separation. As the number of degrees increases beyond three, however, the number of nodes typically grows at an explosive rate and quickly begins to mirror the ALL set.



FIG. 2 is a block diagram illustrating a system for managing an online social network. As shown, FIG. 2 illustrates a computer system 100, including an application server 200 and distributed graph servers 300. The computer system 100 is connected to a network 400, e.g., the Internet, and accessible over the network by a plurality of computers, which are collectively designated as 500.


The application server 200 manages a member database 210, a relationship database 220 and a search database 230. The member database 210 contains profile information for each of the members in the online social network managed by the computer system 100. The profile information may include, among other things: a unique member identifier, name, age, gender, location, hometown, a pointer to an image file, listing of interests, attributes, etc. The profile information also includes VISIBILITY and CONTACTABILITY settings, the uses of which are described below in connection with FIGS. 4 and 5.


The relationship database 220 stores member relationship information in the following format: (MemberID_1, MemberID_2, Time, Add/Delete). MemberID_1 and MemberID_2 identify the two members whose relationship is defined by this input. Time is a variable corresponding to the time stamp of this input. Add/Delete is a variable indicating whether the friendship between MemberID_1 and MemberID_2 is to be added or deleted.


In addition, the contents of the member database 210 are indexed and optimized for search, and stored in the search database 230. The member database 210, the relationship database 220, and the search database 230 are updated to reflect inputs of new member information and edits of existing member information that are made through the computers 500.


The member database 210, the relationship database 220, and the search database 230 are depicted separately in the block diagram of FIG. 2 to illustrate that each performs a different function. The databases 210, 220, 230 may each represent a different database system, module, or software; or any two of the three or all three may be parts of the same database system, module, or software.


The application server 200 also manages the information exchange requests that it receives from the remote computers 500. The information exchange requests may be a request to view a member's profile (FIG. 4), a request to send messages to a member (FIG. 5), or a search request (FIG. 6). The application server 200 relies on the distributed graph servers 300 to process certain CPU-intensive tasks that are part of the information exchange request. The graph servers 300 receive a query from the application server 200, process the query and return the query results to the application server 200.


The graph servers 300 have a dedicated memory device 310, such as a random access memory (RAM), in which an adjacency list that reflects the member relationship information is stored. A sample adjacency list that reflects the social network map of FIG. 1 is shown in FIG. 3. A list item is generated for each member and contains a member identifier for that member and member identifier(s) corresponding to friend(s) of that member. As an alternative to the adjacency list, an adjacency matrix or any other graph data structure may be used.


The graph servers 300, on a fixed interval, e.g., every five minutes, check the relationship database 220 for any incremental changes to the member relationship information. If there is, e.g., if (current time—5 minutes) is less than or equal to the time stamp corresponding to an entry in the relationship database 220, the adjacency list stored in the dedicated memory device 510 is updated to reflect such incremental change. If a friendship is to be added, the adjacency list item for MemberID_1 is amended to add MemberID_2 and the adjacency list item for MemberID_2 is amended to add MemberID_1. If a friendship is to be deleted, the adjacency list item for MemberID_1 is amended to delete MemberID_2 and the adjacency list item for MemberID_2 is amended to delete MemberID_1. Alternatively, the adjacency list can be updated in real time, i.e., synchronously with the updates to the relationship database 220.


The queries processed by the graph servers 300 include:

    • List_of Members (M1, N d/s), which returns a list of member identifiers of all members who are exactly N d/s from member M1;
    • No_of_Members (M1, N d/s), which returns a raw number indicating the number of members who are exactly N d/s from member M1;
    • Get_Network (M1, N d/s), which returns a list of member identifiers of all members that are within N d/s from member M1;
    • Shortest Path (M1, M2), which returns the shortest path, if any, between member M1 and member M2 (the shortest path is displayed in the form of member identifiers of those members disposed in the shortest path between member M1 and member M2); and
    • Are_Connected? (M1, M2, degrees), which returns the degree of separation corresponding to the shortest path between member M1 and member M2, if the two are connected. If the two are not connected, an error code indicating that the two members are not connected is returned.


For the calculation of the shortest path in the queries listed above, any of the shortest path algorithms for a node network defined by an adjacency list may be used, e.g., breadth first search algorithm. The algorithms for carrying out other calculations that are necessary to process the queries listed above are programmed using conventional techniques.


In FIG. 2, a plurality of distributed graph servers 300 are depicted, and is preferred over a single graph server because the distributed structure permits resources to be shared. However, the present invention may also be practiced with a single graph server.


The application server 200 and the graphs servers 300 are depicted separately in the block diagram of FIG. 2 to illustrate that the two are performing separate processes. The application server 200 and the graphs servers 300 may be housed within a single physical structure, or they may be parts of a single processor that is programmed to carry out their separate processes in parallel.



FIG. 4 is a flow diagram illustrating the method for processing a request by one member (e.g., M1) to view the profile of another member (e.g., M2) in the system of FIG. 2. In Step 610, the application server 200 receives a request by member M1 to view the profile of member M2. As an example, this happens when member M1 clicks on a hyperlink associated with member M2. The full profile of member M2 will be displayed if the d/s between M1 and M2 is less than or equal to the VISIBILITY setting set by member M2 or if the VISIBILITY setting set by member M2 is ALL. (VISIBILITY setting may be set at 1, 2, 3 or ALL.) Otherwise, only the mini-profile of member M2 will be displayed. In Step 620, the application server 200 retrieves M2's VISIBILITY setting from the member database 210. If M2's VISIBILITY setting is ALL, the full profile of M2 will be transmitted to M1 for display at M1's computer (Steps 630 and 640). If not, the application server 200 sends the Are_Connected? query to the graph servers 300 to determine the d/s between member M1 and member M2 (Steps 630 and 650). The graph servers 300 execute this query and return the d/s that it computed to the application server 200. If the computed d/s is greater than the VISIBILITY setting or if member M1 and member M2 are not connected, the mini-profile of member M2 and a message indicating that member M2's full profile can only be viewed by members in his or her personal network is transmitted to M1 for display at M1's computer (Steps 660 and 670). Otherwise, the full profile of member M2 is transmitted to M1 for display at M1's computer (Steps 660 and 640).



FIG. 5 is a flow diagram illustrating the method for determining whether a member can be contacted by another member in the system of FIG. 2. In the example given herein, it is assumed that member M1 is attempting to send a message to member M2. In Step 710, the application server 200 retrieves the CONTACTABILITY setting of member M2. (CONTACTABILITY setting may beset as 1, 2, 3 or ALL.) If M2's CONTACTABILITY setting is ALL, this means that member M2 is permitting contact from anyone, and consequently, when member M1 views member M2's profile, a “Send Message” hyperlink will appear through which member M1 will be able to send messages to member M2 (Steps 720 and 730). If M2's CONTACTABILITY setting is not set to ALL, the application server 200 sends the Are_Connected? query to the graph servers 300 to determine the d/s between member M1 and member M2 (Steps 720 and 740). The graph servers 300 execute this query and return the d/s that it computed to the application server 200. If the computed d/s is greater than the CONTACTABILITY setting or if member M1 and member M2 are not connected, this means that member M2 is not permitting contact from member M1 and the “Send Message” hyperlink will not be displayed when member M1 views member M2's profile (Steps 750 and 760). If the computed d/s is less than or equal to the CONTACTABILITY setting, this means that member M2 is permitting contact from member M1, and consequently, when member M1 views M2's profile, a “Send Message” hyperlink will appear through which member M2 will be able to send messages to member M1 (Steps 750 and 730).



FIG. 6 is a flow diagram illustrating the method for processing a search request in the system of FIG. 2. In Step 810, the application server 200 receives a search query input by member M1. The search query is divided into two parts. The first part specifies search terms for pre-selected categories such as gender, age, interests and location. The second part specifies a d/s setting, which may beset at 1, 2, 3 or ALL. For example, the search query may be: [gender (female), age (less than 30), d/s (at most 2)]. The first part of this search query is [gender(female), age (less than 30)] and the second part of this search query is [d/s (at most 2)]. In Step 820, the application server 200 issues the first part of the search query to the search database 230 to obtain member identifiers for those members whose profiles meet the specified criteria. In Step 830, the application server 200 issues a Get_Network query to the graph servers 300 to obtain a list of member identifiers of all members that are within the d/s specified in the second part of the search query. The application server 200 merges the results from the search database 230 and the graph servers 300 (Step 840), and transmits the merged results to member M1 (Step 850). After the merged results are delivered to member M1, the member may click on any of the results to view that member's profile and, if the “Send Message” hyperlink is displayed, attempt to send a message to that member through that hyperlink.


While particular embodiments according to the invention have been illustrated and described above, it will be clear that the invention can take a variety of forms and embodiments within the scope of the appended claims.

Claims
  • 1. A computer-implemented method comprising, by one or more processors associated with one or more computing systems: receiving, from a client device of a first user of an online social network, a request for a user profile of a second user of the online social network;retrieving, using the one or more processors and in response to the request, information from a user profile database, the information comprising user profile data of the second user, wherein a social graph representing the online social network comprises a plurality of nodes and edges, each node representing one of a plurality of users of the online social network, each edge representing a relationship between two of the plurality of users and establishing a degree of separation between each of the plurality of users based on the social graph, wherein the first user corresponds to a first node of the plurality of nodes and the second user corresponds to a second node of the plurality of nodes;determining, using the one or more processors, a profile format for the user profile data of the second user based on a visibility preference of the second user and a degree of separation between the first node and the second node within the social graph, the visibility preference of the second user being included with the information retrieved from the user profile database, and the visibility preference of the second user indicating a specified degree of separation between the second node and another node at which the user is permitted to view the user profile data of the second user in a full profile format; andsending, to the client device for display to the first user, information representing the user profile data of the second user, wherein: if the degree of separation between the first node and the second node is less than or equal to the specified degree of separation indicated in the visibility preference of the second user, then sending the information using a full profile format; andif the degree of separation between the first node and the second node is greater than the specified degree of separation indicated in the visibility preference of the second user, then sending the information using a mini profile format.
  • 2. The method of claim 1, wherein the request comprises an identifier for the second user.
  • 3. The method of claim 1, wherein the specified degree of separation of the visibility preference is 1, 2, 3, or All degrees of separation.
  • 4. The method of claim 1, wherein the full profile format permits the first user to view an entirety of the user profile data of the second user.
  • 5. The method of claim 1, wherein the mini profile format permits the first user to view only a limited portion of the user profile data of the second user.
  • 6. One or more machine-readable non-transitory storage media embodying software that is operable when executed by one or more processors associated with one or more computer systems to: receive, from a client device of a first user of an online social network, a request for a user profile of a second user of the online social network;retrieve, using the one or more processors and in response to the request, information from a user profile database, the information comprising user profile data of the second user, wherein a social graph representing the online social network comprises a plurality of nodes and edges, each node representing one of a plurality of users of the online social network, each edge representing a relationship between two of the plurality of users and establishing a degree of separation between each of the plurality of users based on the social graph, wherein the first user corresponds to a first node of the plurality of nodes and the second user corresponds to a second node of the plurality of nodes;determine, using the one or more processors, a profile format for the user profile data of the second user based on a visibility preference of the second user and a degree of separation between the first node and the second node within the social graph, the visibility preference of the second user being included with the information retrieved from the user profile database, and the visibility preference of the second user indicating a specified degree of separation between the second node and another node at which the user is permitted to view the user profile data of the second user in a full profile format; andsend, to the client device for display to the first user, information representing the user profile data of the second user, wherein: if the degree of separation between the first node and the second node is less than or equal to the specified degree of separation indicated in the visibility preference of the second user, then send the information using a full profile format; andif the degree of separation between the first node and the second node is greater than the specified degree of separation indicated in the visibility preference of the second user, then send the information using a mini profile format.
  • 7. The one or more machine-readable non-transitory storage media of claim 6, wherein the mini profile format permits the first user to view only a limited portion of the user profile data of the second user.
  • 8. The one or more machine-readable non-transitory storage media of claim 6, wherein the full profile format permits the first user to view an entirety of the user profile data of the second user.
  • 9. A system comprising: a user profile database; and an application server comprising: one or more computing systems; andone or more non-transitory machine-readable storage media comprising, by one or more processors associated with one or more computing systems, software for causing the one or more computing systems to execute instructions to: receive, from a client device of a first user of an online social network, a request for a user profile of a second user of the online social network;retrieve, using the one or more processors and in response to the request, information from a user profile database, the information comprising user profile data of the second user, wherein a social graph representing the online social network comprises a plurality of nodes and edges, each node representing one of a plurality of users of the online social network, each edge representing a relationship between two of the plurality of users and establishing a degree of separation between each of the plurality of users based on the social graph, wherein the first user corresponds to a first node of the plurality of nodes and the second user corresponds to a second node of the plurality of nodes;determine, using the one or more processors, a profile format for the user profile data of the second user based on a visibility preference of the second user and a degree of separation between the first node and the second node within the social graph, the visibility preference of the second user being included with the information retrieved from the user profile database, and the visibility preference of the second user indicating a specified degree of separation between the second node and another node at which the user is permitted to view the user profile data of the second user in a full profile format; andsend, to the client device for display to the first user, information representing the user profile data of the second user, wherein: if the degree of separation between the first node and the second node is less than or equal to the specified degree of separation indicated in the visibility preference of the second user, then sending the information using a full profile format; andif the degree of separation between the first node and the second node is greater than the specified degree of separation indicated in the visibility preference of the second user, then sending the information using a mini profile format.
  • 10. The system of claim 9, wherein the request comprises an identifier for the second user.
  • 11. The system of claim 9, wherein the specified degree of separation of the visibility preference is 1, 2, 3, or All degrees of separation.
  • 12. The system of claim 9, wherein the full profile format permits the first user to view an entirety of the user profile data of the second user.
  • 13. The system of claim 9, wherein the one or more non-transitory machine-readable storage media of the application server further comprises instructions to compare the degree of separation between the first node and the second node to the degree of separation indicated in the visibility preference of the second user when the application server determines that the visibility preference is not set to All degrees of separation.
  • 14. The system of claim 13, wherein the mini profile format permits the first user to view only a limited portion of the user profile data of the second user.
  • 15. The system of claim 14, wherein the one or more non-transitory machine-readable storage media of the application server further comprises instructions to set the profile format to transmit the information, based on the full profile format, when the degree of separation between the first node and the second node is less than or equal to the degree of separation indicated in the visibility preference of the second user.
  • 16. The method of claim 1, wherein determining the profile format for the user profile data of the second user comprises: determining whether the visibility preference of the second user is set to some value other than All degrees of separation;generating, in response to determining that the visibility preference of the second user is set to some value other than All degrees of separation, a request for the degree of separation between the first user and the second user;receiving, at a graph server configured to manage the social graph, the request for the degree of separation between the first user and the second user;accessing, by the graph server and in response to receiving the request for the degree of separation between the first user and the second user, the social graph;determining, by the graph server, the degree of separation between the first user and the second user by computing the fewest number of edges in the social graph between the first node and the second node;receiving the degree of separation between the first user and the second user determined by the graph server; andsetting the profile format for viewing the user profile data of the second user based on a comparison of the degree of separation indicated in the visibility preference and the received degree of separation between the first user and the second user.
  • 17. The method of claim 16, wherein the social graph represents a plurality of entries stored in a relationship database for the online social network, each entry of the plurality of entries indicating a relationship between at least two users of the plurality of users of the online social network,wherein the one or more computing systems and the one or more processors associated with the one or more computing systems are components of an application server configured to manage the user profile database and a relationship database,wherein the user profile database stores user profile data for each of the plurality of users of the online social network,wherein the social graph is stored in a dedicated memory device separate from the user profile database and the relationship database, andwherein the graph server, which is separate from the application server, determines the degree of separation between the first user and the second user without accessing the relationship database.
  • 18. The one or more machine-readable non-transitory storage media of claim 6, wherein the software for determining the profile format for the user profile data of the second user is operable when executed by one or more processors associated with one or more computer systems to: determine whether the visibility preference of the second user is set to some value other than All degrees of separation;generate, in response to determining that the visibility preference of the second user is set to some value other than All degrees of separation, a request for the degree of separation between the first user and the second user;control a graph server, which is configured to manage the social graph, to: receive the request for the degree of separation between the first user and the second user;access, in response to receiving the request for the degree of separation between the first user and the second user, the social graph; anddetermine the degree of separation between the first user and the second user by computing the fewest number of edges in the social graph between a node representing the first user and a node representing the second user;receive the degree of separation between the first user and the second user determined by the graph server; andset the profile format for viewing the user profile data of the second user based on a comparison of the degree of separation indicated in the visibility preference and the received degree of separation between the first user and the second user.
  • 19. The system of claim 9, wherein the system further comprises a graph server,wherein the instruction to determine the profile format for the user profile data of the second user comprises instructions for the one or more computing systems to: determine whether the visibility preference of the second user is set to some value other than All degrees of separation;generate, in response to determining that the visibility preference of the second user is set to some value other than All degrees of separation, a request for the degree of separation between the first user and the second user;receive the degree of separation between the first user and the second user from the graph server; andset the profile format for viewing the user profile data of the second user based on a comparison of the degree of separation indicated in the visibility preference and the received degree of separation between the first user and the second user,wherein the graph server comprises:a dedicated memory device, the dedicated memory device storing the social graph and being separate from the user profile database;a processor; andone or more non-transitory machine-readable storage media comprising software for causing the processor to execute instructions to: receive the request for the degree of separation between the first user and the second user;access, in response to receiving the request for the degree of separation between the first user and the second user, the social graph; anddetermine the degree of separation between the first user and the second user by computing the fewest number of edges in the social graph between a node representing the first user and a node representing the second user.
  • 20. The method of claim 1, wherein if no path connects the first node to the second node within the social graph, then the degree of separation between the first node and the second node is greater than the specified degree of separation in the visibility preference.
RELATED APPLICATIONS

The present application is a continuation of U.S. patent application Ser. No. 10/854,054, filed May 26, 2004, and entitled “System and Method for Managing an Online Social Network,” which is incorporated by reference herein for all purposes.

US Referenced Citations (161)
Number Name Date Kind
4987554 Kaufman Jan 1991 A
4989141 Lyons Jan 1991 A
5101475 Kaufman Mar 1992 A
5189608 Lyons Feb 1993 A
5257365 Powers Oct 1993 A
5278966 Parks Jan 1994 A
5359724 Earle Oct 1994 A
5361385 Bakalash Nov 1994 A
5379419 Heffernan Jan 1995 A
5706495 Chadha Jan 1998 A
5735531 Jordan Apr 1998 A
5745764 Leach Apr 1998 A
5765028 Gladden Jun 1998 A
5781896 Dalal Jul 1998 A
5794228 French Aug 1998 A
5794229 French Aug 1998 A
5794246 Sankaran Aug 1998 A
5799300 Ragrawal Aug 1998 A
5805885 Leach Sep 1998 A
5822751 Gray Oct 1998 A
5832475 Agrawal Nov 1998 A
5850547 Waddington Dec 1998 A
5852821 Chen Dec 1998 A
5857184 Lynch Jan 1999 A
5864857 Ohata Jan 1999 A
5890151 Agrawal Mar 1999 A
5901287 Bull May 1999 A
5905985 Malloy May 1999 A
5915257 Gartung Jun 1999 A
5918225 White Jun 1999 A
5918232 Pouschine Jun 1999 A
5926818 Malloy Jul 1999 A
5926820 Agrawal Jul 1999 A
5940822 Haderlie Aug 1999 A
5950200 Sudai Sep 1999 A
5963936 Cochrane Oct 1999 A
5963951 Collins Oct 1999 A
5978768 McGovern Nov 1999 A
5978788 Castelli Nov 1999 A
5978796 Malloy Nov 1999 A
5987467 Ross Nov 1999 A
5991754 Raitto Nov 1999 A
5999192 Selfridge Dec 1999 A
6003029 Agrawal Dec 1999 A
6006216 Griffin Dec 1999 A
6023695 Osborn Feb 2000 A
6034697 Becker Mar 2000 A
6052122 Sutcliffe Apr 2000 A
6061681 Collins May 2000 A
6064999 Dalal May 2000 A
6073105 Sutcliffe Jun 2000 A
6073138 de l'Etrax Jun 2000 A
6108647 Poosala Aug 2000 A
6115705 Larson Sep 2000 A
6122628 Castelli Sep 2000 A
6134541 Castelli Oct 2000 A
6141655 Johnson Oct 2000 A
6151601 Papieniak Nov 2000 A
6161103 Raunder Dec 2000 A
6163774 Lore Dec 2000 A
6173310 Yost Jan 2001 B1
6175831 Weinreich Jan 2001 B1
6182060 Hedgcock Jan 2001 B1
6182061 Matsuzawa Jan 2001 B1
6189004 Rassen Feb 2001 B1
6205447 Malloy Mar 2001 B1
6208975 Bull Mar 2001 B1
6209036 Aldred Mar 2001 B1
6212515 Rogers Apr 2001 B1
6212524 Weismman Apr 2001 B1
6212617 Hardwick Apr 2001 B1
6249282 Sutcliffe Jun 2001 B1
6249791 Osborn Jun 2001 B1
6269369 Robertson Jul 2001 B1
6269393 Yost Jul 2001 B1
6317750 Tortolani Nov 2001 B1
6321241 Gartung Nov 2001 B1
6324533 Agrawal Nov 2001 B1
6324541 de l'Estrz Nov 2001 B1
6330564 Hellerstein Dec 2001 B1
6347332 Malet Feb 2002 B1
6363427 Teibel Mar 2002 B1
6366962 Teibel Apr 2002 B1
6370510 McGovern Apr 2002 B1
6374234 Netz Apr 2002 B1
6385301 Nolting May 2002 B1
6385604 Bakalash May 2002 B1
6397195 Pinard May 2002 B1
6405208 Raghaavn Jun 2002 B1
6408292 Bakalash Jun 2002 B1
6408309 Agarwal Jun 2002 B1
6434544 Bakalash Aug 2002 B1
6473764 Petculescu Oct 2002 B1
6477536 Pasumnasky Nov 2002 B1
6484179 Roccaforte Nov 2002 B1
6493728 Berger Dec 2002 B1
6535872 Castelli Mar 2003 B1
6542748 Hendrey Apr 2003 B2
6549907 Fayyad Apr 2003 B1
6587547 Zirngibl Jul 2003 B1
6594672 Lampson Jul 2003 B1
6601062 Deshpande Jul 2003 B1
6629094 Colby Sep 2003 B1
6640218 Golding Oct 2003 B1
6643661 Polizzi Nov 2003 B2
6662174 Shah Dec 2003 B2
6708172 Wong Mar 2004 B1
6732115 Shah May 2004 B2
6735568 Buckwalter May 2004 B1
6748394 Shah Jun 2004 B2
6763357 Deshpande Jul 2004 B1
6766325 Pasumanksy Jul 2004 B1
6832263 Polizzi Dec 2004 B2
7069308 Abrams Jun 2006 B2
7085927 Kohli Aug 2006 B1
7117254 Lunt Oct 2006 B2
7120619 Drucker Oct 2006 B2
7177880 Ruvolo Feb 2007 B2
7188153 Lunt Mar 2007 B2
7236789 Balachandran Jun 2007 B2
7269590 Hull Sep 2007 B2
7478078 Lunt Jan 2009 B2
7512612 Akella Mar 2009 B1
7657540 Bayliss Feb 2010 B1
7720846 Bayliss May 2010 B1
7895357 Walker Feb 2011 B1
7958457 Brandenberg Jun 2011 B1
9984251 Belton May 2018 B2
20010011948 Rasband Aug 2001 A1
20020016924 Shah Feb 2002 A1
20020023122 Polizzi Feb 2002 A1
20020026478 Rodhers Feb 2002 A1
20020029207 Bakalash Mar 2002 A1
20020038229 Shah Mar 2002 A1
20020038297 Shah Mar 2002 A1
20020086676 Hendrey Jul 2002 A1
20020099692 Shah Jul 2002 A1
20020111173 Hendrey Aug 2002 A1
20020154171 Lee Oct 2002 A1
20030115194 Pitts Jun 2003 A1
20030135582 Allen Jul 2003 A1
20030154194 Jonas Aug 2003 A1
20030187813 Goldman Oct 2003 A1
20040034601 Kreuzer Feb 2004 A1
20040088322 Elder May 2004 A1
20040088325 Elder May 2004 A1
20040094234 Curtis, Sr. May 2004 A1
20040122855 Ruvolo Jun 2004 A1
20040144301 Neudeck Jul 2004 A1
20040148275 Achlioptas Jul 2004 A1
20050078613 Covell Apr 2005 A1
20050091202 Thomas Apr 2005 A1
20050165785 Malkin Jul 2005 A1
20050177385 Hull Aug 2005 A1
20050209999 Jou Sep 2005 A1
20050235062 Lunt Oct 2005 A1
20050243736 Faloutsos Nov 2005 A1
20050256866 Lu Nov 2005 A1
20070005750 Lunt Jan 2007 A1
20070244854 Nevill-Manning Oct 2007 A1
20080004944 Calabria Jan 2008 A1
Foreign Referenced Citations (1)
Number Date Country
1998049636 Nov 1998 WO
Non-Patent Literature Citations (35)
Entry
Albrecht, J. et al., “Aggregate-Based Query Processing in a Parallel Data Warehouse Server,” Proceedings of the Tenth International Workshop on Database and Expert Systems Applications, Sep. 1-3, 1999 pp. 40 44.
Pourabbas, E. et al., “CharacterIZatlon of Hlerarchles and Some Operators in OLAP Environment,” Presented at the ACM 2 International Workshop on Data Warehousing and OLAP, p. 1-17, Nov. 1999.
Wildmann, “Efficient Execution of Operations in a DBMS for Mulidemensional Arrays”, p. 1-11, May 1997.
Pedersen, T.B., Aspects ofData Modeling and Query Processing for Complex Multidimensional Data, 2000, pp. 1-180, Danish Academy ofTechnical Sciences.
Pourabbas, E. et al., “Hierarchies and Relative Operators in the OLAP Environment,” SIGMOD Record, Mar. 2000, pp. 1-8,v61. 29, No. 1, Apr. 2000.
Harinarayan, V. et al., “Implementing Data Cubes EF?ciently,” Presented at the ACM SIGMOD International Conference on Manage ment9fData.,1211 205-216, Jun. 1996.
Agrawal, R. et al., “Modeling Multidimensional Databases,” IBM Almaden Research Center, 1995; Presented at the 13th International Conference on Data Engineering Apr. 1997, pp. 1-23.
Agarwal, S. et al., “On the Computation of Multidimensional Aggregates,” Presented at the 22nd VLDB Conference, 1996, pp. 1-16.
Hellerstein, J .M. et al., “Online Aggregation,” Presented at the ACM SIGMOD International Conference on Management of Data, May 1997, Tucson, Arizona, pp. 1-12, http://www.acm.org/pubs/citations/proceedings/mod/253260/p171-hellerstein/.
Li, C. et al., “Optimizing Statistical Queries by Exploiting Orthogo nality and Interval Properties of Grouping Relations,” Presented at the 8th International Conference on Scienti?c & Statistical Database Management, pp. 1-10, Jun. 1996.
Ho, C. et al., “Range Queries in OLAP Data Cubes,”Presented at the ACM SIGMOD International Conference on Management of Data. pp. 1-16, http://www.acm.org/pubs/citations/proceedings/mod/253260/p73 -ho/, May 1997.
“See Data from All Angles with Multidimensional Database Soft ware” SAS Institute Inc., 2001, 1 page, www.sas.com/products/mddb/indexhtml.
Cheung, D.W. et al., “Towards the Building of a Dense-Region Based OLAP System,” Data and Knowledge Engineering, 2001, pp. 1-27, vol. 36, No. 1, http://www.elsevier.nl/gei-ng/10/16/74/62/24/24/ abstract.html.
McKie, S., “Essbase 4.0,” DBMS Online, Jul. 1996, pp. 1-4, http://www.dbmsmag.com/9607d13.htrnl.
Hellerstein, J .M., “Optimization Techniques for Queries with Expensive Methods,” ACM Transactions on.Database Systems (TODS), 1998, pp. 113-157, vol. 23, No. 2.
Colliat, G., “OLAP, Relational, and Multidimensional Database Systems,” SIGMOD Record, Sep. 1996, pp. 64-69, vol. 25, No. 3.
Kimball, R., “The Aggregate Navigator; How to Optimize Your Data Warehouse Using Aggregates Without Driving Your End Users Crazy,” DBMS, Nov. 1995, www.dbmsmag.com.
Pendse, N., “The Origins ofToday's OLAP Products,” Feb. 6, 2003, pp. 1-7, http://www.olapreport.com/origins.htm.
“Introduction to Structured Query Language,” 2000, pp. 1-33, http:/w3 .one .net/about.j hoffmann/sqltuthtm.
Date, C.J., “An Introduction to Database Systems,” 2000, pp. 250, 266, 289-326, Addison-Wesley, Seventh Edition.
“The Art ofIndexing,” A White Paper by DISC, Oct. 1999, pp. 3-30, Dynamic Information Systems Corporation.
Harrington, J .L., “Relational Database Design Clearly Explained,” 1998, pp. v-xiii, 1-62, Morgan Kaufman.
Kimball, R., “Aggregate Navigation With (Almost) No MetaData,” 1996, pp. 1-8, http://www.dbmsmag.com/9608d54.html.
Duhl, J. et al., “A Performance Comparison of Object and Relational Databases Using the Sun Benchmark,” Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, Sep. 25-30, 1988, pp. 153-163.
Gupta, H. V., et al., “Index Selection for OLAP”, Proceedings of the 13th Int'l Conference on Data Engineering, Apr. 7-11, 1997, pp. 208-219.
Chaudhuri, S. et al., “An Overview of Data Warehousing and OLAP Technology”, SIGMOD Record, NewYork, NY Mar. 1997, vol. 26, No. 1, Apr. 1997.
Colby, L.S. et al. “Red Brick Vista: Aggregate Computation and Myanagement”, Data Engineering 1998 Proceedings, 14th Int'l Conference in Orlando, Fl., Feb. 23-27, 1998.
Albrecht, J. et al. “Management of Multidimensional Aggregates for Effcient Online Analytical Processing,” Database Engineering and Applications, 1999, Int'l Symposium Proceedings Montreal, Quebec, Canada.
Zhao, Y et al. “Array-Based Evaluation of Multi-Dimensional Queries in Object-Relational Database Systems,” Data Engineering, 1998 Proceedings, 14th Int'l Conference in Orlando, Fl., Feb. 23-27, 1998.
“Performance Management Product Information,” ENT, Jul. 17, 1999, 2 pages.
Li, C., et al. “A Data Model for Supporting On-Line Analytical Processing,” Presented at the International Conference on Information and Knowledge Management, pp. 81-88, 1996.
Korn, F., et al., “Efficiently Supporting Ad Hoc Queries in Large Datasets of Time Sequences,” Presented at ACM SIGMOD International Conference on Management of Data, May 11-15, 1997, pp. 1-22, http://www.acm.org/pubs/citations/proceedings/mod/253260.p.289-korn/.
Salem, K., et al., “How to Roll a Join: Asynchronous Incremental View Maintenance,” Presented at ACM SIGMOD on Management of Data and Symposium on Principles of Database Systems, May 15-18, 2000, pp. 1-13, http://www.acm.org/pubs/citations/proceedings/mod/342009/p129-salem/#abstract.
Hellerstein, J.M., et al., “Online Aggregation,” Presented at the ACM SIGMOD International Conference on Management of Data, May 1997, Tucson, Arizona, pp. 1-12, http://www.acm.org/pubs/citatins/proceeedings/mod/253260/p171-hellerstein/.
Elkins, S.B., “Open OLAP,” DBMS, Apr. 1998, pp. 1-7, http://www.dbmsmag.com/9804d14.html.
Related Publications (1)
Number Date Country
20120078957 A1 Mar 2012 US
Continuations (1)
Number Date Country
Parent 10854054 May 2004 US
Child 13309824 US