U.S. Pat. No. 10,486,064

DETAILED DESCRIPTION

A system and method for capturing and sharing console gaming data is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments. It is apparent to one skilled in the art, however, that embodiments can be practiced without these specific details or with an equivalent arrangement. In some instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments.

Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views,FIG. 1is a flowchart illustrating a method for storing gameplay according to one embodiment. At processing block110, gameplay is executed. Gameplay can be executed by the operating system of a game console in response to a user request, which can come in the form of a standard file operation with respect to a set of data associated with the desired gameplay. The request can be transmitted from an application associated with a game. The gameplay can comprise, for example, video content, audio content and/or static visual content, including wall papers, themes, “add-on” content, or any other type of content associated with a game. It is contemplated that such content can be user- or developer-generated, free or paid, full or trial, and/or for sale or for rent.

At processing block120, a first portion of the gameplay is buffered, i.e., stored temporarily. For example, the previous 15 seconds, the previously completed level, or the previous action within the gameplay can be stored temporarily, as described further herein. The term “portion” used herein can correspond to any part of the gameplay that is divisible into any related or arbitrary groups of single or multiple bits or bytes of data. For example, “portions” of gameplay may correspond to levels, chapters, scenes, acts, characters, backgrounds, textures, courses, actions, songs, themes, durations, sizes, files, parts thereof, and combinations thereof. Further, portions of gameplay can comprise screenshots or prescribed durations of video capture.

At processing block130, a request to capture a second portion of the gameplay is received. The request to capture the second portion of the gameplay can be a user request, which can come in the form of a standard file operation with respect to a set of data associated with the gameplay to be captured. A user can request to capture a second portion of the gameplay by, for example, selecting a button on a game controller, as described further herein.

The second portion of the gameplay reflects gameplay subsequent to the first portion of the gameplay. In other words, the first portion of the gameplay reflects gameplay that occurred prior to receipt of the user request to capture the second portion of the gameplay. The second portion of the gameplay reflects gameplay that occurred after receipt of the user request to capture the second portion of the gameplay. Thus, the first portion of the gameplay is a past portion of the gameplay that has already been played, while the second portion of the gameplay begins with a current portion of the gameplay that is being executed.

At processing block140, the second portion of the gameplay is captured. In one embodiment, the second portion of the gameplay is captured according to the user's request. For example, if the user taps a capture button on the game controller, a screenshot or still picture can be taken. If the user holds down a capture button on a game controller, a video can be taken for the length of time the button is being held down. In other words, if the button is held down for 5 seconds, 5 seconds of the gameplay can be captured as the second portion of gameplay; if the button is held down for 10 seconds, 10 seconds of the gameplay can be captured; and so on. In another example, a screenshot or still picture can be taken if the user holds down a capture button, and a video can be taken if the user taps a capture button twice consecutively: once to start the capture, and again to end the capture.

At processing block150, the first and second portions of the gameplay are stored. In an embodiment in which the first and second portions of the gameplay are videos, the first portion of the gameplay can be attached to the second portion of the gameplay, such that a single video without interruption is created. In one embodiment, the first and second portions of the gameplay can be stored locally on the game console in either temporary or permanent storage. Alternatively or additionally, the first and second portions of the gameplay can be transmitted over a network and stored remotely. For example, the first and second portions of the gameplay can be transmitted over a wireless or wired network to another computing device, to another game console, or to a remote server. Such remote servers may include social media servers.

Optionally, portions of the gameplay not retrieved from the buffer or portions of the gameplay outside a particular gaming interval (e.g., a particular duration, level, chapter, course, etc.) can be removed from the buffer. This removal process can be completed using standard file operations on the operating system.

At optional processing block160, the first and second portions of the gameplay are displayed. The first and second portions of the gameplay can be displayed on any of a number of display devices having access to the stored gameplay. For example, the stored gameplay can be displayed on a television set connected to the game console from which the gameplay was captured. In another example, the stored gameplay can be displayed on a computer to which the stored gameplay was transmitted. The stored gameplay can be displayed alone or in conjunction with other information, such as on a social media website.

In one embodiment, the first and second portions of the gameplay are displayed by another game console associated with a user other than the user that buffered or captured the gameplay. According to this embodiment, the first and second portions of the gameplay may show a ball being thrown from a first user to a second user, from the point of view of the first user. The first and second portions of gameplay can then be transmitted to the game console of the second user. Thus, the second user can then view the gameplay from the point of view of the first user. The second user can also have third and fourth portions of gameplay stored showing the ball being thrown by the first user and caught by the second user, from the point of view of the second user. In this embodiment, the second user can review the gameplay from both the point of view of the first user and the point of view of the second user. Still further, the third and fourth portions of the gameplay can be transmitted to the game console of the first user, so that the first user may review the gameplay from two points of view. This embodiment can apply to any number of users having any number of points of view, so that gameplay can be reviewed from any number of different perspectives.

