US20100160047A1 - Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data - Google Patents

Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data Download PDF

Info

Publication number
US20100160047A1
US20100160047A1 US12/341,481 US34148108A US2010160047A1 US 20100160047 A1 US20100160047 A1 US 20100160047A1 US 34148108 A US34148108 A US 34148108A US 2010160047 A1 US2010160047 A1 US 2010160047A1
Authority
US
United States
Prior art keywords
front
name
end
back
system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/341,481
Inventor
Felix Livni
Lowell Manners
Gary William Hall
Jay Thaler
Tony Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US12/341,481 priority Critical patent/US20100160047A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HALL, GARY WILLIAM, LIVNI, FELIX, MANNERS, LOWELL, THALER, JAY
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHEN, TONY
Publication of US20100160047A1 publication Critical patent/US20100160047A1/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/10Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network
    • H04L67/1095Network-specific arrangements or communication protocols supporting networked applications in which an application is distributed across nodes in the network for supporting replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes or user terminals or syncML
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/38Protocols for telewriting; Protocols for networked simulations, virtual reality or games
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/531Server assignment
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/534Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction

Abstract

Disclosed herein is a set of coordinated game service primitives that allows for custom, per-game, logic. A new game with new custom logic can be added without needing to change any public api or database schema or write any new server code. The same hardware may be shared across many games. And the system scales linearly. That is, if the number of servers is doubled, then so is the number of concurrent users that can be supported. Also disclosed are systems and methods for two-stage aggregation. Pre-aggregation may take place on a plurality of front-end server. Final aggregation may take place on one or more back-end servers. A name value store may be used to reliably store state.

