All documents mentioned in this specification are herein incorporated by reference to the same extent as if each individual document was specifically and individually indicated to be incorporated by reference.
It should be noted that throughout the disclosure, where a definition or use of a term in any incorporated document(s) is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the incorporated document(s) does not apply.
One or more embodiments of the present invention relate to a system and a method using a virtual focal point that is perceptible (observable or discernible, etc.) in a real, physical game. More particularly, one or more embodiments of the present invention relate to a system and a method using a virtual focal point in a real, physical, in-person multi-player game using one or more computing devices.
Conventional physical-digital games using multiple players with computing devices that may also use a real physical object such as a ball or flag are well known and have been in use for a number of years. As a non-limiting example, multiple players with their player computing devices (e.g., wearable device) may electronically tag other player devices, with a physical player of an electronically tagged device physically handing over a physical object such as a real physical ball or a flag to the player with the electronically tagging player device.
Regrettably, for most players and spectators such physical-digital games are confusing to follow since the players are dispersed and the devices used by players provide limited information, which are generally available to each individual player associated with the device only. Further, there is a physical delay between the time player devices are electronically tagged and the recognition of the players that their devices have been tagged. For example, a player device may have been electronically tagged by another player device, but the tagged player may continue to play as if they have not been tagged, unaware of the fact that their device is tagged. This creates confusion for both players and spectators.
In drone aerial combat using ZTAG®, LED indicators mounted on drones is another “tag” game based on multiple players with drones. The ZTAG®, LED indicators are visible only to the player with the remote control of the drone (similar to a heads-up display). The object of the game is similar to a tag game where one drone electronically tags another drone, with the ZTAG®, LED indicators notifying the player that their drone has been tagged. Use of drones in such games is even more confusing in that all activity takes place hundreds of feet above and away from players and spectators. For example, a drone flying hundreds of feet in air at a left-end of a large open field does not provide tagging status information about itself to other players or to spectators. This creates confusion for players. The problem is compounded for spectators, where they would merely observe random, confusing mess of flying motions and directions of multiple drones, not knowing which drone is being chased and or which is tagged.
Accordingly, a system and a method are needed that would provide a virtual focal point that would be perceptible (or observable or discernible, etc.) in a real, physical game by players and spectators. More particularly, a system and a method are needed that would provide a virtual focal point in a real, physical, in-person multi-player game using one or more computing devices that would enable both players and spectators to “follow” the game and not be confused.
A non-limiting, exemplary aspect of an embodiment of the present invention provides a gaming system, comprising:
Another non-limiting, exemplary aspect of an embodiment of the present invention provides a gaming system, comprising:
Still another non-limiting, exemplary aspect of an embodiment of the present invention provides a gaming system, comprising:
A further non-limiting, exemplary aspect of an embodiment of the present invention provides a gaming system, comprising:
These and other features and aspects of the invention will be apparent to those skilled in the art from the following detailed description of preferred non-limiting exemplary embodiments, taken together with the drawings and the claims that follow.
It is to be understood that the drawings are to be used for the purposes of exemplary illustration only and not as a definition of the limits of the invention. Throughout the disclosure, the word “exemplary” may be used to mean “serving as an example, instance, or illustration,” but the absence of the term “exemplary” does not denote a limiting embodiment. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. In the drawings, like reference character(s) present corresponding part(s) throughout.
The detailed description set forth below in connection with the appended drawings is intended as a description of presently preferred embodiments of the invention and is not intended to represent the only forms in which the present invention may be constructed and or utilized.
It is to be appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention that are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable sub-combination or as suitable in any other described embodiment of the invention. Stated otherwise, although the invention is described below in terms of various exemplary embodiments and implementations, it should be understood that the various features and aspects described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in various combinations, to one or more of the other embodiments of the invention.
For purposes of illustration, programs and other executable program components are illustrated herein as discrete blocks, although it is recognized that such programs and components may reside at various times in different storage components, and are executed by the data processor(s) of the computers. Further, each block within a flowchart (if a flowchart is used) may represent both method function(s), operation(s), or act(s) and one or more elements for performing the method function(s), operation(s), or act(s). In addition, depending upon the implementation, the corresponding one or more elements may be configured in hardware, software, firmware, or combinations thereof.
The below-described computer hardware and software are presented for purposes of illustrating the basic underlying computer components that may be employed for implementing the present invention. The present invention may be implemented in any well-known type of system architecture or processing environment capable of supporting the methodologies of the present invention presented in detail below. Therefore, for example, the present invention may operate directly between computing devices with or without the use of a central computing device (or a Central Command, further detailed below). In general, computing devices, databases, and networks that may be used in accordance with one or more embodiments of the present invention are very well documented in the technical, trade, and patent literature.
The present invention provides a user interface that is understandable by human intellect and human senses for interaction. A non-limiting example of a user interface may include physical interface or graphic user interface (GUI) to allow a visual way of interacting with computing devices. The disclosed user interface (if any), provided throughout the disclosure is meant to be illustrative and for convenience of example only and should not be limiting. Therefore, the present invention is not limited to any particular user interface configuration and may be implemented in a variety of different types of user interfaces (physical or virtual—GUI). Further, all user interface representations (if any) of any concepts, aspects, functions, or features may be varied and therefore, none should be limiting. The non-limiting, non-exhaustive illustrations of the user interfaces (if any) used throughout the disclosure are provided only for a framework for discussion.
One or more embodiments of the present invention define “virtual” as not physically existing as such but made by software to appear to do so, and carried out, accessed, or stored by means of one or more computing devices (networked or otherwise).
One or more embodiments of the present invention define non-virtual as physically existing in real, physical space. Throughout the disclosure “non-virtual”, “real”, “physical”, or “physical space” may be used interchangeably.
One or more embodiments of the present invention define a “Virtual Focal Point” (or VFP) as a virtual center of focus that is perceptible (observable, noticeable, discernible, etc.) in the real physical space.
One or more embodiments of the present invention define tag, tagging, tagged, etc. or shoot, or hit, etc. as when one computing device electronically breaches an electronic proximity threshold of another computing device and or when one computing device's targeted signal is received by another computing device. Non-limiting examples of a targeted signal are electronic signals, acoustic signals, RF signals, IR signals, etc. that may be either directional or non-directional (e.g., broadcast) signals, etc.
Accordingly, it should be understood that the terms “tag,” “tagging,” “tagged,” “hit,” “shoot,” etc. are equivalent and shorthand for “electronic tagging” “electronically tagged,” “electronically hit,” etc.
One or more embodiments of the present invention define the phrase “physical-digital” as an actual physical game played by physically active players that involved the use of digital devices.
It should be noted that throughout the disclosure, all signals (e.g., RF, IR, etc.), signal transmissions, signal communications, etc., may use any well-known packet format types, non-limiting examples of which may be those used in Ethernet protocol, WLAN, or any other similar format types, subsets thereof, etc.
One or more embodiments of the present invention provide a system and a method that uses a virtual focal point that may be perceptible (or observable or discernible, etc.) in real, physical space by players and spectators. More particularly, a system and a method are provided that introduce a virtual focal point in a real, physical, in-person multi-player game using one or more computing devices that enables both players and spectators to “follow” the game based on the perceptible (or observable or discernible, etc.) virtual focal point and not be confused.
A non-limiting example of actualization “or transfer” of a virtual focal point would be to enable a computing device to store a Boolean of “hasPossession”. If the Boolean “hasPossession” returns a TRUE, then the device may switch to an active state of an instance of VFP. As a non-limiting, example, it may provide perceptible, discernible, or observable indication (e.g., emit visual and or audio indicators) to signal to other participants and spectators that it has possession of a virtual focal point. On the other hand, if the Boolean “hasPossession” returns a FALSE, then the device will return to its default output state of an IN-active state of an instance of VFP.
Accordingly, as illustrated in
The present invention may be implemented on conventional computing machines.
Computer device 100 shown in
Further included are a number of different communication modules for implementing desired communication protocol and their respective communications interface (e.g., transceiver modules) for transmitting and receiving data or signal packets, and may or may not include other components 172 such as an image/video/sound capture device such as a camera, voice recording microphone, stylus, etc.
In the non-limiting, exemplary instance illustrated in
In this non-limiting, exemplary instance, omni-directional transmission of data/signal packets may be implemented using Radio Frequency (RF) for radio transmission rTx and radio reception rRx of various signal/packets intended for omni-directional transmission via a well-known RF Module 102.
In this non-limiting, exemplary instance, directional (or line-of-sight) transmission of data/signal packets may be implemented using Infrared (IR) signal/packets for IR transmission iTx and IR reception iRx of various signal/packets intended for directional transmission via a well-known first Universal Asynchronous Receiver/Transmitter (or UART1) 104 module of MCU 166 through IR emitter IR TX 110 and IR sensor IR RX 112. It should be noted that sound, RF transmission/reception, etc., may also be used for directional signaling.
As further illustrated, computing device 100 may further include a second UART2 106 for RF transmission and reception of RF signals/packets in communications with a display or other peripherals (e.g., flight control for drones) 108.
In this non-limiting, exemplary instance, other omni-directional and or directional transmission of data/signal packets may be implemented using other medium such as acoustic signals (e.g., ultrasound) for transmission oTx and reception oRx of various signal/packets via any well-known transducer 460. As a very specific, non-limiting, example, MCU 166 may be connected to a speaker to transmit acoustic signals oTx and a microphone to receive acoustic signals oRx, both of which may be implemented as either directional or omni-directional.
As further illustrated, the computing device further includes I/O ports 114 communicatively associated with one or more external indicators 116, other network of sensors 118, and other input/output devices 160. The present invention may further include other external network of sensors 120 in communication with computing device 100. Network of sensors 118 and 120 may include, for example, GPS, altimeter, etc. that gather real-time location & orientation information of objects, computing device 100, etc. including body-mounted and field-embedded sensors.
Player computing devices 128, optional Central Command computing device 122, and the optional Neutral computing device 124 are all identical to computing device 100 illustrated in
As illustrated in
Although not illustrated, all computing devices 100 may comprise one or more standalone devices connected to one or more server systems (not shown) using a well-known conventional network/Internet and conventional communications protocols. The network/Internet may be any one of a number of conventional, well-known network systems that includes functionality for packaging computing device 100 communications in any well-known manner together with any parameter (or attributes) information into a format (of one or more packets) suitable for communications between the server systems and computing devices 100 (e.g., player computing devices 128, the optional Central Command computing device 122, and or the optional Neutral computing device 124).
As illustrated in
Further, a computing device 100 of the plurality of the computing devices may initially exhibit an active state of an instance of a VFP 132, and another computing device of the plurality of the computing devices may initially exhibit an IN-active state of the instance of the same VFP 132 as that of the computing device.
As a specific example, for the instance 134 shown in
As another example shown in
It should be noted that for convenience and to distinguish or identify a specific computing device 100 (in particular, distinguishing a player computing device 128 from another player computing device 128), references such as “first computing device” and “second computing device” may also be used. In such instances, a computing device 100 that initially exhibits an active state of an instance of a VFP 132 may be defined as the first computing device, and another computing device of the plurality of the computing devices that initially exhibits an IN-active state of the instance of the same VFP 132 as that of the computing device may be defined as the second computing device. For example, for the selected instance 134 shown in
As another example, for the selected instance 136 shown in
As illustrated
Referring to
It should be noted that
The following detail a non-limiting, non-exhaustive exemplary set of methodologies for “transfer” of a VFP from one computing device to another. It should be noted that the reasons for the “transfer” of VFP are many and may depend on many factors, non-limiting, non-exhaustive examples of which may include, for example, the type of game played, the game rules, etc.
As illustrated, MCU 166 based on Game Logic 168 of a computing device 100 at operations 302 determines if a Directional Signal Packet transmission is enabled. If MCU 166 determines that the Directional Signal Packet transmission is not enabled, then there would be no transmission (operations 304). Depending on the game, game rules, etc. the Directional Signal Packet transmission may remain disabled or become enabled.
As further illustrated in
As best illustrated in
The payload may further include a source device ID, which is the identification of the source from which the directional signal was transmitted. In a non-limiting, exemplary instance, another computer (for example, a second computing device) may be identified as the source of the signal received by a computing device (e.g., a first computing device).
The payload of the Directional Signal Packet may also include a destination device ID, which in this example, is defined as broadcast. That is, the signal packet shown in
As illustrated, MCU 166 based on Game Logic 168 of a computing device 100 at operations 310 determines if RF transmission is enabled. If MCU 166 determines that the RF transmission is not enabled, then there would be no RF transmission (operations 312). Depending on the game, game rules, etc. the RF signal packets transmission may remain disabled or become enabled.
As further illustrated in
Referring back to
In the non-limiting, exemplary instance shown in
At operations 320 MCU 166 determines if a Directional Signal Packet is received. MCU 166 may determine receipt of a Directional Signal Packet based on Game Logic 168 (for example, via the IR Rx receiver 112 associated with the UART1 TxRx transceiver 104 or Transducer TX/RX 460, etc.).
If MCU 166 of the computing device (e.g., first computing device) at operations 320 determines that a Directional Signal Packet is received, the computing device based on Game Logic 168 of MCU 166 at operations 322 broadcasts an RF VFP Handoff Signal Packet (
It should be noted that as further detailed below, depending on hardware setup (as shown in
As best illustrated in
The payload may further include a source device ID, which is the identification of the source from which the RF VFP Handoff Signal Packet was transmitted. In a non-limiting, exemplary instance, this would be the computing device with the active state of the instance of the VFP.
The payload of the RF VFP Handoff Signal Packet may also include a destination device ID, which in this exemplary instance may be the device ID of the computing device with the IN-active state of the instance of the VFP. More specifically, the destination ID is of the second computing device that has successfully transmitted a directional signal packet (
Referring back to
As further detailed in
As indicated above,
As illustrated in
If at operations 346 MCU 166 determines that an RF VFP Handoff Signal Packet (
Intended recipient may be identified by device IDs of both the transmitter (source ID) and receiver (destination ID) payloads of the RF VFP Handoff Signal Packet. For example, the source ID may be the ID of the computing device with the active state of the instance of the VFP and the destination ID may be the ID of the computing device with the IN-active state of the instance of the VFP.
If the MCU 166 determines that the computing device which received the RF Handoff Signal Packet is the intended recipient at operations 348, then MCU 166 executes operations 350; otherwise, MCU 166 loops back to operations 344.
At operations 350 MCU 166 of the destination computing device may transmit an RF VFP Receiver Signal Packet (
It should be noted and as further detailed below, depending on hardware setup (as shown in
Since the computing device at operations 458 now exhibits an active state of the instance of the VFP, it now may operate as indicated in
If at operations 332 MCU 166 of the computing device (e.g., second computing device) with IN-active state of an instance of a VFP determines that it received a Directional Signal Packet, MCU 166 executes operations 334. That is, at operations 334 the computing device (e.g., second computing device) with IN-active state of an instance of a VFP broadcasts an RF Hit-Acknowledgement (Hit-ACK) Signal Packet, detailed in
Referring to
The payload may further include a source device ID, which is the identification of the source from which the RF Hit-ACK Signal Packet is transmitted.
The payload of the RF Hit-ACK Signal Packet may also include a destination device ID, which may be in broadcast mode or specific a particular recipient. That is, the RF Hit-ACK Signal Packet shown in
At operations 354, MCU 166 determines if the received RF Signal Packet is an RF VFP Handoff Signal Packet (
If at operations 354 the computing device (e.g., the second computing device) determines that the RF Signal Packet is not a RF VFP Handoff Signal Packet, then at operations 358 MCU 166 determines if the RF Signal Packet received is a Hit-ACK Signal Packet (
At the Start operations 382, no player computing device 128 participating in a game that may require CPT processing has or exhibits an active state of an instance of a VFP. Instead, the required active state of an instance of a VFP may be exhibited by a Neutral computing device. In this instance, the Neutral computing device may be thought of as the “first computing device” and all other players computing devices defined as the “second computing device” or subsequent computing devices. Accordingly, MCU 166 of player computing devices in the game sets respective CPT counters of player computing devices 128 to zero at operations 384.
When the game commences, at operations 386, any player computing device 128 that first successfully tags or targets the Neutral computing device 124 may “retrieve” an active state of an instance of a VFP from the Neutral computing device as detailed in
As further illustrated, at operations 388 the CPT COUNTER of the player computing device 128 with the active state of the instance of the VFP is varied incrementally by the MCU 166 of the player computing device 128.
At operations 390, MCU 166 of the player computing device 128 determines if the CPT is beyond threshold and if so, at operations 392 the player computing device with CPT count beyond threshold wins.
If MCU 166 at operations 390 determines that the CPT count is not beyond threshold, MCU 166 at operation 394 determines if the player computing device 128 with the active instance of the state of the VFP received a Directional Signal Packet (i.e., has the player device been tagged by another player device).
If MCU 166 of the player computing device 128 with the active instance of the state of the VFP determines that no Directional Signal Packet is received, then operations 388 and operations 390 are executed.
If MCU 166 of the player computing device 128 with the active instance of the state of the VFP determines that a Directional Signal Packet is received, then at operations 396 CPT counter is stopped. Optionally, operations 326 and operations 328 may first be executed before operations 396. This way, the CPT counter will continue counting until the number “hits” or “tags” as a result of receiving Directional Signal Packets is beyond a certain threshold.
At operations 398 VFP is transferred via a broadcast of a VFP Release Signal Packet (
Referring to
The payload may further include a source device ID, which is the identification of the source from which the RF VFP Release Signal Packet is transmitted.
The payload of the RF VFP Release Signal Packet may also include a destination device ID, which may be in broadcast mode and include the identification of the source of the computing device that successfully transmitted the Directional Signal Packet (the computing device with IN-ACTIVE state of the instance of the VFP).
The payload of the RF VFP Release Signal Packet may also include Team CPTs, for example, CPT for Team A and CPT for Team B, in addition to Team Source ID, which identifies the player device team that transmits the RF VFP Release Signal Packet.
Referring back to
Depending on the game and game rules, the method of initialization for every hardware with respect to an ACTIVE or IN-active state of an instance of a VFP may be varied. For example, when starting a game, initial condition or state of the Neutral computing device 124 may be such that upon start it will always exhibit an ACTIVE or IN-active state of an instance of a VFP. As another example, depending on the rules of the game, a player computing device 128 may by default exhibit an ACTIVE state of an instance of a VFP. Accordingly, a Neutral computing device 124 may be use for a variety of reasons in various games. For example, one or more Neutral computing device 124 may function as “goal” posts, targets, or a neutral starting point between two player computing devices, etc.
Accordingly, the flowchart of
As illustrated, in the non-limiting, exemplary instance shown in
At operations 404 MCU 166 of the Neutral computing device determines if a Directional Signal Packet is received. MCU 166 may determine receipt of a Directional Signal Packet based on Game Logic 168 (for example, via the IR Rx receiver 112 associated with the UART1 TxRx transceiver 104 or Transducer TX/RX 460).
If MCU 166 of the Neutral computing device 124 at operations 404 determines that a Directional Signal Packet is received, Neutral computing device 124 based on Game Logic 168 of MCU 166 at operations 406 broadcasts an RF VFP Handoff Signal Packet (
It should be noted that as further detailed below, depending on hardware setup (as shown in
As further detailed in
As illustrated in
At operations 412 the targeted computing device exhibiting an IN-active state of the instance of the VFP determines if it has received a Directional Signal Packet and if so, MCU 166 of the targeted computing device activates an incremental counter to record a score at operations 414. It should be noted that this updated score may be displayed on a scoreboard visible to all players and spectators and may also be available as a payload of an RF broadcast signal transmitted by the target computing device to all other player computing devices, very similar to CPT updates of RF Release Signal Packet shown in
Referring back to
As illustrated, a Central Command computing device 122 may be used to select the computing device (player computing device, Neutral computing device, etc.) that will be granted the possession of an active state of an instance of a VFP (operations 420). For example, the Central Command computing device 122 may transmit an RF SET VFP Signal Packet (
At operations 422, the selected computing device receives and stores RF Signal Packet with VFP payload and hence, becomes a computing device with the active state of the instance of the VFP, while at operations 424 Central Command computing device commences the game.
The payload section of the RF Set-VFP Signal Packet may comprise of a Packet Type, which is Set-VFP, a Source ID (which is the ID associated with the Central Command computing device), and a Destination ID, which is the ID of the selected computing device.
As is indicated above, depending on hardware setup (as shown in
As illustrated, operations 426 is a representative of operations (by an MCU 166 of any computing device) that exhibits active state of the instance of the VFP, broadcasting VFP Handoff Signal Packet, and initiates VFP Transfer Process.
The computing device may communicate the transmission of the RF VFP Handoff Signal Packet with a Central Command computing device using the “hand-shake” operations detailed in
At operations 452 MCU 166 of Central Command computing device 124 receives the RF VFP Handoff Signal Packet (again, via the processes of
Additionally, MCU 166 of Central Command computing device 124 at operation 452 may transmit to a computing device with the IN-active state of the instance of the VFP an RF VFP Handoff Signal Packet. Again, the Central Command computing device may communicate the transmission of the RF VFP Handoff Signal Packet with the computing device using the “hand-shake” operations detailed in
It should be noted that any well-established and well-known methods of transfer with certain level of reliability may be used, including for example, using the Message Queuing Telemetry Transport Quality of Service (or MQTT QOS=2), with MQTT protocol specifying the quality of service, which guarantees the reliability of message delivery under different network environments. Alternatively, all signal transmissions may be simple one-time transmissions from one device to another without any handshake or reliability checks.
As illustrated, in
On the other hand, operations 372, 374, 376, 378, and 380 may be carried out by the MCU 166 of the other computing device (e.g., the second computing device) with an IN-active state of the instance of the VFP of the first computing device.
Further, the entry point for execution of the Transmit Handoff Signal Packet of VFP operation 362 may be from operations (e.g., 322, 426, etc.) that transmit a VFP Handoff Signal Packet and initiate VFP transfer process by a computing device (e.g., the first computing device) and the entry point for the execution of the Received VFP Handoff Signal Packet operations 372 may be from other operations such as operation 350 (
As illustrated, the computing device exhibiting an ACTIVE state of an instance of a VFP transmits an RF VFP Handoff Signal Packet at operations 362 to the other computing device exhibiting an IN-active state of the instance of the VFP.
The other computing device exhibiting the IN-active state of the instance of the VFP receives RF VFP Handoff Signal Packet at operations 372, and transmits a VFP Handoff-Acknowledgement (Handoff-ACK) Signal Packet the computing device (e.g., the first computing device) at operations 374.
At operations 364 the computing device (e.g., first computing device) exhibiting the ACTIVE state of the instance of the VFP determines if RF VFP Handoff-ACK Signal Packet from the other computing device (e.g., second computing device) exhibiting the IN-active state of the instance of the VFP is received.
If the computing device (e.g., first computing device) determines that the VFP Handoff-ACK Signal Packet is not received, MCU 166 of the computing device (e.g., first computing device) re-transmits VFP Handoff Signal Packet at operations 362. As indicated in the flow, the loop of operations 362, 372, 374 and 364 may be aborted after multiple tries.
If the computing device (e.g., first computing device) determines that the VFP Handoff-ACK Signal Packet is received, it transmits a VFP Release Signal Packet at operations 366 to other computing device (e.g., the second computing device).
The other computing device (e.g., the second computing device) at operations 376 determines if the VFP Release Signal Packet from the computing device (e.g., first computing device) is received.
If the other computing device (e.g., second computing device) determines that the VFP Release Signal Packet is not received, MCU 166 of the other computing device (e.g., second computing device) re-transmits VFP Handoff-ACK Signal Packet at operations 374. As indicated in the flow, the loop of operations 376, 374, 364, and 366 repeats and may be aborted after multiple tries.
If the other computing device (e.g., second computing device) determines that the VFP Release Signal Packet is received at operations 376, the other computing device transmits VFP Transfer Complete Signal Packet to the computing device (e.g., the first computing device).
At operations 368 the computing device (e.g., first computing device) determines if VFP Transfer Complete Signal Packet is received from the other computing device (e.g., the second computing device).
If the computing device (e.g., first computing device) determines that the VFP Transfer Complete Signal Packet is not received, MCU 166 of the computing device (e.g., first computing device) re-transmits VFP Release Signal Packet at operations 366. As indicated in the flow, the loop of operations 368, 366, 376, and 378 repeats and may be aborted after multiple tries.
If the computing device (e.g., first computing device) determines that the VFP Transfer Complete Signal Packet is received, the computing device that exhibited the active state of the instance of the VFP now exhibits the IN-active state of the instance of the VFP at operations 370, and the other computing device that exhibited the IN-active state of the instance of the VFP of the computing device (first computing device) now exhibits an ACTIVE state of the instance of the of the computing device (first computing device) in operations 380.
Situations may arise in most games where a first computing device may “pass” the ACTIVE state of an instance of a VFP to another computing device with an IN-active state of the instance of the VFP of the computing device (similar to a game of football where the ball is passed from one player to another team player, for example).
Specifically, the invention disclosed provides complementary methods of VFP transfer between players of the different teams (taking possession of VFP from an opponent) and players of the same team (giving possession of VFP to a teammate). A VFP transfer between players of different teams is typically involuntary while a VFP transfer between players of the same team is typically voluntary. Both methods of VFP transfer require the directional signal of a computing device A to be received by another computing device B (
As illustrated in
The payload of the Directional VFP Handoff Signal Packet may comprise of a Packet type, which identifies the signal packet as VFP Handoff. Further included as payload may be a source ID (from which the Directional VFP Handoff Signal Packet was transmitted) and a destination ID in broadcast mode.
Referring back to
If MCU 166 of the second computing device (the one with the IN-active state of the instance of the VFP) determines that it has received a Directional VFP Handoff Signal Packet, at operations 432 the second computing device transmits a RF VFP Handoff ACK Signal Packet (
The payload of the RF VFP Handoff ACK Signal Packet may comprise of a Packet type, which identifies the signal packet as VFP Handoff Acknowledgement (or ACK). Further included as payload may be a source ID (from which the RF VFP Handoff ACK Signal Packet was transmitted) and a destination ID of the first computing device (device with the active state of the instance of the VFP) that transmitted the Directional VFP Handoff Signal Packet.
Referring back to
As indicated above,
At operations 444 the MCU 166 of the first computing device determines if the VFP Handoff-ACK Signal Packet is received and if so, at operations 446 MCU 166 determines if it was the intended recipient.
If the MCU 166 of the first computing device with the active state of the instance of the VFP determines that the RF VFP Handoff-ACK Signal Packet received is itself the intended recipient at operations 446, then MCU 166 executes operations 448 otherwise, MCU 166 loops back to operations 442.
At operations 448 MCU 166 of the first computing device with the active state of the instance of the VFP initiates VFP transfer process (
The following
Gaming systems illustrated in
The objective of Drone Oddball game is to be the first drone to take possession of the VFP (exhibit an ACTIVE state of an instance of VFP) for some cumulative time, or be the drone with the most cumulative possession time (CPT) when some game timer runs out.
A first drone 436 with VFP 132 may be tagged by a second drone 438, at which point VFP 132 transfers to second drone 438 (progressively shown in
The game may commence with the ACTIVE state of an instance of VFP for one drone. In this exemplary instance, drone 436 is determined (for example, by a toss of a coin) to exhibit an ACTIVE state of an instance of VFP 132. Alternatively (as shown in
As demonstrated, a cumulative possession time (CPT) for both drone 436 and 438 may be accounted for using their respective MCU 166 executing operations shown in
The aim of the game is to take possession of the VFP from a Neutral Computing device 124 with an ACTIVE state of an instance of a VFP 132 and score points by transferring the VFP 132 to a designated target 124 (which may comprise of another Neutral computing device 124).
As illustrated in
As illustrated in
As best illustrated in
As illustrated in
This physical game is similar to a football with goal posts 456 that may be on opposite sides of a football field, which may include additional sensors 120 or computing devices 100 (best shown in
In this game, a point is scored whenever a drone with an ACTIVE state of an instance of a VFP 132 flies between the goal posts of the opposite team (best shown in
After a score, ACTIVE state of an instance of a VFP 132 may switch to the opposing team and the game continues (as with any football game). It should be noted that a coin toss may determine which team has the initial ACTIVE state of an instance of a VFP 132. Alternatively, as with
When the game starts, the objective is for the drone with an ACTIVE state of an instance of a VFP 132 to pass between goal posts 456. A drone may lose the ACTIVE state of the instance of the VFP 132 (e.g.,
In this game, the drone with ACTIVE state of the instance of the VFP 132 does not emit IR signal to tag any other drone (for example, as per the operations 304 of the flowchart shown in
Player computing devices (e.g., drones) with IN-active state of an instance of a VFP 132 may both tag and potentially be tagged by drones. For example, if a drone IN-active state of an instance of a VFP 132 is tagged, that drone may temporarily lose the ability to emit IR signal to tag other drones for a certain period.
Based on the above game mechanics, a cooperative strategy develops because teammates of the drone with ACTIVE state of an instance of a VFP 132 will try to fly in formation in order to protect the drone with ACTIVE VFP 132 from opponents.
Opponents being tagged will be temporarily unable to tag and thus, giving additional time for the drone with ACTIVE state of an instance of a VFP 132 to maintain possession (for those instances where CPT is desired).
This physical game is similar to a football with goal posts 456 that may be on opposite sides of a football field, which may include additional sensors 120 and or computing devices 100.
In this game, a point is scored whenever a drone with an ACTIVE state of an instance of a VFP 132 passes VFP 132 to computing device 100 associated with the goal posts 456 of the opposite team. In other words, the drone need not go through the goal posts 456.
In this non-limiting, exemplary instance, neutral computing device 124 may be used to determine which drone will have the ACTIVE state of an instance of a VFP 132 in the manner discussed in
After a score, ACTIVE state of an instance of a VFP 132 may switch back to the opposing team and or the neutral computing device 124 and the game continues as with any football game.
As shown in
As shown in
As shown in
Although the invention has been described in considerable detail in language specific to structural features and or method acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary preferred forms of implementing the claimed invention. Stated otherwise, it is to be understood that the phraseology and terminology employed herein, as well as the abstract, are for the purpose of description and should not be regarded as limiting. Further, the specification is not confined to the disclosed embodiments. Therefore, while exemplary illustrative embodiments of the invention have been described, numerous variations and alternative embodiments will occur to those skilled in the art. For example, any one or more of the specified payloads of any one or more of any signal packet(s) may be varied and or moved to other packets, based on game, game rules, efficiency of data transfer, or many other factors, etc. As another example, the hardware and methods presented are not limited to be mounted on drones, but can equally apply to any moving object that is human controlled such as Radio Controlled (RC) cars, RC boats, or running players wearing computing devices 100. Such variations and alternative embodiments are contemplated, and can be made without departing from the spirit and scope of the invention.
It should further be noted that throughout the entire disclosure, the labels such as left, right, front, back, top, inside, outside, bottom, forward, reverse, clockwise, counter clockwise, up, down, or other similar terms such as upper, lower, aft, fore, vertical, horizontal, lateral, oblique, proximal, distal, parallel, perpendicular, transverse, longitudinal, etc. have been used for convenience purposes only and are not intended to imply any particular fixed direction, orientation, or position. Instead, they are used to reflect relative locations/positions and/or directions/orientations between various portions of an object.
In addition, reference to “first,” “second,” “third,” and etc. members throughout the disclosure (and in particular, claims) is not used to show a serial or numerical limitation but instead is used to distinguish or identify the various members of the group.
Further the terms “a” and “an” throughout the disclosure (and in particular, claims) do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced items.
The use of the phrases “and or,” “and/or” throughout the specification (if any used) indicate an inclusive “or” where for example, A and or B should be interpreted as “A,” “B,” or both “A and B.”
In addition, any element in a claim that does not explicitly state “means for” performing a specified function, or “step for” performing a specific function, is not to be interpreted as a “means” or “step” clause as specified in 35 U.S.C. Section 112, Paragraph 6. In particular, the use of “step of,” “act of,” “operation of,” or “operational act of” in the claims herein is not intended to invoke the provisions of 35 U.S.C. 112, Paragraph 6.
This Application claims the benefit of priority of U.S. Utility Provisional Patent Application 63/183,739, filed 4 May 2021 the entire disclosure of which is expressly incorporated by reference in its entirety herein.
Number | Name | Date | Kind |
---|---|---|---|
8391825 | Arseneau et al. | Mar 2013 | B2 |
8570168 | Logan et al. | Oct 2013 | B2 |
8651961 | Muller | Feb 2014 | B2 |
8860760 | Chen et al. | Oct 2014 | B2 |
9047698 | Maciocci et al. | Jun 2015 | B2 |
9077865 | Molyneux | Jul 2015 | B1 |
9143564 | Milburn et al. | Sep 2015 | B2 |
9330478 | Anderson | May 2016 | B2 |
9700781 | Monari et al. | Jul 2017 | B2 |
9734477 | Weast et al. | Aug 2017 | B2 |
9741244 | Berelejis et al. | Aug 2017 | B2 |
9832441 | Osman | Nov 2017 | B2 |
9898663 | Wexler et al. | Feb 2018 | B2 |
10089772 | Tayloer et al. | Oct 2018 | B2 |
10104329 | Faratzis | Oct 2018 | B2 |
10105619 | Gutierrez et al. | Oct 2018 | B2 |
10127723 | Miller | Nov 2018 | B2 |
10176637 | Billbrey et al. | Jan 2019 | B2 |
10203762 | Bradski et al. | Feb 2019 | B2 |
10336469 | Mallinson | Jul 2019 | B2 |
10653337 | Markison et al. | May 2020 | B2 |
20060287113 | Small et al. | Dec 2006 | A1 |
20070053201 | Dietz et al. | Mar 2007 | A1 |
20090325699 | Delgiannidis | Dec 2009 | A1 |
20110300941 | Weston et al. | Dec 2011 | A1 |
20120105466 | Leslie | May 2012 | A1 |
20120229381 | Langridge | Sep 2012 | A1 |
20130130758 | Moore | May 2013 | A1 |
20140204002 | Bennet et al. | Jul 2014 | A1 |
20140320824 | Kim et al. | Oct 2014 | A1 |
20140328485 | Saulters | Nov 2014 | A1 |
20160134911 | Tetreault | May 2016 | A1 |
20160228764 | Condon et al. | Aug 2016 | A9 |
20160317383 | Stanfield et al. | Nov 2016 | A1 |
20170006356 | Krasadakis | Jan 2017 | A1 |
20180052648 | Ziv et al. | Feb 2018 | A1 |
20180077276 | Wright et al. | Mar 2018 | A1 |
20180174401 | Iao et al. | Jun 2018 | A1 |
20180234742 | Abrams | Aug 2018 | A1 |
20180329671 | Einziger et al. | Nov 2018 | A1 |
20180352303 | Siddique et al. | Dec 2018 | A1 |
20180364741 | Van Voorst | Dec 2018 | A1 |
20190132372 | Litsyn et al. | May 2019 | A1 |
20190162834 | Al-Alusi | May 2019 | A1 |
20190246146 | Bustamante et al. | Aug 2019 | A1 |
20220402606 | Kovács | Dec 2022 | A1 |
Number | Date | Country |
---|---|---|
0869378 | Mar 1996 | JP |
6499154 | Mar 2019 | JP |
101591579 | Feb 2016 | KR |
Entry |
---|
Cradle: Combined RF/Acoustic Detection and Localization of Passive Tags; Arbabian et al. IEEE Publication vol. 68, No. 6, Jun. 2021. |
Energy-Neutral Devices: Can Hybrid RF-Acoustic Signals Point Them Out?; COX et al. Dept of EE, Ku Leuven, Belgim Dec. 2020. |
High Percision Hybrid RF Ultrasonic Chirp-Based Ranging for Low Power IOT Nodes; Cox et al., Eurasip Journal On Wireless Communications and Networking 2020. |
Radio Frequnecy Time-Of-Flight Distance Measurment for Low-Cost Wireless Sensor Localization; IEEE Sensors Journal Apr. 2011. |
High Accuracy Ultrasound Micro-Distance Measurments With Pmuts Under Liquid Operation; Zamora et al. ; Jun. 2021. |
PCT/US2022/027211 ; ISR and Written Opinion dated Jan. 12, 2023. |
Number | Date | Country | |
---|---|---|---|
20220355198 A1 | Nov 2022 | US |
Number | Date | Country | |
---|---|---|---|
63183739 | May 2021 | US |