With respect to storage, transmission and/or display of the first and second portions of the gameplay as described herein, it is contemplated that the first and second portions of the gameplay can be stored, transmitted and displayed as image or video data. In another embodiment, however, the first and second portions of the gameplay can be stored and transmitted as telemetry or metadata representative of the image or video data, and can be recreated as images or video by a game console or other device prior to display.

In some embodiments, the first portion of the gameplay has a predetermined relationship with the executed gameplay. For example, the first portion of the gameplay can correspond to a certain amount of gameplay prior to the currently executing gameplay, such as the previous 10 seconds of gameplay. In another embodiment, the first portion of the gameplay has a predetermined relationship with the second portion of the gameplay. For example, the first portion of the gameplay can correspond to a certain amount of gameplay prior to receipt of a request to capture the second portion of gameplay, such as the 10 seconds of gameplay prior to selection of the capture button. In each of these embodiments, the amount of gameplay buffered prior to the current gameplay or the requested gameplay can be configured and adjusted by the user according to his or her particular preferences.

In other embodiments, the buffer is “smart” or “elastic”, such that it captures gameplay according to variables without regard to time. In one such embodiment, the first portion of the gameplay has a predetermined relationship with an event related to the gameplay. For example, the first portion of the gameplay may be buffered to include a statistical anomaly, such as a high score being reached, the gathering of a large number of points in a short amount of time, the multiple selections of buttons on a controller, and other rare events. Such statistical anomalies can be determined by comparing gameplay metrics to average metrics for a particular game or scene, or for all games generally. Such average metrics can be stored locally or remotely for comparison. For example, a game console can track local high scores for a particular game, and buffer gameplay in which a user approaches and surpasses that high score. In another example, a remote server can track global high scores for a particular game, and can communicate that information to the game console, which buffers gameplay in which the user approaches and surpasses that high score.

In another example, the first portion of the gameplay can be buffered to include an achievement, such as a trophy being attained or other landmark being reached. Such trophies or landmarks memorialize any goal or gaming achievement, such as a certain number of points being attained, a certain level being reached, and the like. For example, gameplay can be buffered to include the awarding of a trophy for reaching level 10, for reaching 100,000 points, etc.

Similarly, progress toward reaching an event, in addition to the actual attainment of the trophy or statistical anomaly, can be buffered to be included in the first portion of the gameplay. For example, a screenshot can be taken at each of levels 1 through 10, creating a photo album to memorialize the receipt of a trophy for reaching level 10. In another example, a video can be taken of a user winning a race for the first through fifth times, where a trophy is awarded for 5 wins.

Thus, according to the embodiment illustrated inFIG. 1, at least a portion of executed gameplay can always be kept in a running buffer. In other words, when a request to capture a portion of the gameplay is received, a portion of the prior gameplay can already be captured to include previous footage. For example, if a request to capture gameplay is received after a user crosses the finish line in a racing game, the buffered gameplay can include footage of the user crossing the finish line. In other words, a user will be able to capture moments occurring before a request is made to capture the gameplay.

FIG. 2is a flowchart illustrating a method for embedding information such as links into stored gameplay in accordance with one embodiment. At processing block210, stored gameplay and its associated gameplay metadata is retrieved. The stored gameplay may be gameplay or portions thereof stored on any medium. In one embodiment, the stored gameplay comprises the first and second portions of gameplay discussed above with respect toFIG. 1. Gameplay metadata may include, for example, the game title, game publisher, game developer, game distributor, game platform, game release date, game rating, game characters, game genre, game expansions, gameplay level or scene, length of stored gameplay, gameplay storage date, accessories used during gameplay, number of players, user ID of the user that captured the stored gameplay, user IDs of other users identified in the stored gameplay, and the like.

At processing block220, relevant links are identified based on the gameplay metadata. Relevant links may be hyperlinks, for example. In one embodiment, relevant links are automatically created and generated based on the gameplay metadata. This embodiment can be implemented where websites are named according to a particular naming convention. For example, if a game's website address is assigned according to http://us.playstation.com/games-and-media/games/TITLE-OF-GAME-PLATFORM.html, where TITLE-OF-GAME is replaced with the game's title and PLATFORM is replaced with the game's platform, the method according to this embodiment could pull the title of the game and the game platform from the gameplay metadata, and insert the data into the website address to generate a link. For example, for a game entitled “Sample Game” available on the PS3, the following link could be automatically generated: http://us.playstation.com/games-and-media/games/sample-game-ps3.html.