Description

    BACKGROUND
  • In a console game designed to support many users all posting messages to a server or servers, where each message contains data that needs to be aggregated and made available back to those users, common “primitive” aggregation logic, such as summation and top-n, as well as custom game-specific aggregation logic can be used to drive custom game logic. For example, each user might belong to a team and post a score. The scores might need to be summed to get the total score for each team. The aggregate score might need to be made available quickly to the users. Writing custom server code is expensive, however, and custom servers are expensive to maintain.
  • Also, in such a console game, due to the volume of posted messages, all the posts may not be able to be handled on a single front end server. Accordingly, it would be desirable to provide a mechanism for aggregating values posted across many front end servers.
  • In a platform that supports many massively multi-player games, which tend to have a high number of concurrent users during just a few hours a week, many servers may be needed to support peak load, which may be on the order of about 200,000 internet accesses/second, with peak data transfer rates on the order of Gigabits/second. For this reason and others, it may be desirable to share a single game service across many different games.
  • It would be particularly desirable if a single infrastructure that scales to peak could be used across many games, with a standard service that need not be extended every time a new game is built. Such a service should be sufficiently fault tolerant such that it can tolerate and recover from any single component failure automatically and within seconds.
  • SUMMARY
  • Disclosed herein is a set of coordinated game service primitives that allows for custom, per-game, logic. The functionality of the primitives does not change from game-to-game, custom, client-side game logic can be built on top of these primitives in much the same way that custom reports can be generated using SQL primitives. For example, a new game with new custom logic can be added without needing to change any public application programming interface (API) or database schema, nor to write any new service or server-side code. The same hardware may be shared across many games. And the system scales linearly. That is, if the number of servers is doubled, then so is the number of concurrent users that can be supported.
  • Also disclosed are systems and methods for two-stage aggregation. Pre-aggregation may take place on a plurality of front-end servers. Final aggregation may take place on one or more back-end servers. A name value store may be used to reliably store state.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 depicts an example network-based game service.
  • FIG. 2 is a flowchart for employing scalable game service primitives in a network-based game service.
  • FIG. 3 is a block diagram of an example computing environment in which example embodiments and aspects of the present invention may be implemented.
  • FIG. 4 is an example network configuration in which aspects of the invention may be implemented.
  • DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
  • As shown in FIG. 1, an example network-based game service may include a plurality of front-end servers, one or more back-end servers, and a partitioned name/value store.
  • The front-end servers may be TCP/IP Socket Servers that dynamically load the pre-aggregation primitive code and custom game logic that may be referred to as “front-end controllers.” These front-end controllers process incoming messages from users and perform custom game logic on them, often storing the results in the name/value store. Front-End controllers may read and write from the name/value store.
  • The back-end servers similarly load back-end controllers. Back-end controllers do the final aggregation of pre-aggregated data (e.g., aggregating a sum for some data pre-aggregated and set by a plurality of front end servers) and performing other custom game logic including advancing a round. Back-end controllers read and write from the name/value store.
  • The name/value store is a partitioned sql database with a simple, single-table schema. The name/value table has two columns, one for name and one for value. The name is a string and the value is a binary blob, which may be an xml blob, for example. The store is partitioned on name. The name/value store does not provide transactions or record locking.
  • As shown in FIG. 2, users may post messages to the front end controllers at 52. The messages, each of which may have a name and an XML body, are pre-aggregated on the front-end servers.
  • At 54, messages are routed by name to the appropriate front end controllers.
  • At 56, the front end controllers execute on all the messages in a batch, often aggregating and writing the aggregate value to the name/value store.
  • At 58, the back-end servers run their controllers, periodically reading values from the name/value store and perhaps further aggregating the results and writing out the final values. So that the back end servers know which values to aggregate, a queuing mechanism may be employed to signal the back end server. The queuing mechanism may be polled periodically.
  • Consider an example of 200,000 game consoles playing a quiz-show game all at the same time. Each game console may connect to the data center through a secure gateway, and communicate using encrypted traffic. The game consoles may tunnel through the secure gateway to the plurality of front-end servers. The game consoles may connect using persistent TCP/IP connections rather than web service calls. To handle 200,000 game consoles, the system may include, say, 20 front-end servers, each to handle 10,000 game console clients.
  • Suppose that each of the 200,000 game consoles is answering the same question at the same time. Each game console submits its respective answer, and each front end gets 10,000 messages at same time.
  • Typically, each user will want to know whether he or she got the right answer. But the users might also want feedback that relies on answers provided by other users. For example, the users might want to know what percentage of respondents got the right answer, or who was first to answer correctly.
  • The individual game consoles may be programmed to determine whether the user got an answer right or wrong, and provide such an indication to the user. Each game console may keep score of how many answers the user of that console got right. Each game console may then communicate to the associated front-end server whether the user got the answer right or wrong. Data may then be aggregated on the back-end server.
  • Data is tracked in the system in accordance with name/value pairs. That is, every datum may have a name and a value associated with it. An example of a name might be game title, such as “trivia.quest.sessionid.questionno.right/wrong.” Values for this datum might be “right” and “wrong,” which could be represented as “0” and “1,” respectively.
  • Each front-end server does pre-aggregation (e.g., a summation for their subset of users), and writes the pre-aggregated value (e.g., a sum) out to the store. This process may be referred to as “pre-aggregation,” i.e., aggregation by the front-end server of input data provided by each of a plurality of clients associated with the front-end server. The back-end server grabs the list of sums and sums the sums to get a final sum of sums. Thus, the back-end server aggregates the data globally.
  • To accomplish this, the back-end servers need understand only a set of basic primitives. The console sends a name and value, and the back-end server sums all the values over that name. For example, a console might send a message with a name such as “question 7 right?” and a value of “1” or “0” (depending on whether the user got it right or not). The action (i.e., primitive) may be “sum.” After a prescribed period of wait time (e.g., six seconds), the game console may ask the front-end server to report back an aggregation from the universe of consoles. For example, the game console may send a message with name =“question 7 right?” and action (primitive)=“get.” In response, the back-end server may provide the aggregate value for that name (which, in this example, is the summation of the number right).
  • Note that the front-end server need not communicate directly with the back-end server. The front-end server may communicate values to the name/value store. The back-end server may pick up pre-aggregated values from the name/value store, and write aggregated values back. The back-end server may pick up aggregated values from the name/value store.
  • Example Computing Environment
  • FIG. 3 shows an exemplary computing environment in which example embodiments and aspects may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.
  • Numerous other general purpose or special purpose computing system environments or configurations may be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like.
  • Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.
  • With reference to FIG. 3, an exemplary system includes a general purpose computing device in the form of a computer 110. Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The processing unit 120 may represent multiple logical processing units such as those supported on a multi-threaded processor. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus). The system bus 121 may also be implemented as a point-to-point connection, switching fabric, or the like, among the communicating devices.
  • Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
  • The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 3 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.
  • The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 3 illustrates a hard disk drive 140 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156, such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
  • The drives and their associated computer storage media discussed above and illustrated in FIG. 3, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 3, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 20 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 195.
  • The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 3. The logical connections depicted in FIG. 3 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
  • When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 3 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
  • Network Environment
  • FIG. 4 illustrates an example network environment in which the present invention may be employed. Of course, actual network and database environments may be arranged in a variety of configurations; however, the example environment shown here provides a framework for understanding the type of environment in which an embodiment may operate.
  • The example network may include one or more client computers 200 a, a server computer 200 b, data source computers 200 c, and/or databases 270, 272 a, and 272 b. The client computers 200 a and the data source computers 200 c may be in electronic communication with the server computer 200 b by way of the communications network 280 (e.g., an intranet, the Internet or the like). The client computers 200 a and data source computers 200 c may be connected to the communications network by way of communications interfaces 282. The communications interfaces 282 can be any type of communications interfaces such as Ethernet connections, modem connections, wireless connections and so on.
  • The server computer 200 b may provide management of the database 270 by way of database server system software such as MICROSOFT®'s SQL SERVER or the like. As such, server 200 b may act as a storehouse of data from a variety of data sources and provides that data to a variety of data consumers.
  • In the example network environment of FIG. 4, a data source may be provided by data source computer 200 c. Data source computer 200 c may communicate data to server computer 200 b via communications network 280, which may be a LAN, WAN, Intranet, Internet, or the like. Data source computer 200 c may store data locally in database 272 a, which may be database server or the like. The data provided by data source 200 c can be combined and stored in a large database such as a data warehouse maintained by server 200 b.
  • Client computers 200 a that desire to use the data stored by server computer 200 b can access the database 270 via communications network 280. Client computers 200 a access the data by way of, for example, a query, a form, etc. It will be appreciated that any configuration of computers is equally compatible with an embodiment of the present invention.

