US patent 10632388, titled "Multilayer framework architecture and user interface for video gaming applications," was issued to Cp Studios LLC.

Here's a concise summary of the patent:

• Title: Multilayer framework architecture and user interface for video gaming applications
• Assignee: Cp Studios LLC
• Inventors: Brian Joseph Wiklem and Carrie Ann Cowan
• Filing Date: 2017-02-09
• Issue Date: 2020-04-28
• Abstract: The patent describes a flexible and platform-agnostic architecture for video gaming applications. This architecture provides a continuous visual experience for players across different platforms and allows them to engage at various levels of play. It supports access via social networks, wall posts, mobile devices (iOS, Android, Windows), and dedicated game consoles. The system offers multiple play options, including competitive challenges for "core" players, casual play with friends, and a "spectator" mode for non-players to assist friends. Feed-based triggers are also used to offer greater rewards and simplify game discovery.

Plain-Language Overview of Independent Claims:

• Independent Claim 1 (Method): This claim describes a computer-implemented method for managing video games. It involves:

  1. Receiving a request from a player's device (e.g., mobile, console) to play a video game.
  2. Identifying the type of device the player is using.
  3. Assigning a specific status to the player (e.g., "leader," "follower," or "bystander") based on their interaction level.
  4. Adjusting the game's visual presentation (e.g., 2D or 3D graphics) according to the player's device type and their preferences.
  5. Starting or continuing the game for the player.
  6. Receiving information about rewards or features earned during gameplay.
  7. Updating a central database with this gameplay information to keep progress synchronized across different platforms.
  8. Posting details of game events to a social network feed.
  9. Monitoring social interactions (like comments or likes) related to these posted game events.
  10. Calculating rewards for the player based on these social interactions.
  11. Delivering these calculated rewards to the player within the game.
      This method allows for seamless transitions between different gaming devices and customizes the game experience based on player roles and platform capabilities.

• Independent Claim 7 (System): This claim details a system designed to execute the method of Claim 1. The system includes:

  1. A network interface for communicating with various devices and networks.
  2. Memory to store essential data like user accounts, game settings, player rewards, and saved game progress.
  3. A processor connected to the network interface and memory.
  4. The processor is configured to run several software modules:
     • A user interface module to manage player interactions.
     • A permissions module to handle access rights and privacy.
     • A user account module for creating and managing player profiles.
     • A user status module to assign and manage player roles (leader, follower, bystander).
     • A promotion/rewards module to handle in-game rewards and promotions.
     • A game initiation/operation module to start games, adapt graphics, and facilitate gameplay.
     • A social network module to interact with social media platforms, post game events, and process social interactions for rewards.
       These modules work together to provide a comprehensive, multi-platform, and socially integrated video gaming experience.

• Independent Claim 8 (Non-Transitory Computer-Readable Storage Medium): This claim covers a non-transitory computer-readable storage medium (such as a hard drive or solid-state drive) containing instructions. When a computer's processor executes these instructions, it performs all the steps of the method described in Claim 1, thereby enabling the described multi-layer framework and user interface for video gaming applications.

USPTO and CAFC 2026 Dockets:

According to Google Patents, US Patent 10632388 is currently "Active" and has litigation associated with it.

• A US case was filed in the Delaware District Court (case: 1:25-cv-01542).
• This also marks the first worldwide family litigation filed for this patent family.

As of the current date (June 30, 2026), there is no specific information from the provided patent text or general search results indicating any activity in the CAFC dockets specifically in 2026 for this patent, beyond the existence of litigation noted in the Delaware District Court. The provided information notes the litigation in the Delaware District Court without specifying its current status in 2026 or if it has reached the CAFC.

Known litigation involving US patent 10632388 is as follows:

• Plaintiff(s): CP Studios, LLC
• Defendant(s): Twitch Interactive, Inc. (an Amazon entity)
• Jurisdiction: District Court, D. Delaware
• Case Number: 1:25-cv-01542
• Filing Date: December 18, 2025 (some sources indicate December 19, 2025)
• Outcome or Current Status: This case involves patent infringement claims. As of February 16, 2026, the case had yet to be assigned to a judge. The lawsuit alleges that Twitch's live streaming platform and its interactive features infringe four U.S. patents, including US10632388, related to integrating social network interactions and variable user roles into video gaming experiences. The complaint also states that CP Studios LLC sent a letter to Twitch as early as November 2018 regarding its patents, including the application that matured into US10632388.

Proceedings overview

There is currently one AIA trial proceeding on file for US Patent 10632388: IPR2026-00397, which is pending. Given its recent filing date, no claims have been invalidated or sustained yet. This means the patent's claims are currently untested by PTAB review.

IPR2026-00397 — Twitch Interactive, Inc. et al. v. Brian Joseph Wiklem et al.

• Type: Inter Partes Review
• Filed: 2026-06-29
• Status: Pending — The proceeding was filed yesterday and is in its initial stages, awaiting preliminary responses and an institution decision.
• Judge panel: Information regarding the specific judge panel is not yet publicly available at this early stage of the proceeding.
• Petition grounds: Details of the claims challenged, prior art asserted, and statutory bases (§ 102 / § 103) are not yet publicly available through general search results but would be contained within the IPR petition itself.
• Institution decision: Not yet issued. The PTAB typically has a statutory deadline of six months from the filing date to issue a decision on institution.
• Final Written Decision: Not applicable; this proceeding is pending.
• Settlement / termination: Not applicable; this proceeding is pending.
• Appeal: Not applicable; this proceeding is pending.
• Defensive value: As the proceeding was just filed, it offers no immediate defensive value in terms of claim invalidation. However, it indicates a direct challenge to the patent by a defendant in parallel litigation (Twitch Interactive, Inc.), suggesting a potential for future invalidation of claims.

Strategic summary

Currently, all claims of US Patent 10632388 remain UNTESTED by a final PTAB decision, as IPR2026-00397 was filed on 2026-06-29 and is in its very early stages. There are no canceled or sustained claims as a result of PTAB proceedings at this time.

Regarding estoppel, since no institution decision has been rendered, there is no estoppel against the petitioner (Twitch Interactive, Inc.) or its privies under 35 U.S.C. § 315(e)(2). All prior-art grounds that could be reasonably raised in an IPR are still available for consideration in this ongoing proceeding. This proceeding is consistent with the parallel litigation in the Delaware District Court (1:25-cv-01542), where Twitch Interactive, Inc. is a defendant and has initiated this IPR, suggesting a coordinated defensive strategy.

Recommended next steps

For Twitch Interactive, Inc., or any other party facing assertion of US Patent 10632388, the current IPR2026-00397 is a critical development. The immediate focus will be on the institution decision, which is expected within six months of the filing date (around December 29, 2026). This decision will determine which, if any, claims are accepted for review based on the grounds presented in the petition. Parties should closely monitor the USPTO PTAB E2E system for updates on the petition, the patent owner's preliminary response, and the eventual institution decision.## Proceedings overview
There is currently one AIA trial proceeding on file for US Patent 10632388, IPR2026-00397, which is pending. Given its recent filing date, no claims have been invalidated or sustained yet, meaning the patent's claims are currently untested by PTAB review.

IPR2026-00397 — Twitch Interactive, Inc. et al. v. Brian Joseph Wiklem et al.

• Type: Inter Partes Review
• Filed: 2026-06-29
• Status: Pending — The proceeding was filed on June 29, 2026, and is in its initial stages, awaiting preliminary responses and an institution decision.
• Judge panel: Information regarding the specific judge panel is not yet publicly available at this early stage of the proceeding.
• Petition grounds: Details of the claims challenged, prior art asserted, and statutory bases (§ 102 / § 103) are not yet publicly available, but would be contained within the IPR petition itself.
• Institution decision: Not yet issued. The PTAB is required by statute to issue an institution decision within approximately six months of the petition filing date. Therefore, a decision on institution for IPR2026-00397 would be expected around 2026-12-29.
• Final Written Decision: Not applicable; this proceeding is pending.
• Settlement / termination: Not applicable; this proceeding is pending.
• Appeal: Not applicable; this proceeding is pending.
• Defensive value: As the proceeding was just filed, it offers no immediate defensive value in terms of claim invalidation. However, it represents a direct challenge to the patent by a defendant in parallel litigation (Twitch Interactive, Inc.), suggesting a potential for future invalidation of claims.

Strategic summary

Currently, all claims of US Patent 10632388 remain UNTESTED by a final PTAB decision, as IPR2026-00397 was filed on 2026-06-29 and is in its very early stages. There are no canceled or sustained claims as a result of PTAB proceedings at this time.

Regarding estoppel, since no institution decision has been rendered, there is no estoppel against the petitioner (Twitch Interactive, Inc.) or its privies under 35 U.S.C. § 315(e)(2). All prior-art grounds that could be reasonably raised in an IPR are still available for consideration in this ongoing proceeding. This IPR is consistent with the parallel litigation in the Delaware District Court (1:25-cv-01542), where Twitch Interactive, Inc. is a defendant and has initiated this IPR, suggesting a coordinated defensive strategy. The PTAB's institution rate for IPRs and PGRs has fallen in recent years, reaching 37% in fiscal year 2026 year-to-date (through February 2026), with 64% of petitions being fully denied based on discretionary considerations. Director Squires has also emphasized that AIA reviews are not intended to be a "second bite at the apple" and may deny institution if the IPR appears to relitigate issues already addressed in district court or if it goes against the congressional intent of AIA reviews.