In another embodiment, relevant links are identified from a plurality of links provided by or available from the game console, the game itself, the gaming network, or a third party server. In this embodiment, relevant links can be selected based on their commonalities with the gameplay metadata. For example, relevant links could include links to the game title's store or purchase page, to the user profiles of other users identified in the stored gameplay, to an informational website about the game title, to a community website dedicated to the game title, to the user's trophy information, to downloadable content or game expansions used in the stored gameplay, to other videos of the same game title and/or game level, to other gameplay captured by the same user, to trailers of upcoming games in the same genre, to clan data, to contests, to advertisements, and the like.

At processing block230, one or more of the relevant links are embedded into the stored gameplay. In one embodiment, the relevant links are graphically or textually embedded into or overlaid on the screenshot or video itself. In another embodiment, the relevant links are embedded as text accompanying the screenshot or video.

At processing block240, the link-embedded gameplay is stored. In one embodiment, the link-embedded gameplay is stored locally on a game console in either temporary or permanent storage. Alternatively or additionally, the link-embedded gameplay can be transmitted over a network and stored remotely. For example, the link-embedded gameplay can be transmitted over a wireless or wired network to another computing device, to another game console, or to a remote server. Such remote servers may include social media servers.

At optional processing block240, the link-embedded gameplay is displayed. The link-embedded gameplay can be displayed on any of a number of display devices having access to and capability to display the link-embedded gameplay. For example, the link-embedded gameplay can be displayed on a television set connected to the game console from which the gameplay was captured. In another example, the link-embedded gameplay can be displayed on a computer to which the stored gameplay was transmitted. The link-embedded gameplay can be displayed alone or in conjunction with other information, such as on a social media website.

In one embodiment, the “sharing” of link-embedded gameplay by users can be encouraged by providing an incentive program. For example, the number of clicks of the relevant links can be tracked. In another example, where the link-embedded gameplay contains a link to a purchase website for the game, the number of game purchases can be tracked. These numbers can then be used to reward users for sharing and distributing link-embedded gameplay. In still another example where the link-embedded gameplay contains a link to a purchase website for the game, a discount on the game can be provided to those users clicking through link-embedded gameplay to encourage purchase of the game and distribution of the link-embedded gameplay.

FIG. 3is a flowchart illustrating a method for embedding information such as user IDs into stored gameplay in accordance with one embodiment. At processing block310, stored gameplay and gameplay metadata is retrieved. The stored gameplay may be gameplay or portions thereof stored on any medium. In one embodiment, the stored gameplay comprises the first and second portions of gameplay discussed above with respect toFIG. 1. In another embodiment, the stored gameplay is the gameplay embedded with relevant links discussed above with respect toFIG. 2. Gameplay metadata according to this embodiment includes at least one of the user ID of the user that captured the stored gameplay, and the user ID(s) of other user(s) present in the captured gameplay. The other user(s) present in the captured gameplay can be local users, such as a second user in a two player game connected to the same game console as the first user, or can be remote users, such as networked users connected to a different game console than the first user participating in a partially- or fully-online implemented game.

At processing block320, user IDs are identified from the gameplay metadata. At processing block330, the user IDs are embedded into the stored gameplay. In one embodiment, the user IDs are graphically or textually embedded into or overlaid on the screenshot or video itself. In this embodiment, the user IDs can be embedded into or overlaid on their associated graphical representations. For example, if User_1 is represented by a red car in the stored gameplay, and User_2 is represented by a blue car in the stored gameplay, the tag “User_1” can be overlaid on or otherwise associated with the red car, and the tag “User_2” can be overlaid on or otherwise associated with the blue car. In another embodiment, the user IDs are embedded as text accompanying the screenshot or video. In the latter embodiment, the accompanying text can be text intended to be displayed, such as a description or title, or can be text intended to be invisible upon display, such as embedded gameplay metadata. It is contemplated that the accompanying text can be searchable.

At processing block340, the ID-embedded gameplay is stored. In one embodiment, the ID-embedded gameplay is stored locally on a game console in either temporary or permanent storage. Alternatively or additionally, the ID-embedded gameplay can be transmitted over a network and stored remotely. For example, the ID-embedded gameplay can be transmitted over a wireless or wired network to another computing device, to another game console, or to a remote server. Such remote servers may include social media servers.

At processing block350, the ID-embedded gameplay is displayed. The ID-embedded gameplay can be displayed on any of a number of display devices having access and capability to display the ID-embedded gameplay. For example, the ID-embedded gameplay can be displayed on a television set connected to the game console from which the gameplay was captured. In another example, the ID-embedded gameplay can be displayed on a computer to which the stored gameplay was transmitted.