Claims (20)

1. A network-based gaming system, comprising:
a plurality of front-end servers, each said front-end server executing thereon respective front-end controllers;
a back-end server; and
a partitioned name/value store,
wherein users are enabled to post messages to the front-end controllers, each said message having a respective name and body, messages are routed by name to the appropriate front-end controllers, the front-end controllers aggregate values from a batch of messages, and write the aggregated values to a persistent data store, and
wherein the back-end servers periodically read aggregated values from the data store, and write to the data store final values aggregated over the plurality of front-end servers.
2. The system of claim 1, wherein the front-end servers perform primitive logic on the incoming messages, store results in the data store, read from the data store, and supply aggregated results back to the users.
3. The system of claim 1, wherein the front-end servers are adapted to process incoming messages from users, to perform custom game logic on the incoming messages, to store results in the name/value store, and to read from the name/value store.
4. The system of claim 1, wherein the back-end servers are adapted to perform time-based operations and other custom game logic, and to read and write from the name/value store.
5. The system of claim 1, wherein the data store is a partitioned name/value store with a single-table schema.
6. The system of claim 5, wherein the single table is a name/value table having a first column for name and a second column for value.
7. In network-based gaming system comprising a plurality of front-end servers, each front-end server being associated with a respective plurality of game consoles, a single back-end server associated with the plurality of front-end servers, and a partitioned name/value store, a method comprising:
receiving at each of the front-end servers, a set of messages from the respective plurality of game consoles associated therewith, each said message having a respective name and XML body;
aggregating at each of the front-end servers values from the received messages;
writing the aggregated values from the front-end servers to the name/value store;
periodically reading the aggregated values at the back-end server from the name/value store; and
writing from the back-end server to the name/value store a final value aggregated over the plurality of front-end servers.
8. The method of claim 7, further comprising:
routing the messages by name to the front-end controllers.
9. The method of claim 7, further wherein data is tracked in the system in accordance with name/value pairs.
10. The method of claim 7, wherein each front-end server performs pre-aggregation of input data provided by each of the plurality of clients associated with the front-end server.
11. The method of claim 10, wherein the back-end server aggregates the data globally.
12. The method of claim 11, wherein the aggregation is performed using a set of basic primitives.
13. A network-based gaming system, comprising:
a plurality of front-end servers, each said front-end server executing thereon respective front-end controllers;
a back-end server; and
a partitioned name/value store,
wherein each front-end server performs pre-aggregation of input data provided by each of a plurality of clients associated with the front-end server,
wherein the back-end server aggregates the data globally, and
wherein the aggregation is performed using a set of basic primitives.
14. The system of claim 13, wherein users are enabled to post messages to the front-end servers, each said message having a respective name and XML body.
15. The system of claim 14, wherein each message contains a respective value associated with said name, and the back-end server aggregates the data by summing the values over a set of messages containing the name.
16. The system of claim 13, wherein the set of primitives includes at least get and set primitives.
17. The system of claim 13, wherein the set of primitives includes at least sum and get primitives.
18. The system of claim 13, wherein the front-end server communicates pre-aggregated values to the name/value store, and does not communicate directly with the back-end server.
19. The system of claim 18, wherein the back-end server picks up pre-aggregated values from the name/value store, and writes aggregated values back to the name/value store.
20. The system of claim 19, wherein the back-end server picks up the aggregated values from the name/value store for communication to the users.
US12/341,481 2008-12-22 2008-12-22 Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data Abandoned US20100160047A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/341,481 US20100160047A1 (en) 2008-12-22 2008-12-22 Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/341,481 US20100160047A1 (en) 2008-12-22 2008-12-22 Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data