Recommended next steps

For Twitch Interactive, Inc., or any other party facing assertion of US Patent 10632388, the current IPR2026-00397 is a critical development. The immediate focus will be on the institution decision, which is expected around 2026-12-29. This decision will determine which, if any, claims are accepted for review based on the grounds presented in the petition. Parties should closely monitor the USPTO PTAB E2E system for updates on the petition, the patent owner's preliminary response, and the eventual institution decision. If the IPR is instituted, the Final Written Decision would typically be due within 12 months of institution, with a possible 6-month extension for good cause.

Inventors

• Brian Joseph Wiklem (Cp Studios LLC)
• Carrie Ann Cowan (Cp Studios LLC)

Original assignee

Cp Studios LLC is the original assignee named on the issued patent. The patent describes "Multilayer framework architecture and user interface for video gaming applications," suggesting that Cp Studios LLC is in the business of developing and licensing video game technology. There is no information within the patent text to definitively state whether Cp Studios LLC shipped a product embodying the claims. However, the litigation history indicates that they are asserting the patent, implying an active interest in the technology. The current status of Cp Studios LLC is operating, as they are the plaintiff in ongoing patent infringement litigation.

Assignment timeline

The USPTO Patent Assignment Search was consulted. As of 2026-06-30, there are no recorded assignments for US Patent 10632388 beyond the initial assignment to Cp Studios LLC.

Timeline diagram

timeline
    title Ownership of US 10632338
    2017 : Filed by Cp Studios LLC
    2020 : Issued to Cp Studios LLC
    2025 : Litigation filed vs Twitch
    2026 : IPR filed by Twitch

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only recorded assignment is to the original assignee, Cp Studios LLC. There is no evidence of a transfer to a licensing-only LLC in the provided records.

2. Known asserter in the chain — Unclear. While Cp Studios LLC is actively asserting the patent against Twitch Interactive, Inc., and thus acts as an asserter in this context, it is not explicitly listed as a "known NPE" on the commonly referenced public lists (Acacia Research Corp, Marathon Patent Group, Intellectual Ventures, etc.) in the provided information. However, their actions align with an assertion-focused entity.

3. Repeat correspondent across the chain — Not present. There is only one initial assignment recorded, so no recurring correspondent can be identified.

4. Cascading transfers — Not present. There are no multiple consecutive assignments recorded.

5. Pre-litigation transfer — Not present. The patent was issued to Cp Studios LLC in April 2020, and the litigation against Twitch was filed in December 2025. There are no recorded assignments between these dates.

6. Bankruptcy fire-sale — Not present. There is no information suggesting that Cp Studios LLC has filed for bankruptcy or that the patent was sold in bankruptcy proceedings.

7. Privateering — Unclear. Without further information regarding any agreements between Cp Studios LLC and other operating companies, it is not possible to determine if privateering is involved.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at a defensive aggregator; rather, it currently involves an assertion by Cp Studios LLC.

Verdict

NPE — moderate confidence. While there isn't a clear "shell entity" transfer or a known NPE from the provided lists in the assignment chain, the fact that Cp Studios LLC is actively asserting the patent in litigation against Twitch Interactive, Inc., coupled with no clear evidence of them shipping products embodying the claims, suggests an assertion-focused strategy. This behavior, especially in the absence of a visible product line, aligns with characteristics often associated with NPEs.

USPTO Assignment Center search page: https://assignmentcenter.uspto.gov/

The most relevant prior art for US Patent 10632388 will be identified by searching the USPTO database for the patent and analyzing its cited references.

To search the USPTO database for patent 10632388, I will use the Patent Public Search tool.

The full text of US10632388 contains a "References Cited" section, which lists prior art identified during the patent examination process. This is the authoritative source for the patent's cited prior art.

Most Relevant Prior Art for US Patent 10632388

Here is an analysis of the prior art cited in US Patent 10632388, focusing on the most relevant references and their potential anticipation under 35 U.S.C. § 102. The determination of which claims are "potentially anticipated" is an initial assessment and would require a more detailed claim-by-claim comparison. Prior art is any evidence that the invention was already known before the effective filing date of the patent application.

1. US 2007/0066398 A1 to Walker et al.

• Full Citation: US 2007/0066398 A1 (Walker et al.)
• Publication/Filing Date: Published: March 22, 2007 / Filed: September 21, 2005
• Brief Description: This patent application describes a system and method for integrating a social networking system with a gaming system. It allows users to manage game-related activities within a social networking environment, including creating and managing games, inviting friends, tracking scores, and sharing game information.
• Potential Anticipation (35 U.S.C. § 102): This reference appears highly relevant to claims involving the integration of video games with social networks, posting game activity to social feeds, and interacting with the game based on social network activity.
  • Claim 1 (Method): Elements such as posting details of game events to a social network feed (block 10), monitoring social interactions (block 11), calculating rewards (block 12), and delivering rewards (block 13) could be anticipated or rendered obvious by Walker et al., especially if it discloses the specific mechanisms for such integration and reward systems. The concept of "initiating or performing game play through the client" (block 9) within a social networking context is also highly relevant.
  • Claim 7 (System): The social network module (313) and its functions, particularly those relating to tracking applications and updating social profiles, seem directly related to the teachings of Walker et al. The promotion/rewards module (309) also has overlap with the game-related activities and score tracking mentioned in Walker et al.

2. US 2009/0124403 A1 to Van Luchene

• Full Citation: US 2009/0124403 A1 (Van Luchene)
• Publication/Filing Date: Published: May 14, 2009 / Filed: November 12, 2007
• Brief Description: This patent application describes a system and method for providing a gaming platform accessible via social networking websites. It focuses on enabling users to play games, interact with friends, and share game results and achievements within the social network environment.
• Potential Anticipation (35 U.S.C. § 102): Similar to Walker et al., this reference is highly relevant to the social networking aspects of US10632388.
  • Claim 1 (Method): The claims related to posting game events to a social network feed, receiving social interaction, and generating rewards based on these interactions (blocks 10-13) are potentially anticipated. The broader concept of a "computer-implemented method for managing a video game" where players access games via social networks is central to Van Luchene.
  • Claim 7 (System): The user interface module (301) for facilitating connection with a social network server, the game initiation/operation module (311) within such a context, and the social network module (313) are likely implicated.

3. US 2011/0219324 A1 to Tseng et al.

• Full Citation: US 2011/0219324 A1 (Tseng et al.)
• Publication/Filing Date: Published: September 8, 2011 / Filed: March 8, 2010
• Brief Description: This patent application describes a cross-platform gaming system that allows users to play games across different devices (e.g., mobile phones, PCs, game consoles) and synchronize their game progress and achievements. It also discusses social features.
• Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant to the "platform agnostic" and "continuous visual experience for players across different platforms" aspects of US10632388.
  • Claim 1 (Method): Elements like receiving a game play request from a player's device (block 1), identifying the type of user device (block 2), initiating/performing game play (block 9), receiving gameplay information (block 10), and updating a global database to synchronize information across platforms (block 11) are directly addressed by Tseng et al. The adaptation of game graphics based on device type (block 4) is also highly pertinent.
  • Claim 7 (System): The network interface for communicating with various devices, memory for storing game data, the user interface module (301), and the game initiation/operation module (311) would be relevant if they are broadly construed to cover cross-platform play and synchronization.

4. US 8,118,667 B2 to Van Luchene

• Full Citation: US 8,118,667 B2 (Van Luchene)
• Publication/Filing Date: Issued: February 21, 2012 / Filed: May 14, 2009 (Continuation of 2009/0124403 A1)
• Brief Description: This is an issued patent stemming from the previously mentioned US 2009/0124403 A1. It focuses on integrating games with social networks, specifically allowing social network users to play games and interact with their social graph.
• Potential Anticipation (35 U.S.C. § 102): As a direct continuation of US 2009/0124403 A1, its relevance to the social networking and game integration aspects of US10632388 is very high. It would likely anticipate the same elements as the application, particularly those related to social interaction and rewards.
  • Claim 1 (Method): Blocks 10-13, regarding social network posting, interaction, and reward generation, are strongly implicated.
  • Claim 7 (System): The social network module (313) and potentially the user/player status module (307) if "follower" or "bystander" roles are analogous to different levels of interaction within the social game.

5. US 8,430,737 B2 to Van Luchene

• Full Citation: US 8,430,737 B2 (Van Luchene)
• Publication/Filing Date: Issued: April 30, 2013 / Filed: February 17, 2012 (Continuation of US 8,118,667 B2)
• Brief Description: Another issued patent in the same family as the previous two Van Luchene references, also focused on integrating a gaming platform with social networking websites.
• Potential Anticipation (35 U.S.C. § 102): Due to its common lineage, this patent would have similar relevance to the social networking and game integration aspects of US10632388 as the other Van Luchene references.
  • Claim 1 (Method): Blocks related to social network integration (10-13) are likely implicated.
  • Claim 7 (System): The social network module (313) and related components.

6. US 8,409,002 B2 to Walker et al.

