Objects

When a Basketball Court Becomes a Message

Follow First Mobile Device alongside User Input: A first mobile device displays basketball-court visuals and receives user input indicating a player's action sequence.

Clay-diorama editorial illustration related to System And Method Of Basketball Testing.

First, the setting

Basketball practice is built around seeing where players move, how they choose to pass or shoot, and how a team responds. Coaches and players revisit those moments because small decisions on a court can be difficult to notice while everyone is running.

In a gym, a player or coach holds a phone or tablet beside the court, then taps through a sequence of passes, dribbles, and shots on a court diagram. Another person nearby sees a matching court view appear on a separate screen, with a hoop and action markers placed on it.

What changes in this design

Without this system, a person might enter basketball actions on one screen and have no court-based view of them on another screen. A reader could otherwise expect the actions to remain tied to the starting device.

Here, the starting device turns the person's choices into encoded information, sends it to a server, and triggers a notification for another device. That other screen displays the court and action elements, with hoop placement influenced partly by a player profile.

This matters because the basketball action information is presented as a court view at a second location. It also shows that the player profile can affect where the hoop appears.

Court Sequence and Handoff

User input indicating a player's action sequence is the cause, a notification on a second mobile device is the effect, and the next choice is how that second screen places the hoop among the action elements. US20260257107A1, published September 3, 2026, under the title System And Method Of Basketball Testing, begins with basketball-court visuals on a first mobile device. That picture matters because it makes the starting point ordinary: someone indicates a sequence of player actions on a court rather than beginning with an unseen calculation.

From that visible beginning, the filing describes a sequence in order: the first device receives the input, encodes it, sends it to a server, and triggers the second-device notification. To encode here means to turn the indicated action sequence into information the system can send. The server has the air of a quiet clipboard between the first screen and the second. That modest handoff made me look twice, because the arrangement makes movement between screens part of the mechanism, not merely a change of view.

Once that notification has occurred, the second device displays the court with action elements. Its hoop placement is determined partly from the player's profile. The published record does not say which profile details are involved, and that boundary is worth keeping visible. At this point, the hoop placement behaves less like a fixed prop and more like a stage mark that consults the player's profile. The point is not that the hoop becomes a promise; it is a setting whose response is specified only to the limited extent the filing gives us.

Profile-Guided Hoop Placement

That limitation leads to the purpose I can responsibly see in the arrangement: it connects an action sequence entered on one court view to a related court view on another device, while allowing hoop placement to draw partly on profile information. The title calls the arrangement basketball testing, but its clearest design question is broader: when should a system carry forward a user's indicated sequence, and when should it condition one visible element on information already associated with a player? You can spot two concrete choices here: the input is captured before the second display is shown, and the profile affects hoop placement rather than being described as altering every action element.

Settings Versus Promises

That distinction sets up the useful contrast. A setting is a defined condition in an arrangement, such as the stated relationship between the player's profile and hoop placement. A promise is an assumed outcome, such as presuming that a profile-related placement will necessarily make the testing better, clearer, or suitable for a particular person. The filing gives the setting, not those broader outcomes. Framed this way, the defined response replaces a guess: a profile partly informs placement, while the system still begins with the action sequence the user indicates.

From there, the transferable test is pleasantly small. When you meet any system that moves a selection from one place to another, ask first where the selection is translated into sendable information, then ask which visible element is explicitly allowed to vary, and finally ask what outcome you are being tempted to assume. By the end, the sequence has the air of a stage manager following one cue at a time. I think that three-beat check keeps a setting from quietly dressing itself up as a promise, which is a consequence you can use wherever an interface turns an input into a tailored display.

The record, briefly. US20260257107A1, “System And Method Of Basketball Testing” A first mobile device displays basketball-court visuals and receives user input indicating a player's action sequence, encodes and sends it to a server, and triggers a second device notification. The second device displays the court with action elements, including a hoop placement determined partly from the player's profile.

More angles on this

Read around this one:Public patent recordUSPTO published figure