Publications (1)

Publication Number Publication Date
US20100160047A1 true US20100160047A1 (en) 2010-06-24

Family

ID=42266933

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/341,481 Abandoned US20100160047A1 (en) 2008-12-22 2008-12-22 Scalable Game Primitives / Distributed Real-Time Aggregation Of Player Data

Country Status (1)

Country Link
US (1) US20100160047A1 (en)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US791067A (en) * 1903-07-31 1905-05-30 John B Archer Process of burning fuel.
US5822523A (en) * 1996-02-01 1998-10-13 Mpath Interactive, Inc. Server-group messaging system for interactive applications
US6487556B1 (en) * 1998-12-18 2002-11-26 International Business Machines Corporation Method and system for providing an associative datastore within a data processing system
US6574241B2 (en) * 1998-10-14 2003-06-03 Nokia Corporation Message monitoring in a network element
US6993454B1 (en) * 2000-12-05 2006-01-31 Microsoft Corporation Performance logging solution
US7203623B2 (en) * 2000-11-10 2007-04-10 Microsoft Corporation Distributed data gathering and aggregation agent
US7315805B2 (en) * 2004-02-05 2008-01-01 Raytheon Company Operations and support discrete event stimulation system and method
US7774831B2 (en) * 2002-12-24 2010-08-10 International Business Machines Corporation Methods and apparatus for processing markup language messages in a network

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US791067A (en) * 1903-07-31 1905-05-30 John B Archer Process of burning fuel.
US5822523A (en) * 1996-02-01 1998-10-13 Mpath Interactive, Inc. Server-group messaging system for interactive applications
US6574241B2 (en) * 1998-10-14 2003-06-03 Nokia Corporation Message monitoring in a network element
US6487556B1 (en) * 1998-12-18 2002-11-26 International Business Machines Corporation Method and system for providing an associative datastore within a data processing system
US7203623B2 (en) * 2000-11-10 2007-04-10 Microsoft Corporation Distributed data gathering and aggregation agent
US6993454B1 (en) * 2000-12-05 2006-01-31 Microsoft Corporation Performance logging solution
US7774831B2 (en) * 2002-12-24 2010-08-10 International Business Machines Corporation Methods and apparatus for processing markup language messages in a network
US7315805B2 (en) * 2004-02-05 2008-01-01 Raytheon Company Operations and support discrete event stimulation system and method

Similar Documents

Publication Publication Date Title
Offsey Knowledge management: linking people to knowledge for bottom line results
Almeida et al. Are firms superior to alliances and markets? An empirical test of cross-border knowledge building
Graham et al. New platform, old habits? Candidates’ use of Twitter during the 2010 British and Dutch general election campaigns
Agrawal et al. Database management as a service: Challenges and opportunities
Tam et al. Building content-based publish/subscribe systems with distributed hash tables
Soh Network patterns and competitive advantage before the emergence of a dominant design
Hu et al. Scalable peer-to-peer networked virtual environment
JP5538510B2 (en) A user clustering rich scalable based on the similarity of the set
KR101545912B1 (en) Processor-accessible media and methods for facilitating flexible extended presence capabilities of instant messaging, document
US7454465B2 (en) Real-time collaboration and communication in a peer-to-peer networking infrastructure
Kohavi et al. Trustworthy online controlled experiments: Five puzzling outcomes explained
US7606839B2 (en) Systems and methods for providing client connection fail-over
US20070105624A1 (en) Online gaming cheating prevention system and method
US20120198004A1 (en) System and method for managing multiple queues of non-persistent messages in a networked environment
US6598077B2 (en) System and method for dynamic content routing
JP4499716B2 (en) The execution of the application in a peer-to-peer network
Kamvar et al. EigenRep: Reputation management in P2P networks
US9588851B2 (en) Locality based quorums
US20140108518A1 (en) Providing Personalized Platform Application Content
US8255548B2 (en) Offline web services API to mirror online web services API
US7930345B2 (en) Method for authenticating a user in an interactive gaming environment
US8226485B1 (en) Multiuser game with friend proxy automated characters
US20130110938A1 (en) Apparatus and method for matching users for online sessions
EP2843901B1 (en) Peer-to-peer relay network
US20100057700A1 (en) Systems and methods for hierarchical aggregation of multi-dimensional data sources

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION,WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIVNI, FELIX;MANNERS, LOWELL;HALL, GARY WILLIAM;AND OTHERS;REEL/FRAME:022497/0239

Effective date: 20090219

AS Assignment

Owner name: MICROSOFT CORPORATION,WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CHEN, TONY;REEL/FRAME:022683/0397

Effective date: 20090211

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034564/0001

Effective date: 20141014