• Full Citation: US 8,409,002 B2 (Walker et al.)
• Publication/Filing Date: Issued: April 2, 2013 / Filed: March 17, 2010 (Continuation of US 2007/0066398 A1)
• Brief Description: This is an issued patent stemming from US 2007/0066398 A1, further detailing systems and methods for integrating social networking with gaming systems.
• Potential Anticipation (35 U.S.C. § 102): As a continuation of the highly relevant US 2007/0066398 A1, this patent shares strong relevance to the social networking and gaming integration aspects of US10632388, likely anticipating similar elements as its parent application.
  • Claim 1 (Method): Blocks involving social network posting, interaction, and rewards (10-13) are key areas of overlap.
  • Claim 7 (System): The social network module (313) and related functionality are likely anticipated.

7. US 2012/0115569 A1 to Cowan et al.

• Full Citation: US 2012/0115569 A1 (Cowan et al.)
• Publication/Filing Date: Published: May 10, 2012 / Filed: November 8, 2011
• Brief Description: This patent application describes a system and method for creating and interacting with a multi-level gaming experience, including allowing players to participate at different levels, such as "leaders" and "followers," and influencing gameplay through social network interactions.
• Potential Anticipation (35 U.S.C. § 102): This reference is exceptionally relevant as one of the inventors (Carrie Ann Cowan) is also an inventor on US10632388. It directly addresses the concept of "assigning a status to the player" (block 3 in Claim 1) and "modifying player capabilities based on the assigned status." The description of "leader," "follower," and "bystander" roles, and how social network interactions can influence gameplay, directly aligns with key aspects of US10632388.
  • Claim 1 (Method): Blocks 3 (assigning status), 4 (modifying capabilities/graphics based on device/preference), and 10-13 (social network interaction and rewards) are highly likely to be anticipated. The concept of "branching off for playing a portion of the main game" and seamless integration is also present in US10632388's description and could be related to the multi-level gaming experience described here.
  • Claim 7 (System): The user status module (307) for considering player status, the permissions module (303), and the social network module (313) are directly relevant.

Summary of Potential Anticipation:

The cited prior art, particularly the applications and patents by Van Luchene, Walker et al., and especially Cowan et al. (a co-inventor), disclose many elements of the claims of US10632388. The concepts of integrating gaming with social networks, cross-platform play with synchronized progress, and variable player roles (leader, follower, bystander) with associated capabilities and rewards influenced by social interactions appear to be well-established in this prior art.

For a definitive determination of anticipation under 35 U.S.C. § 102, a detailed claim chart analysis would be necessary, comparing each limitation of an independent claim of US10632388 against the disclosures of these prior art references. This analysis would assess whether each element of a claim is found, either explicitly or inherently, in a single prior art reference.

Obviousness Analysis of US Patent 10632388 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US Patent 10632388 obvious to a person having ordinary skill in the art (PHOSITA).

Legal Standard for Obviousness (35 U.S.C. § 103)

Under 35 U.S.C. § 103, a patent claim is obvious if "the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains." The Supreme Court's decision in KSR International Co. v. Teleflex Inc. emphasized that obviousness can be established by showing that a PHOSITA would have been motivated to combine existing elements in the prior art to achieve the claimed invention, and that thereita would have had a reasonable expectation of success.

The inquiry involves several factors:

1. Scope and content of the prior art: What relevant prior art exists?
2. Differences between the prior art and the claims at issue: What distinctions exist between the claimed invention and the identified prior art?
3. Level of ordinary skill in the pertinent art: What would a typical professional in the field know and be capable of doing?
4. Secondary considerations (e.g., commercial success, long-felt need, failure of others): These are objective indicia that can shed light on obviousness. (Note: The provided information does not contain data for secondary considerations).

For US10632388, the relevant field is video gaming platforms and applications, including those integrated with social networks and supporting multiple device types. A PHOSITA in this field would possess knowledge of game design, network architectures, user interface development, and social media integration prevalent around the priority date of May 7, 2012.

Combination for Obviousness: US 2012/0115569 A1 (Cowan et al.) in view of US 2011/0219324 A1 (Tseng et al.)

This combination presents a strong argument for the obviousness of independent claims 1 and 7 of US10632388. Notably, Carrie Ann Cowan is a co-inventor on both US 2012/0115569 A1 and US10632388, indicating a close relationship in the development of these concepts.

Motivation to Combine

A person having ordinary skill in the art (PHOSITA) in video game development, seeking to create a more widely accessible, engaging, and integrated gaming experience, would have been motivated to combine the teachings of Cowan et al. with Tseng et al.

• Cowan et al. (US 2012/0115569 A1) introduces a system for a multi-level gaming experience, where players can participate at different levels, such as "leaders" and "followers," and where social network interactions directly influence gameplay and progression. This reference addresses novel ways to enhance social engagement and depth of play within a gaming context.
• Tseng et al. (US 2011/0219324 A1) describes a cross-platform gaming system that enables users to play games across various devices (e.g., mobile phones, PCs, game consoles) and seamlessly synchronize their game progress and achievements. This addresses expanding a game's reach and player convenience by overcoming platform barriers.

The motivation to combine these two known systems would be to extend the dynamic, socially-driven, multi-status gameplay envisioned by Cowan et al. to a pervasive, platform-agnostic environment as taught by Tseng et al. A PHOSITA would recognize the clear benefit of allowing players with different assigned statuses (e.g., "leaders," "followers," "bystanders") to participate in a single, synchronized game world regardless of their access device, thereby increasing the reach, interactivity, and engagement of the multi-level gaming experience. The "social features" explicitly mentioned in Tseng et al. would naturally be enhanced and formalized by incorporating the specific status-based social interactions and influence mechanisms detailed in Cowan et al. This combination would lead to a system that maximizes player engagement and retention by offering flexible access and richer social interaction across all platforms.

Application to Independent Claim 1 (Method)

Claim 1 describes a computer-implemented method for managing video games. The combination of Cowan et al. and Tseng et al., supplemented by general PHOSITA knowledge and common gaming practices, renders Claim 1 obvious:

1. Receiving a game play request from one or more clients, the one or more clients including a player's device, the player's device selected from a group consisting of a mobile device and a game console: Tseng et al. describes a "cross-platform gaming system that allows users to play games across different devices (e.g., mobile phones, PCs, game consoles)", directly teaching receiving requests from such devices.
2. Identifying a type of the user device: Tseng et al.'s teaching of enabling play across "different devices" implicitly requires identifying the device type to adapt the user experience. US10632388 itself states, "FIG. 33 is a flow chart illustrating an example method for determining graphics based on a user device or platform," including an operation for "determining the type of user device (for example, desktop, mobile device, tablet etc.)" (block 3304). This is a routine step in cross-platform development.
3. Assigning a specific status to the player based on a level of interaction, the specific status selected from a group consisting of a leader, a follower, and a bystander: Directly taught by Cowan et al., which details a system "allowing players to participate at different levels, such as 'leaders' and 'followers'" and where players can influence gameplay through social network interactions. The concept of a "bystander" as a third level of interaction (e.g., viewing and keyword-based influence) is an obvious extension within such a social influence framework.
4. Altering game-play graphics based on the type of user device and one or more user preferences: Tseng et al. describes a "cross-platform gaming system" designed for "different devices," which inherently necessitates adapting graphics for optimal display on each device type. A PHOSITA would understand that different devices (e.g., mobile phones versus game consoles) have varying display capabilities, and user preferences for visual presentation (e.g., 2D for mobile, 3D for console) would naturally lead to adjusting graphics, as explicitly described in US10632388 and illustrated in FIG. 33, block 3308.
5. Initiating or performing game play through the client based on the received game play request, the altered game-play graphics, and the specific status: This is a combination of the teachings from Tseng et al. regarding "playing games across different devices" and Cowan et al.'s system where player status affects capabilities and thus influences game play initiation and performance.
6. Receiving game-play information, the game-play information including one or more rewards and one or more features earned during game play: Tseng et al. teaches synchronizing "achievements" across platforms, which are a form of reward/feature. Cowan et al. describes social network interactions influencing gameplay, which implies the generation and reception of in-game effects or rewards.
7. Updating a global database to synchronize information across platforms based on the received game-play information: Explicitly taught by Tseng et al., which describes synchronizing "game progress and achievements" across platforms.
8. Posting details of one or more game events to a social network feed: Cowan et al. describes "influencing gameplay through social network interactions", which would involve posting relevant game events. Additionally, other cited prior art such as Walker et al. and Van Luchene extensively describe posting game-related activities to social networks.
9. Monitoring one or more social interactions related to the posted game events, the one or more social interactions including comments and likes: Taught by Cowan et al.'s concept of "influencing gameplay through social network interactions". Walker et al. and Van Luchene further elaborate on monitoring social network activity related to games.
10. Calculating one or more rewards for the player based on the one or more social interactions: Cowan et al.'s concept of social interactions "influencing gameplay" inherently includes the calculation of in-game effects or rewards. Walker et al. also discusses tracking scores and sharing game information, which forms a basis for calculating rewards based on social engagement.
11. Delivering the one or more calculated rewards to the player within the video game: This is a logical outcome of the calculations in the previous step and is implied by Cowan et al.'s "influencing gameplay" and Tseng et al.'s synchronization of "achievements" across platforms.

Application to Independent Claim 7 (System)

Claim 7 describes a system designed to execute the method of Claim 1. The elements of Claim 7 are likewise rendered obvious by the combination of Cowan et al. and Tseng et al., along with general knowledge of system architecture for online gaming:

• A system for managing a video game, comprising:
  • a network interface for communicating with a plurality of user devices and a plurality of networks: A standard and necessary component for any online or cross-platform gaming system, as taught by both Tseng et al. and Cowan et al..
  • memory for storing user account data, game options data, user rewards data, user play data, game options, preferences data, promotion data, and advertising data: Essential for any persistent game and implied by the synchronized progress and achievements in Tseng et al. and the multi-level play and rewards in Cowan et al..
  • a processor coupled to the network interface and the memory, the processor configured to execute a plurality of software modules, the plurality of software modules comprising: A standard central processing unit required for any computer-implemented system.
    • a user interface module configured to facilitate a connection of a user device with a social network server: Covered by Cowan et al.'s description of interaction via social networks and Tseng et al.'s cross-platform system, both requiring a user interface.
    • a permissions module configured to ensure user device compliance with protocols: Implied by managing different player statuses and interactions (Cowan et al.), as well as general security and access control requirements for online gaming systems.
    • a user account module configured to determine if a user has an existing account or must create one: Implied by the need for player accounts in all online gaming contexts, as taught by Tseng et al. and Cowan et al..
    • a user status module configured to assign a status to the player and manage the player's status: Directly taught by Cowan et al.'s system for "allowing players to participate at different levels, such as 'leaders' and 'followers'".
    • a promotion/rewards module configured to permit players to earn one or more rewards: Implied by Cowan et al.'s social interactions influencing gameplay and Tseng et al.'s synchronization of achievements. Walker et al. and Van Luchene also extensively address game-related activities, scores, and promotions that would necessitate such a module.
    • a game initiation/operation module configured to initiate game play, adapt game-play graphics based on the type of user device and user preference, and facilitate game play: Covered by Tseng et al.'s cross-platform play and adaptation for different devices.
    • a social network module configured to interact with one or more social network platforms to post game events to a social network feed, and process one or more social interactions for one or more rewards: Directly covered by Cowan et al.'s influencing gameplay through "social network interactions" and Tseng et al.'s "social features". Walker et al. and Van Luchene provide extensive detail on implementing these social network interactions within a gaming context.

Conclusion

The combination of US 2012/0115569 A1 (Cowan et al.) and US 2011/0219324 A1 (Tseng et al.) provides a clear and direct basis for an obviousness rejection of independent claims 1 and 7 of US Patent 10632388. A PHOSITA, motivated to enhance player engagement through varied social roles and expand game accessibility across multiple platforms, would have readily combined these teachings with a reasonable expectation of success. The key elements of multi-level player status, cross-platform synchronization, and social network-driven rewards are all present or clearly suggested in the combined prior art.

For US Patent 10632388, here are the details regarding its term and family:

Patent Term Adjustment (PTA):
Patent Term Adjustment (PTA) extends the term of a patent to compensate for certain delays by the USPTO during the examination process of a utility or plant patent application. The USPTO automatically determines and transmits a notice of PTA no later than the patent's issuance date. Delays are categorized as A-delays (USPTO failure to act within specific timeframes), B-delays (failure to issue patent within three years of filing), and C-delays (due to interference, secrecy orders, or appeals). This adjusted term is added to the standard 20-year patent term, calculated from the application's filing date.

To determine the specific PTA for US 10632388, it would be necessary to access the patent's prosecution history on the USPTO Patent Center or review the Issue Notification Letter that accompanies the granted patent. This information is not explicitly provided in the patent document itself or general search results.

Patent Term Extension (PTE):
Patent Term Extension (PTE) is available under the Hatch-Waxman Act (35 U.S.C. § 156) for patents on certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products. This aims to restore patent term lost while awaiting premarket government approval from a regulatory agency. The extension cannot exceed five years and cannot extend the patent term to more than 14 years from the product's approval date.

Given that US Patent 10632388 relates to "Multilayer framework architecture and user interface for video gaming applications," it is highly unlikely to be eligible for Patent Term Extension under 35 U.S.C. § 156, as its subject matter does not fall within the categories of products requiring premarket regulatory review (e.g., pharmaceuticals or medical devices).

Continuation Applications:
A continuation application is a follow-up application filed to pursue additional claims related to the same invention disclosed in a prior "parent" application, while retaining the parent's priority date and largely the same specification. Continuation applications must be filed before the parent application issues as a patent or becomes abandoned. They are often used to secure broader claims or to pursue claims that were not allowed in the parent application.

The "Cross Reference To Related Applications" section of US10632388 indicates that it is a continuation of several earlier-filed applications:

• U.S. patent application Ser. No. 13/889,276, filed May 7, 2013
• U.S. patent application Ser. No. 13/889,266, filed May 7, 2013
• U.S. patent application Ser. No. 13/889,274, filed May 7, 2013
• U.S. patent application Ser. No. 13/889,284, filed May 7, 2013

These applications, in turn, claim the benefit of U.S. Provisional Application No. 61/643,352, filed on May 7, 2012.

Additionally, the Google Patents information for US10632388 lists several later priority claims, indicating potential subsequent continuation applications that claim priority back to US10632388:

• Priority to US17/076,408 (2020-10-21), which resulted in US11731054B1
• Priority to US18/347,057 (2023-07-05), which resulted in US12324988B2
• Priority to US19/219,455 (2025-05-27), which resulted in US20250281835A1

Divisional Applications:
A divisional application is filed when a parent application contains more than one distinct invention, usually in response to a USPTO restriction requirement. It claims a distinct invention disclosed but not claimed in the parent application, but shares the priority date of the original parent application.

The provided patent text does not explicitly state that US10632388 itself is a divisional application, nor does it list any specific divisional applications stemming directly from US10632388. The listed related applications are continuations.

Related Family Members:
Based on the "Cross Reference To Related Applications" section in US10632388 and the priority data from Google Patents, the patent family includes:

• Parent Applications:
  • U.S. Provisional Application No. 61/643,352, filed on May 7, 2012 (priority date)
  • U.S. patent application Ser. No. 13/889,276, filed May 7, 2013
  • U.S. patent application Ser. No. 13/889,266, filed May 7, 2013
  • U.S. patent application Ser. No. 13/889,274, filed May 7, 2013
  • U.S. patent application Ser. No. 13/889,284, filed May 7, 2013