The ID-embedded gameplay can be displayed alone or in conjunction with other information, such as on a social media website. When displayed on a social media website, it is contemplated that the user tags can be compatible with the websites, such that the tags carry over to the social media website. Thus, according to the embodiment described with respect toFIG. 3, the need to manually tag gameplay media with user ID's is eliminated by making the process automatic.

FIG. 4illustrates a system for effecting the acts of one or more of the methodologies described herein. Server410is connected over network440to a user device450. Server410includes processor420and memory430, which are in communication with one another. Server410is typically a computer system, and may be an HTTP (Hypertext Transfer Protocol) server, such as an Apache server. It is contemplated, however, that server410can be a single or multiple modules or devices hosting downloadable content or portions thereof. Further, server410can be a dedicated server, a shared server, or combinations thereof. For example, server410can be a server associated with the developer, publisher or distributor of the application460, or a third-party server, such as a peer device in a peer-to-peer (P2P) network. In addition, server410can comprise a virtual market or online shopping-based service offering the application460. In this embodiment, server410(alone or in combination with other devices) can process and perform various commercial transactions, such as billing, in addition to those acts described herein.

User device450includes application460, input device465, operating system470, processor480, and memory490, which are in communication with one another. In one embodiment, user device450is a game console. In that embodiment, application460may be a game, and input device465may be a controller. Server410and user device450are characterized in that they are capable of being connected to network440. Network440can be wired or wireless, and can include a local area network (LAN), wide area network (WAN), a telephone network (such as the Public Switched Telephone Network (PSTN)), a radio network, a cellular or mobile phone network (such as GSM, GPRS, CDMA, EV-CO, EDGE, 3GSM, DECT, IS-136/TDA, iDEN, and the like), intranet, the Internet, or combinations thereof. Memory430and memory490may be any type of storage media that may be volatile or non-volatile memory that includes, for example, read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, zip drives, and combinations thereof. Memory430and memory490can be capable of permanent or temporary storage, or both; and can be internal, external, or both.

In use, application460makes calls to operating system470to load and access data stored in memory490, using standard file operations. Application460can be any software and/or hardware that provides an interface between a user of user device450(via input device465) and operating system470. The standard file operations include, for example, “open” (i.e., specifying which file is to be accessed), “seek” (i.e., specifying what position to go to in the file to read data), “read” (i.e., requesting that data be read from the file and copied to application460), and “close” (i.e., requesting that the file be closed for now).

FIG. 5shows a diagrammatic representation of machine in the exemplary form of computer system500within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, as a host machine, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, a game console, a television, a CD player, a DVD player, a BD player, an e-reader, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

According to some embodiments, computer system500comprises processor550(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), main memory560(e.g., read only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.) and/or static memory570(e.g., flash memory, static random access memory (SRAM), etc.), which communicate with each other via bus595.

According to some embodiments, computer system500may further comprise video display unit510(e.g., a liquid crystal display (LCD), a light-emitting diode display (LED), an electroluminescent display (ELD), plasma display panels (PDP), an organic light-emitting diode display (OLED), a surface-conduction electron-emitted display (SED), a nanocrystal display, a 3D display, or a cathode ray tube (CRT)). According to some embodiments, computer system500also may comprise alphanumeric input device515(e.g., a keyboard), cursor control device520(e.g., a controller or mouse), disk drive unit530, signal generation device540(e.g., a speaker), and/or network interface device580.

Disk drive unit530includes computer-readable medium534on which is stored one or more sets of instructions (e.g., software536) embodying any one or more of the methodologies or functions described herein. Software536may also reside, completely or at least partially, within main memory560and/or within processor550during execution thereof by computer system500, main memory560and processor550. Processor550and main memory560can also constitute computer-readable media having instructions554and564, respectively. Software536may further be transmitted or received over network590via network interface device580.

While computer-readable medium534is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the disclosed embodiments. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.

It should be understood that processes and techniques described herein are not inherently related to any particular apparatus and may be implemented by any suitable combination of components. Further, various types of general purpose devices may be used in accordance with the teachings described herein. It may also prove advantageous to construct a specialized apparatus to perform the methods described herein. Those skilled in the art will appreciate that many different combinations of hardware, software, and firmware will be suitable for practicing the disclosed embodiments.

Embodiments have been described in relation to particular examples, which are intended in all respects to be illustrative rather than restrictive. Further, while embodiments have been described in connection with a number of examples and implementations, it is understood that various modifications and equivalent arrangements can be made to the examples while remaining within the scope of the inventive embodiments.

Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. Various aspects and/or components of the described embodiments may be used singly or in any combination. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.