• Child/Continuation Applications (claiming priority from US10632388's lineage):
  • US17/076,408 (filed 2020-10-21), which became US11731054B1
  • US18/347,057 (filed 2023-07-05), which became US12324988B2
  • US19/219,455 (filed 2025-05-27), which became US20250281835A1

Projected Expiration Date:
For applications filed on or after June 8, 1995, the patent term is generally 20 years from the date of the earliest related application, or if there are no earlier applications, the filing date. This 20-year term can be adjusted by Patent Term Adjustment (PTA) to compensate for USPTO delays.

The earliest priority date for US 10632388 is May 7, 2012, from U.S. Provisional Application No. 61/643,352.

Based on a nominal 20-year term from the earliest priority date:
May 7, 2012 + 20 years = May 7, 2032.

The Google Patents information for US10632388 explicitly states an "Anticipated expiration" date of 2033-05-07. This indicates that there is likely a Patent Term Adjustment (PTA) of approximately one year applied to the patent, extending its life beyond the standard 20 years from its earliest priority date. Therefore, the projected expiration date is May 7, 2033.

Defensive Disclosure Document: Enhancements and Alternative Embodiments for US Patent 10632388

Current Date: 2026-04-26

This document describes a series of derivative works and alternative embodiments based on the core teachings of US Patent 10632388, titled "Multilayer framework architecture and user interface for video gaming applications." The purpose of this disclosure is to establish prior art for potential future incremental improvements by competitors, thereby rendering such advancements obvious or non-novel. This document does not summarize the existing patent but builds upon its claimed inventions.

---

Derivatives of Independent Claim 1 (Computer-Implemented Method)

Independent Claim 1 outlines a computer-implemented method for managing a video game, focusing on dynamic user experience based on device type, assigned status, cross-platform synchronization, and social network integration for rewards.

1. Material & Component Substitution: Thin Client with Haptic Feedback Array & Federated Social Graph Protocol

Enabling Description: This derivative method replaces traditional client-side rendering and processing with a cloud-gaming architecture utilizing thin clients. The player's device, whether mobile or console-like, acts primarily as a display and input device, streaming video frames from a remote server. Input capture includes advanced haptic feedback peripherals, such as a force-feedback haptic glove or full-body suit (e.g., using electroactive polymers or piezoelectric actuators) which provide tactile sensations proportional to in-game events, supplementing visual feedback. The social network integration is achieved via a decentralized, federated social graph protocol (e.g., Mastodon-compatible ActivityPub or a distributed ledger-based social graph like Lens Protocol). Game events are posted as ActivityStreams objects to federated instances, and social interactions (likes, comments, boosts) are monitored across this distributed network. Rewards are calculated and delivered based on these verifiable, cryptographically signed social interactions within the game. The global database for synchronization would leverage a sharded, distributed SQL or NoSQL database for horizontal scaling across cloud regions.

flowchart TD
    A[Player Device (Thin Client) with Haptic Peripheral] --> B{Game Play Request / User Input};
    B --> C[Cloud Gaming Server Cluster];
    C --> D{Identify Device Type & Haptic Capabilities};
    C --> E{Assign Player Status (Leader, Follower, Bystander)};
    C --> F{Alter Game Graphics & Haptic Feedback Parameters};
    F --> G[Initiate/Perform Game Play (Rendered on Server)];
    G --> H[Stream Video/Audio & Haptic Commands to Client];
    I{Receive Game-play Info (Rewards/Features)};
    I --> J[Update Sharded Global Database (Cross-Platform Sync)];
    J --> K{Post Game Events as ActivityStreams (Federated Social Graph)};
    K --> L{Monitor Federated Social Interactions (Comments/Likes/Boosts)};
    L --> M{Calculate Rewards (Based on Signed Social Interactions)};
    M --> N{Deliver Calculated Rewards In-Game};

2. Operational Parameter Expansion: Sub-Millisecond Global eSports & Serverless Microservices

Enabling Description: This method is designed for ultra-low-latency, geographically dispersed competitive gaming, supporting millions of concurrent players. The "game play request" initiates a session on a serverless microservice architecture deployed across global edge computing nodes, ensuring player-server latency is minimized (targeting <5ms round trip). Device type identification dynamically provisions appropriate GPU-accelerated container instances. Player status assignment and capability modification are managed by a real-time policy engine, which can switch player roles and modify game logic within tens of microseconds based on game state and social feed triggers. Game-play graphics alteration occurs at the rendering pipeline level, optimizing for device display characteristics and network bandwidth in real-time. The global database for synchronization is a globally distributed, eventually consistent database (e.g., Amazon DynamoDB Global Tables, Google Cloud Spanner) with conflict resolution logic, ensuring game state convergence within hundreds of milliseconds across continents. Social network events are published via a low-latency message queue (e.g., Apache Kafka) to a dedicated social interaction processing pipeline, which calculates rewards based on stream analytics of likes/comments within single-digit milliseconds, delivering rewards back via WebSocket connections.

sequenceDiagram
    participant P as Player Device
    participant EC as Edge Compute Node
    participant MS as Microservices Layer
    participant DBE as Global Distributed DB (Eventual Consistency)
    participant MQS as Message Queue (Kafka)
    participant SIPE as Social Interaction Processing Engine
    participant RDD as Real-time Reward Delivery

    P->>EC: Game Play Request (<5ms RTT)
    EC->>MS: Identify Device Type & Player ID
    MS->>MS: Assign Player Status (Policy Engine)
    MS->>MS: Alter Game Graphics (Dynamic Rendering)
    MS->>EC: Initiate/Perform Game Play
    EC->>P: Game State Updates (Sub-millisecond)
    MS->>DBE: Receive/Update Game-play Info
    DBE-->>MS: Acknowledge Sync
    MS->>MQS: Post Game Event to Stream
    MQS->>SIPE: Deliver Event to Processing Engine
    SIPE->>SIPE: Monitor Social Interactions (Stream Analytics)
    SIPE->>SIPE: Calculate Rewards (<10ms)
    SIPE->>RDD: Send Reward Data
    RDD->>P: Deliver Reward (WebSocket)

3. Cross-Domain Application: Remote Surgical Training and Simulation

Enabling Description: This method manages a remote surgical training and simulation platform. A "player's device" is a surgical robot console or a high-fidelity VR/AR workstation. The system receives a request for a surgical simulation. It identifies the device type (e.g., Da Vinci surgical console emulator, VR headset) and assigns roles: "Surgeon (Leader)," "First Assistant (Follower)," and "Observer (Bystander)." Each role has defined interaction levels and permissions. Graphics are altered for realism, e.g., 3D stereoscopic for VR, high-resolution for surgical displays. Gameplay involves simulated surgical procedures. Game-play information (e.g., tissue damage, blood loss, procedure time, instrument manipulation accuracy) is received. A global database synchronizes the simulation state for all participants. Details of surgical actions, successful maneuvers, or critical errors are posted to a secure, internal social network feed for peer review or instructor feedback. Monitoring comments ("likes" or specific keyword tags like "#goodhemostasis") and structured feedback generates "rewards" such as skill points, certification progress, or unlocks for more complex procedures. These calculated rewards are delivered within the training module.

graph TD
    A[Trainee Device (Surgical Robot Console / VR Workstation)] --> B{Simulation Request};
    B --> C[Simulation Server];
    C --> D{Identify Device Type (e.g., Haptic/VR)};
    C --> E{Assign Role: Surgeon, Assistant, Observer};
    C --> F{Alter Simulation Graphics (Realism) & Haptic Feedback};
    F --> G[Initiate/Run Surgical Simulation];
    G --> H{Receive Simulation Performance Data (Metrics)};
    H --> I[Update Global Simulation State DB];
    I --> J{Post Surgical Event to Secure Peer Review Feed (Internal Social Network)};
    J --> K{Monitor Peer Feedback (Structured Comments/Ratings)};
    K --> L{Calculate Skill Points / Certification Progress (Rewards)};
    L --> M{Deliver Rewards In-Simulation};

4. Cross-Domain Application: Smart City Infrastructure Management Simulation

Enabling Description: This method manages a Smart City infrastructure simulation platform. A "player's device" can be a municipal GIS workstation, a tablet for field workers, or a public kiosk interface. The method receives a request to interact with the city model. It identifies the device type and assigns a status: "City Planner (Leader)," "Department Head (Follower)," and "Citizen (Bystander)." Graphics are altered: high-detail 3D for planners, simplified map views for field staff, and informational dashboards for citizens. Game-play involves proposing infrastructure changes, managing resources, or responding to simulated events (e.g., traffic incidents, utility failures). Game-play information includes project progress, budget adherence, and citizen satisfaction metrics. This data updates a global city model database. Proposed changes or responses to events are posted to a public social network feed integrated with municipal feedback channels. Monitoring public comments, votes, or simulated "likes" on these proposals influences "rewards" such as project approval ratings, public trust scores, or unlocking new funding opportunities for the City Planner. These rewards are delivered back into the simulation environment.

flowchart TD
    A[User Device (GIS Workstation / Tablet / Public Kiosk)] --> B{Interaction Request};
    B --> C[Smart City Simulation Engine];
    C --> D{Identify Device Type};
    C --> E{Assign Role: City Planner, Dept Head, Citizen};
    C --> F{Alter UI Graphics (Detail Level) & Data Views};
    F --> G[Initiate/Perform Infrastructure Management Simulation];
    G --> H{Receive Simulation Metrics (Project Status, Budget, Satisfaction)};
    H --> I[Update Global City Model DB];
    I --> J{Post Proposal/Event to Public Feedback Portal (Social Network)};
    J --> K{Monitor Public Comments/Votes/Sentiment};
    K --> L{Calculate Project Approval / Public Trust (Rewards)};
    L --> M{Deliver Rewards In-Simulation};

5. Cross-Domain Application: Personalized Adaptive Learning Platform

Enabling Description: This method manages a personalized adaptive learning platform. A "player's device" is a student's tablet, a teacher's laptop, or a parent's smartphone. The method receives an access request. It identifies the device type and assigns a status: "Instructor (Leader)," "Student (Follower)," or "Parent/Tutor (Bystander)." Graphics are altered, presenting rich multimedia for students, analytic dashboards for instructors, and progress reports for parents. Game-play involves students engaging with learning modules, completing quizzes, or collaborative projects. Game-play information includes learning progress, quiz scores, and time spent on tasks. This data updates a global student progress database. Student achievements, collaborative project milestones, or specific learning challenges are posted to an internal, role-gated social network feed. Monitoring comments/reactions from peers, instructors, or parents generates "rewards" such as digital badges, access to advanced modules, or virtual classroom currency. These calculated rewards are delivered within the learning platform.

graph TD
    A[User Device (Student Tablet / Teacher Laptop / Parent Smartphone)] --> B{Access Request};
    B --> C[Adaptive Learning Platform Server];
    C --> D{Identify Device Type};
    C --> E{Assign Role: Instructor, Student, Parent};
    C --> F{Alter Content Presentation (Multimedia, Dashboards, Reports)};
    F --> G[Initiate/Perform Learning Module / Assessment];
    G --> H{Receive Learning Progress Data (Scores, Completion, Time)};
    H --> I[Update Global Student Progress DB];
    I --> J{Post Learning Event to Role-Gated Internal Social Feed};
    J --> K{Monitor Peer/Instructor/Parent Feedback (Comments/Reactions)};
    K --> L{Calculate Badges / Module Unlocks / Virtual Currency (Rewards)};
    L --> M{Deliver Rewards In-Platform};

6. Integration with Emerging Tech: AI-Driven Dynamic Content and Reward Optimization

Enabling Description: This method integrates AI for real-time optimization of game content and reward structures. Upon receiving a game-play request, an AI-powered module (e.g., using a Reinforcement Learning agent) identifies the user device and assigns status. The AI then dynamically alters game-play graphics (e.g., texture detail, particle effects density, UI complexity) and content (e.g., quest difficulty, enemy AI behavior, environmental hazards) based on real-time player performance metrics (e.g., K/D ratio, quest completion speed, resource management efficiency), emotional state inferred from in-game chat sentiment analysis (NLP model), and predictive models of player engagement and churn. Game events are posted to the social network feed, and the AI continuously monitors social interactions. A separate AI reward engine (e.g., using Bayesian inference or a deep learning model) calculates personalized rewards by correlating social interaction patterns (e.g., specific keyword usage, emotional tone of comments, 'like' velocity) with optimal player retention and in-game economy balance, delivering these customized rewards dynamically.

sequenceDiagram
    participant P as Player Device
    participant AI as AI Optimization Module
    participant G as Game Engine
    participant S as Social Network Module
    participant DB as Global Database

    P->>G: Game Play Request
    G->>AI: Device Type, Player Status, Real-time Performance
    AI->>AI: Analyze Player Data & Social Sentiment (NLP)
    AI->>AI: Predict Engagement & Churn (ML Model)
    AI->>G: Dynamically Adjust Game Content & Graphics (RL Agent)
    G->>P: Render Game Play
    G->>DB: Receive/Update Game-play Info
    G->>S: Post Game Event to Feed
    S->>S: Monitor Social Interactions
    S->>AI: Forward Social Interaction Data
    AI->>AI: Calculate Personalized Rewards (Bayesian / Deep Learning)
    AI->>G: Deliver Rewards
    G->>P: In-Game Reward Notification

7. Integration with Emerging Tech: IoT Biometric Feedback for Adaptive Gameplay

Enabling Description: This method integrates real-time biometric data from IoT wearable sensors into gameplay. The player's device includes or is paired with IoT sensors (e.g., smartwatches, chest straps, smart rings) that continuously monitor physiological parameters like heart rate (HR), heart rate variability (HRV), galvanic skin response (GSR), and electroencephalogram (EEG) signals. Upon receiving a game-play request, the system identifies the player's device and assigns status. It also establishes a secure, low-latency connection to ingest biometric data. Game-play graphics are altered based on device capabilities and player preference, but also dynamically in response to biometric feedback. For instance, if HR or GSR indicates high stress, the game difficulty might adapt, or visual cues might change. Game-play involves player actions, and "game-play information" now includes biometric performance data alongside traditional scores. This augmented data updates the global database. Critical physiological events (e.g., "player achieved peak focus (low HRV) during boss fight") are automatically posted to a specialized social network feed. Monitoring comments or "cheers" related to these biometric achievements generates "rewards" such as temporary buffs, increased in-game currency, or unique cosmetic items, which are delivered in-game.

graph TD
    A[Player Device] --> B{Game Play Request};
    W[IoT Wearable Biometric Sensors] --> C[Biometric Data Ingestion Gateway];
    B & C --> D[Game Server];
    D --> E{Identify Device Type};
    D --> F{Assign Player Status};
    D --> G{Alter Graphics & Gameplay based on Biometric Feedback};
    G --> H[Initiate/Perform Game Play];
    H --> I{Receive Game-play Info + Biometric Data};
    I --> J[Update Global DB (Sync)];
    J --> K{Post Biometric Game Event to Specialized Social Feed};
    K --> L{Monitor Social Interactions (Cheers, Comments)};
    L --> M{Calculate Biometric-Based Rewards};
    M --> N{Deliver Rewards In-Game};

8. Integration with Emerging Tech: Blockchain for Verifiable In-Game Asset Provenance and Social Rewards

Enabling Description: This method leverages blockchain technology to manage in-game assets and transparently verify social rewards. When a game-play request is received, the system identifies the device and assigns player status. Game-play graphics are altered as usual. Critical in-game assets (e.g., rare items, achievements, virtual land) are represented as Non-Fungible Tokens (NFTs) or Fungible Tokens (FTs) on a public or private blockchain (e.g., Ethereum, Polygon, Solana, or a Hyperledger Fabric instance). Game-play information regarding the creation, acquisition, or use of these assets is recorded as immutable transactions on the blockchain. The global database synchronizes traditional game state, while the blockchain manages asset provenance. Posting game events (e.g., "Player X acquired Rare Sword NFT") to a social network feed now also includes cryptographic proof or a link to the blockchain transaction. Monitoring social interactions (likes, comments, shares) triggers the calculation of rewards, which could be new tokens, fractional ownership of existing assets, or governance tokens within the game's Decentralized Autonomous Organization (DAO). These rewards are delivered directly to the player's associated blockchain wallet and reflected in-game, providing transparent and verifiable social contributions.

sequenceDiagram
    participant P as Player Device
    participant G as Game Server
    participant DB as Global Database
    participant S as Social Network Module
    participant BC as Blockchain Network
    participant CW as Player Crypto Wallet

    P->>G: Game Play Request
    G->>G: Identify Device Type & Assign Status
    G->>P: Alter Graphics & Initiate Game Play
    G->>DB: Receive/Update Game-play Info
    G->>BC: Mint/Transfer In-Game Asset (NFT/FT Transaction)
    G->>S: Post Game Event (with Blockchain Tx ID)
    S->>S: Monitor Social Interactions
    S->>G: Forward Social Interactions
    G->>G: Calculate Rewards (e.g., new Tokens/NFTs)
    G->>BC: Initiate Reward Token/NFT Transfer
    BC->>CW: Deliver Reward to Wallet
    G->>P: In-Game Reward Notification (with Tx ID)

9. The "Inverse" or Failure Mode: Resilient Low-Power/Limited-Functionality Mode

Enabling Description: This method describes a resilient operation mode for the gaming system during periods of high load, degraded network conditions, or partial system failures. Upon receiving a game-play request under such conditions, the system identifies the device and assigns status, but a "resilience module" intercepts. Instead of full functionality, game-play graphics are automatically downgraded to a "low-power" 2D mode, or even a text-based adventure interface, prioritizing core game logic over visual fidelity (e.g., only critical UI elements are rendered). Player capabilities based on status are temporarily restricted (e.g., "bystanders" can only view, "followers" cannot initiate complex sub-games). The game initiation/operation module switches to a "limited-functionality" mode, focusing on persistent game state updates while deferring non-critical actions. Game-play information received is minimized, only critical progress points are saved to the global database, which itself might operate in a read-only or eventually consistent mode with reduced transaction rates. Posting to the social network feed is batched or delayed, and real-time social interaction monitoring is suspended. Rewards calculation is simplified (e.g., fixed baseline rewards) or deferred, and delivery occurs only upon system recovery, providing a safe and stable, albeit reduced, user experience.

stateDiagram-v2
    state Normal_Operation {
        [*] --> Game_Request
        Game_Request --> Full_Graphics
        Full_Graphics --> Full_Gameplay
        Full_Gameplay --> Social_Integration
        Social_Integration --> Rewards_Delivery
        Rewards_Delivery --> Full_Gameplay
    }
    state Degraded_Mode {
        state "Low-Power & Limited Functionality" as LPM {
            [*] --> Reduced_Graphics
            Reduced_Graphics --> Core_Gameplay
            Core_Gameplay --> Delayed_Social_Update
            Delayed_Social_Update --> Basic_Rewards
            Basic_Rewards --> Core_Gameplay
        }
        LPM --> System_Recovery: Network/Server Restore
    }

    Full_Gameplay -- T[Degradation Event (High Load, Network Failure)] --> LPM
    System_Recovery --> Normal_Operation

---

Derivatives of Independent Claim 7 (System)

Independent Claim 7 describes a system for managing video games, including various hardware and software modules to support the functionality of Claim 1.

1. Material & Component Substitution: Quantum-Resistant Cryptographic Hardware & Memristor Memory

Enabling Description: This derivative system implements the core functions using advanced hardware. The network interface incorporates quantum-resistant cryptographic hardware modules (e.g., based on lattice-based cryptography ASICs) to secure data transmission against future quantum computing threats. Memory utilizes memristor-based non-volatile memory for persistent storage of user account data, game state, and rewards, offering ultra-low power consumption and high endurance. The processor is a heterogeneous architecture combining traditional CPUs for general orchestration with dedicated neuromorphic computing units (e.g., Intel Loihi chips) for the AI-driven optimization module (as described in Claim 1, derivative 6) and portions of the game initiation/operation module that involve complex pattern recognition or adaptive behavior generation. User devices (clients) can be thin clients leveraging WebAssembly for client-side logic, communicating with server-side microservices for core game execution.

classDiagram
    class System {
        +NetworkInterface(QuantumResistantCrypto)
        +Memory(MemristorNVM)
        +Processor(Heterogeneous: CPU+Neuromorphic)
        +UserInterfaceModule
        +PermissionsModule
        +UserAccountModule
        +UserStatusModule
        +PromotionRewardsModule
        +GameInitiationOperationModule
        +SocialNetworkModule
    }
    class QuantumResistantCrypto {
        +LatticeBasedASIC
        +SecureChannelProtocol()
    }
    class MemristorNVM {
        +PersistentStorage()
        +LowPowerOperation()
    }
    class NeuromorphicUnit {
        +AIProcessing()
        +PatternRecognition()
    }
    System *-- QuantumResistantCrypto
    System *-- MemristorNVM
    System *-- NeuromorphicUnit

2. Operational Parameter Expansion: Exascale Edge Computing & High-Frequency Network Adapters

Enabling Description: This system is architected for exascale gaming workloads, supporting billions of API calls per second and petabytes of data throughput. It features a massively distributed network interface employing high-frequency trading (HFT) grade network adapters (e.g., 200GbE or higher with FPGA-based offloading) within global edge computing data centers. The memory is a tiered, geographically sharded memory fabric with automated data locality management, capable of caching active game state within microseconds of access from any global node. The processor architecture leverages advanced vector processors and specialized hardware accelerators (e.g., custom ASICs for physics, rendering, and AI) distributed across these edge nodes. The game initiation/operation module dynamically migrates active game sessions between edge nodes based on player geographic movement and network conditions. The social network module integrates with federated social graphs and processes event streams using real-time stream processing engines (e.g., Apache Flink) deployed on these edge resources, ensuring social interaction feedback and reward delivery at near-instantaneous speeds across a global player base.

graph TD
    subgraph Global Exascale System
        EdgeNode1[Edge Computing Node 1] <--> HFTNA1(HFT Network Adapter)
        EdgeNode2[Edge Computing Node 2] <--> HFTNA2(HFT Network Adapter)
        ...
        EdgeNodeN[Edge Computing Node N] <--> HFTNAN(HFT Network Adapter)

        subgraph EdgeNode1 Components
            Proc1(Processor: Vector + Accel) --> Mem1(Tiered Memory Fabric)
            Proc1 --> GIO1(Game Initiation/Operation Module)
            Proc1 --> SNM1(Social Network Module)
            Proc1 --> UIM1(User Interface Module)
            Proc1 --> PMM1(Permissions Module)
            Proc1 --> UAM1(User Account Module)
            Proc1 --> USM1(User Status Module)
            Proc1 --> PRM1(Promotion/Rewards Module)
        end
        subgraph EdgeNode2 Components
            Proc2(Processor: Vector + Accel) --> Mem2(Tiered Memory Fabric)
            Proc2 --> GIO2(Game Initiation/Operation Module)
            Proc2 --> SNM2(Social Network Module)
            ...
        end

        HFTNA1 --- Net(Global High-Speed Network) --- HFTNA2
        Mem1 --- GlobalDB(Globally Sharded DB) --- Mem2
    end
    Player1[Player Device 1] -- Connect --> HFTNA1
    PlayerN[Player Device N] -- Connect --> HFTNAN

3. Cross-Domain Application: Industrial IoT Plant Control and Monitoring System

Enabling Description: This system is adapted for industrial control and monitoring. The network interface supports industrial communication protocols (e.g., OPC UA, Modbus TCP, MQTT) for communication with various sensors, actuators, and programmable logic controllers (PLCs). Memory stores real-time operational data, equipment schematics, maintenance logs, and compliance standards. The processor executes modules tailored for industrial applications. The user interface module provides HMI (Human-Machine Interface) dashboards and augmented reality (AR) overlays for plant operators. The permissions module enforces strict role-based access control (RBAC) in accordance with ISA/IEC 62443. The user status module assigns roles such as "Lead Engineer (Leader)," "Maintenance Technician (Follower)," and "Auditor (Bystander)," each with defined control and viewing permissions. The promotion/rewards module tracks KPIs (Key Performance Indicators) and awards "efficiency bonuses" or "safety compliance credits." The game initiation/operation module simulates plant operations, allowing operators to test control sequences. The social network module integrates with an internal communication platform, posting critical alerts or successful operational milestones, processing feedback (e.g., acknowledging alarms, reporting anomalies) to influence "rewards" or system adjustments.

flowchart TD
    A[Industrial IoT Sensors/Actuators] -- OPC UA/MQTT --> B{Network Interface (Industrial Protocols)};
    B --> C[System Processor];
    C --> D[Memory (Operational Data, Schematics, Logs)];

    subgraph Software Modules
        E[User Interface Module (HMI/AR)]
        F[Permissions Module (RBAC)]
        G[User Account Module]
        H[User Status Module (Lead Engineer, Technician, Auditor)]
        I[Promotion/Rewards Module (KPI Tracking)]
        J[Game Initiation/Operation Module (Plant Simulation)]
        K[Social Network Module (Internal Comms, Alerts)]
    end

    C --> E
    C --> F
    C --> G
    C --> H
    C --> I
    C --> J
    C --> K

    K --> L[Internal Communication Platform (e.g., MS Teams/Slack Integrated)]
    L --> M[Operator/Engineer Devices]

4. Cross-Domain Application: Disaster Response Coordination Platform

Enabling Description: This system is tailored for coordinating disaster response efforts. The network interface supports robust, resilient mesh networking protocols (e.g., LoraWAN, satellite uplinks) to operate in degraded communication environments, connecting various field devices (rugged tablets, body cameras, drones). Memory stores dynamic incident maps, resource inventories, live sensor feeds (e.g., air quality, structural integrity), and responder profiles. The processor executes a suite of emergency management modules. The user interface module displays real-time operational common operating picture (COP) with GIS overlays. The permissions module strictly controls access based on emergency credentials and current incident command structure. The user status module assigns roles like "Incident Commander (Leader)," "First Responder (Follower)," and "Logistics Coordinator (Bystander)," with corresponding command, action, and support capabilities. The promotion/rewards module tracks completed tasks, resource allocation efficiency, and safety compliance, awarding "incident credits" or "resource prioritization." The game initiation/operation module simulates disaster scenarios for training and strategic planning. The social network module integrates with an emergency communication platform, posting updates, requests for aid, or validated reports, processing acknowledgments or requests for information to influence "rewards" (e.g., faster resource dispatch) or update situation awareness.

graph TD
    A[Field Devices (Rugged Tablet, Bodycam, Drone)] -- Mesh Network/Satellite --> B{Network Interface (Resilient Comms)};
    B --> C[System Processor];
    C --> D[Memory (Incident Maps, Resources, Sensor Feeds)];

    subgraph Software Modules
        E[User Interface Module (COP/GIS)]
        F[Permissions Module (Emergency RBAC)]
        G[User Account Module (Responder Profiles)]
        H[User Status Module (Incident Commander, First Responder, Logistics)]
        I[Promotion/Rewards Module (Task Completion, Resource Efficiency)]
        J[Game Initiation/Operation Module (Scenario Simulation)]
        K[Social Network Module (Emergency Comms, Alerts)]
    end

    C --> E
    C --> F
    C --> G
    C --> H
    C --> I
    C --> J
    C --> K

    K --> L[Emergency Communication Platform]
    L --> M[Decision Makers / Support Teams]

5. Cross-Domain Application: Collaborative Architectural Design & Review Platform

Enabling Description: This system is designed for collaborative architectural design and review. The network interface supports high-bandwidth peer-to-peer connections and cloud-based CAD/BIM model streaming. Memory stores versioned 3D building information models (BIM), material libraries, regulatory compliance data, and stakeholder feedback. The processor runs specialized design and visualization modules. The user interface module provides immersive VR/AR walkthroughs and collaborative CAD environments. The permissions module manages access to specific model components or design layers. The user status module assigns roles such as "Lead Architect (Leader)," "Structural Engineer (Follower)," and "Client (Bystander)," each with specific editing, commenting, or viewing rights. The promotion/rewards module tracks design iteration efficiency, compliance adherence, and client satisfaction, awarding "design credits" or "project milestones." The game initiation/operation module facilitates real-time design modifications and conflict detection within the BIM. The social network module integrates with a project collaboration platform, posting design updates, issue resolutions, or client review milestones, processing comments, approvals, or change requests to influence "rewards" (e.g., accelerated design approvals) or trigger automated design checks.

flowchart TD
    A[Design Devices (CAD Workstation, VR/AR Headset)] -- P2P/Cloud Stream --> B{Network Interface (High-Bandwidth)};
    B --> C[System Processor];
    C --> D[Memory (Versioned BIM, Libraries, Compliance)];

    subgraph Software Modules
        E[User Interface Module (VR/AR, Collaborative CAD)]
        F[Permissions Module (Model Layer Access)]
        G[User Account Module (Designer Profiles)]
        H[User Status Module (Lead Architect, Engineer, Client)]
        I[Promotion/Rewards Module (Design Efficiency, Compliance)]
        J[Game Initiation/Operation Module (Real-time BIM Edit, Conflict Detect)]
        K[Social Network Module (Project Collaboration, Reviews)]
    end

    C --> E
    C --> F
    C --> G
    C --> H
    C --> I
    C --> J
    C --> K

    K --> L[Project Collaboration Platform]
    L --> M[Stakeholders / Reviewers]

6. Integration with Emerging Tech: AI-Driven Predictive Resource Allocation System

Enabling Description: This system integrates AI across its core modules for predictive optimization. The network interface feeds telemetry data into an AI inference engine for anomaly detection and predictive analytics. Memory is augmented with a feature store and vector database for real-time access to training data and AI model embeddings. The processor is specialized with AI accelerators (e.g., TPUs, GPUs). The user interface module includes an AI-powered conversational agent for player support and predictive UI elements (e.g., suggesting next actions, anticipating needs). The permissions module uses a federated learning model to adapt access policies based on observed user behavior and risk profiles without centralizing sensitive data. The user status module employs an AI classification model to dynamically assign and re-evaluate player status based on interaction patterns and influence scores, rather than static rules. The promotion/rewards module uses Reinforcement Learning agents to dynamically generate and deliver personalized rewards, maximizing player engagement and retention by predicting optimal reward types and timing based on individual player profiles and in-game behavior. The game initiation/operation module includes an AI game master that procedurally generates content, adjusts difficulty, and orchestrates events in real-time. The social network module utilizes natural language processing (NLP) for sentiment analysis of social interactions, feeding this back into the AI reward engine and game master for adaptive responses.

classDiagram
    class System {
        +NetworkInterface
        +Memory
        +Processor
        +UserInterfaceModule
        +PermissionsModule
        +UserAccountModule
        +UserStatusModule
        +PromotionRewardsModule
        +GameInitiationOperationModule
        +SocialNetworkModule
    }
    class AI_Subsystems {
        <<interface>>
    }
    class AI_InferenceEngine {
        +PredictiveAnalytics()
        +AnomalyDetection()
    }
    class FederatedLearningModel {
        +AdaptiveAccessPolicies()
    }
    class AI_ClassificationModel {
        +DynamicStatusAssignment()
    }
    class ReinforcementLearningAgent {
        +PersonalizedRewardGeneration()
    }
    class AI_GameMaster {
        +ProceduralContentGeneration()
        +DynamicDifficultyAdjust()
    }
    class NLP_SentimentAnalysis {
        +SocialInteractionAnalysis()
    }
    System *-- AI_InferenceEngine
    System *-- FederatedLearningModel
    System *-- AI_ClassificationModel
    System *-- ReinforcementLearningAgent
    System *-- AI_GameMaster
    System *-- NLP_SentimentAnalysis

7. Integration with Emerging Tech: IoT Sensor-Driven Contextual Game State System

Enabling Description: This system integrates real-world environmental and biometric data via IoT sensors to create a dynamically responsive game environment. The network interface includes a dedicated IoT gateway module supporting various low-power wireless protocols (e.g., Zigbee, Bluetooth Low Energy, LoRaWAN) to ingest data from an array of environmental (e.g., temperature, humidity, light, GPS) and biometric sensors (e.g., heart rate monitors, motion trackers, smart clothing). Memory stores historical sensor data, contextual rulesets, and player biometric profiles. The processor includes dedicated embedded processing units for real-time sensor data fusion and contextual inference. The game initiation/operation module dynamically alters game state (e.g., weather conditions, character abilities, quest availability) based on the current real-world environment (e.g., actual time of day affects in-game lighting, local weather mirrors in-game weather events, player's physical activity level affects stamina). The user status module might assign temporary buffs or debuffs based on player location (geofencing) or environmental conditions (e.g., "Explorer" status for players in new GPS zones). The social network module automatically posts contextual game events (e.g., "Player X is experiencing a virtual snowstorm because it's raining outside!") and allows social interactions (comments, "weather aid" gifts) to influence real-time in-game environmental parameters.

graph TD
    A[IoT Environmental Sensors] -- Low-Power Wireless --> B{IoT Gateway Module (Network Interface)};
    C[IoT Biometric Sensors] -- Bluetooth LE --> B;
    B --> D[System Processor (Embedded Units)];
    D --> E[Memory (Sensor Data, Context Rules, Biometric Profiles)];

    subgraph Software Modules
        F[User Interface Module]
        G[Permissions Module]
        H[User Account Module]
        I[User Status Module (Contextual Buffs/Debuffs)]
        J[Promotion/Rewards Module]
        K[Game Initiation/Operation Module (Dynamic Game State from IoT)]
        L[Social Network Module (Contextual Event Posting, Influence)]
    end

    D --> F
    D --> G
    D --> H
    D --> I
    D --> J
    D --> K
    D --> L

8. Integration with Emerging Tech: Decentralized Autonomous Organization (DAO) for Game Governance and Asset Management

Enabling Description: This system uses blockchain and DAO principles for game governance and asset management. The network interface includes a blockchain client module to interact with a public or private blockchain (e.g., an EVM-compatible chain like Avalanche, or a Cosmos SDK-based chain). Memory stores cryptographic keys, transaction histories, and local copies of smart contract states. The processor is optimized for cryptographic operations. The user account module integrates with non-custodial blockchain wallets, linking player identities to on-chain addresses. The user status module can assign "governance token holder" status, giving players voting rights in the DAO for game rule changes, content updates, or reward distribution mechanisms. The promotion/rewards module distributes rewards as fungible tokens (FTs) or NFTs, managed by smart contracts, providing verifiable ownership and transferability. The game initiation/operation module incorporates smart contract interfaces to trigger on-chain events (e.g., minting new items, initiating a quest that requires token staking). The social network module posts immutable records of game events and player actions to the blockchain, which can then be indexed by decentralized social platforms, fostering a transparent and community-governed game economy where social interactions (votes on proposals, donations of tokens) directly influence game development and player experience via DAO mechanics.

classDiagram
    class System {
        +NetworkInterface
        +Memory
        +Processor
        +UserInterfaceModule
        +PermissionsModule
        +UserAccountModule(BlockchainWalletIntegrated)
        +UserStatusModule(GovernanceTokenHolderStatus)
        +PromotionRewardsModule(SmartContractRewards)
        +GameInitiationOperationModule(SmartContractInterfaces)
        +SocialNetworkModule(BlockchainEventPosting)
    }
    class BlockchainClientModule {
        +InteractWithBlockchain()
        +CryptographicOps()
    }
    class SmartContract {
        +ManageGameRules()
        +DistributeRewards()
        +GovernAssets()
    }
    class NonCustodialWallet {
        +StoreCryptoKeys()
        +ManageTokens()
    }
    System *-- BlockchainClientModule
    System *-- SmartContract
    System *-- NonCustodialWallet

9. The "Inverse" or Failure Mode: Multi-Region Asynchronous Recovery with Local Offline Caching

Enabling Description: This system is designed for enhanced resilience against catastrophic failures through multi-region asynchronous recovery and local offline caching. The network interface employs a global traffic manager that can automatically reroute client connections to healthy regional deployments. Memory for game state is replicated asynchronously across multiple geographic regions, with eventual consistency and conflict resolution handled by a distributed ledger or CRDTs (Conflict-free Replicated Data Types). Each player's device (client) also includes a robust local offline cache in its memory, capable of storing a significant portion of the current game state and pending actions. In a failure mode (e.g., regional data center outage, major network partition), the game initiation/operation module automatically transitions to a local offline play mode, where the client uses its cached data to allow continuous (albeit solo) gameplay. Player actions during offline mode are stored locally. Upon system recovery, the local offline cache synchronizes with the globally available database, using the distributed ledger/CRDTs to resolve any conflicts between offline progress and potentially outdated server state. The social network module queues any social events generated during offline play for deferred posting, and the promotion/rewards module calculates and delivers rewards retrospectively based on the merged game history. This ensures maximum uptime and continuity for players even during widespread system disruptions.

stateDiagram-v2
    state Normal_Operation_Multi_Region {
        [*] --> Region_A_Active: Client Connected to Region A
        Region_A_Active --> Region_B_Standby: Asynchronous Replication
        Region_B_Standby --> Region_A_Active: Data Sync
    }
    state Failure_Event_Region_A {
        Region_A_Active --> Client_Offline_Mode: Region A Fails, Reroute to Local Cache
        Client_Offline_Mode --> Region_B_Active: Region A Recovery, Connect to Region B
        Region_B_Active --> Client_Offline_Mode_Sync: Data Merge & Conflict Resolution
        Client_Offline_Mode_Sync --> Normal_Operation_Multi_Region: Full Recovery
    }

    Client_Offline_Mode: Local Gameplay on Cached Data
    Client_Offline_Mode_Sync: Sync Local Cache with Global DB / CRDTs

---

Combination Prior Art Scenarios

Here are at least three scenarios combining elements of US Patent 10632388 with existing open-source standards, demonstrating obviousness for certain implementations:

1. US10632388 + Open Gaming Alliance (OGA) Common Game Services APIs:
   A person skilled in the art, seeking to develop a cross-platform video game with variable player capabilities and social integration, would find it obvious to combine the architectural principles of US10632388 (e.g., platform agnosticism, user status modules, promotion/rewards logic) with the Open Gaming Alliance's (OGA) open-source Common Game Services APIs. The OGA provides standardized interfaces and SDKs for common game functionalities like user authentication, friend lists, leaderboards, achievements, and in-game commerce, designed for interoperability across diverse platforms. Applying the OGA's open APIs for managing user accounts and rewards (Claim 1, steps 1, 6, 11; Claim 7, modules 305, 309) or for player-to-player communication (Claim 1, steps 8-10; Claim 7, module 313) within the multi-tier framework of US10632388 would be a natural engineering choice to reduce development cost and increase platform reach, thus rendering such an implementation obvious.

2. US10632388 + ActivityPub Protocol for Decentralized Social Integration:
   Given the emphasis in US10632388 on posting game events to a social network feed and monitoring social interactions for rewards (Claim 1, steps 8-10; Claim 7, module 313), it would be obvious to implement these features using the ActivityPub protocol. ActivityPub is a W3C recommended decentralized social networking protocol, which is open-source and widely adopted in the "fediverse" (e.g., Mastodon, Pixelfed). A PHOSITA aiming to achieve the social interaction and reward mechanisms described in US10632388 in a more open, federated, and censorship-resistant manner would naturally integrate ActivityPub. Game events (e.g., "Player X achieved a promotion") could be published as ActivityStreams objects to a player's ActivityPub-enabled profile, and replies/reactions ("likes," "comments") would be received and processed by the game's social network module, leading to the calculation and delivery of in-game rewards. This combination extends the social reach and robustness of the patent's core social features.

3. US10632388 + WebRTC for Real-time Multiplayer Communication and "Bystander" Influence:
   US10632388 describes real-time game play, including "collaborative and competitive play by multiple players" and a "spectator mode that permits non-players in a network to assist friends" (Abstract, Description). It would be obvious to integrate WebRTC (Web Real-Time Communication), an open-source project that enables real-time voice, video, and data communication directly within web browsers and mobile applications via simple APIs, into the multiplayer and spectator functionalities of US10632388. Specifically, the "game initiation/operation module" (Claim 7, module 311) could leverage WebRTC for direct peer-to-peer audio/video chat between "leader" and "follower" players, or for "bystanders" to directly transmit keyword-based influence or tactical suggestions through a low-latency data channel, rather than relying solely on asynchronous social feed comments. This integration enhances the real-time interactivity and immersiveness of the described multi-status gameplay model.