The present disclosure relates generally to lottery systems, and more particularly to lottery systems, methods and devices for draw-based games.
Lottery games that are determined by pre-printed indicia and random drawings are known. For example, instant lottery tickets typically provide a scratch-off coating whereby a user can scratch off the coating to determine if the underlying indicia result in any winnings. When instant tickets are made available for sale, they are generally provided to a retailer in packs, and an activation code or number can be read by, or entered through, a terminal to activate the pack of tickets for sale and play. Once the pack is activated, the individual tickets in the pack can be sold without requiring any further activation for the tickets to be played and redeemed. When a ticket purchaser seeks to redeem a purchased instant ticket, a validation code, such as a void-if-removed number (“VIRN”), can be scanned at a retailer POS terminal or other terminal to confirm that the ticket is a winner, and the scanned code is communicated to a lottery host, which checks the code against a database of stored ticket information and returns a message to the retailer terminal that the code is valid to allow the retailer to redeem the ticket for its associated winnings.
Online or draw-based games, including raffle games, allow a user to select various indicia such as numbers, or have the numbers randomly selected for the user, and then a random drawing determines if the user's indicia match enough of the randomly drawn indicia for the user to win. With draw-based games, special drawing game devices or terminals separate from standard retailer point-of-sale (POS) terminals are generally employed to process wagers and print tickets and/or receipts with the player's requested or randomly selected indicia. These special devices may be positioned away from traditional checkout lines and POS terminals, such that players who may be shopping for other items must make a second stop at the special device to make a wager for a draw-based game. Regardless, the special terminal communicates the wager and associated details to a host as part of registering the wager. The game's integrity is maintained, at least in part, by ensuring that only purchased tickets with registered wagers are capable of winning when the random drawing occurs.
Pre-printed draw-based lottery tickets are not common, but as with traditional draw-based lottery tickets, the operator of the lottery must know the indicia or set of indicia tied to tickets that were actually purchased in order to register those tickets as eligible to win. If not all of the pre-printed tickets have been sold, then any unsold tickets must not be included in determining winners in order to maintain the integrity of the wagering game. While a pack of pre-printed draw-based lottery tickets can be activated for sale, such activation cannot be treated as an instant ticket pack activation would be, where each individual ticket is thereafter redeemable by scanning a validation code, since unscrupulous individuals may seek out unpurchased, but winning, draw-based tickets after a drawing has occurred. Accordingly, draw-based lottery tickets with pre-printed indicia must be purchased, and the purchase recorded before the drawing, in order for the ticket to be activated for play and later redemption.
While a code can be provided on a pre-printed draw-based ticket for scanning in order to activate and/or register the ticket for play, problems arise if the activation for play code is not scanned or otherwise entered and communicated to the host. For example, if a purchaser buys a pre-printed draw-based ticket and it is somehow not scanned, it may include winning indicia but not be redeemable, since it would be treated by the system as an unsold ticket. Post-purchase ticket scanning can be missed for many reasons, such as through poor retailer clerk training or by mistake, such as in instances where the player is purchasing several consecutive tickets in a pack, and one or more of the tickets is mistakenly missed during scanning to activate the tickets for play. There is thus a technical challenge with pre-printed draw-based lottery tickets to ensure that all purchased tickets are activated for play, even when the ticket code has not been scanned or otherwise communicated to the host. This challenge is heightened by the desire to reduce the equipment footprint of lottery machines in retailer sites such that all required operations can be fulfilled using retailer POS terminals.
The present disclosure relates generally to a system, apparatus and method wherein wagering event integrity is controlled using, for example, one or more of a remote lottery host, retailer terminal(s) and specially adapted tickets and ticket groups.
According to the present disclosure, pre-printed draw-based lottery tickets are provided in a pack and/or sequence. Each ticket in the pack includes a unique trigger code which, when read or entered at a retailer terminal, activates the individual ticket for play. A lottery host in communication with one or more retailer terminals receives a signal from the retailer terminal corresponding to the unique trigger code of a currently available ticket, determines whether any previous tickets in the pack have not been activated for play, and then activates such previous tickets as well as the currently available ticket for play prior to the lottery game drawing.
Further according to the present disclosure, an input device in communication with one or more retailer terminals permits a user to enter a unique ticket number associated with a specific ticket from the ticket pack. Upon receiving a signal from the retailer terminal corresponding to the unique ticket number, the lottery host determines whether any previous tickets in the pack have not been activated for play, and then activates such previous tickets for play prior to the lottery game drawing.
The presently disclosed subject matter now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the presently disclosed subject matter are shown. Like numbers refer to like elements throughout. The presently disclosed subject matter may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein, but is applicable to any system, method and/or apparatus wherein an event provider, operator, retailer and/or player experiences improved event integrity through, in part, employing safeguards to ensure that non-activated products that should be activated and/or tracked are appropriately triggered. Indeed, many modifications and other embodiments of the presently disclosed subject matter set forth herein will come to mind to one skilled in the art to which the presently disclosed subject matter pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the presently disclosed subject matter is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims.
Example embodiments such as those disclosed herein can be used to support regulated state or governmental lotteries, private gaming corporations, or other entities that provide legal gaming to customers. While the examples are described principally with reference to regulated state lotteries, it will be appreciated that the same solutions may be applied in other wagering or regulated gaming applications. The example embodiments described below include references to a lottery host or a host system. A host or host system may be implemented as a single computing system or as a collection of computing systems or subsystems which are communicatively coupled, and each component or subsystem of the exemplary host can be implemented in hardware, software or a combination thereof.
According to various embodiments, the present disclosure describes a wagering event integrity control system, device and method which can enable wagering event providers, operators and associated retailers to offer a securely integrated, ticket-based wagering event to wagering event consumers. In various embodiments, the ticket-based wagering event can relate to a game that includes a first game, such as an instant win game, combined with a subsequent event-based game, such as a drawing-based game.
While the retailer terminal 101 can be embodied in a clerk-operated point-of-sale (POS) terminal, it may also take the form of a player self-service terminal or computing device in appropriate commercial sites, subject to any jurisdictional limitations, for example. It will be appreciated that the terminal(s) 101 can incorporate necessary processing power in the form of one or more central processing units (CPU) 106, an input/output (I/O) interface 104 and memory 108 for storing data and programming that can be employed by the processor to carry out the functions and communications necessary to facilitate the processes and functionalities described herein. Ticket generators (e.g., retail clerks and players) can enter commands and information into respective terminals through a user interface as described above. In addition to display devices, the terminal 101 can also include other peripheral output devices, such as one or more printers, for example, which may be connected through an output peripheral interface.
The retailer terminal 101 can also be in communication with a network 110 (e.g., the internet or a private network). The system 100 can also include a remote central controller or lottery host 120. The host 120 is shown in communication with the network 110, and is thereby in operative communication with retailer terminal 101. It will be appreciated that the host 120 can incorporate necessary processing power in the form of one or more central processing units (CPU) 124, an input/output (I/O) interface 125 and memory 126 for storing data and programming that can be employed by the processor to carry out the functions and communications necessary to facilitate the processes and functionalities described herein. It should be understood that, in various embodiments, there may be one or more retailer terminals 101 and/or one or more remote lottery hosts 120, as appropriate. An exemplary embodiment of a user interface 133 associated with the retailer terminal 101 is illustrated in
In various embodiments, ticket inventory deployed to retailers for ultimate consumption by consumers is managed. In some embodiments, inventory may include, for example, packs containing multiple individual products arranged in a sequence (e.g., packs or rolls of lottery game tickets to be sold individually to consumers) that are delivered from a wagering event provider or operator to one or more retailers. In these various embodiments, when a retailer makes certain inventory available for sale to consumers (e.g., a pack containing one or more tickets for sale to consumers), the retailer can “activate” the pack. Pack “activation” may take many forms, including, for example, communicating to the host (e.g., 120) or remote central controller operated by a wagering event provider and/or operator that the pack is being made available for sale. In various embodiments, a retailer can communicate such availability for sale by, among other things, employing one or more retailer terminals (e.g., 101) and associated hardware and software to scan a pack activation code, or to manually enter an activation code. Such codes can be sent directly to the host 120 over the network 110 via the retailer terminal(s) 101, and many forms of communication can be accommodated, including email, phone, and other messaging systems and protocols.
In various embodiments, an operator of a retailer terminal(s) 101 employs a scanner device 102 in communication with the terminal 101 to read a game pack number or activation code from a ticket pack, whereupon programming operating on the retailer terminal automatically communicates such code or number as an activation signal directly to the lottery host, which then receives the activation signal and subsequently renders the associated pack of tickets as activated for sale and/or eligible for individual ticket activation. In other embodiments, the scanned code or number is first converted by the retailer device into a special indicator that is then communicated as the activation signal to the lottery host, which receives the activation signal and subsequently renders the associated pack of tickets as activated for sale and/or eligible for individual ticket activation. The retailer may be prompted for such action as at 135 using interface 133 in
In other embodiments, an operator of the retailer terminal can manually enter a code or number into a user interface in communication with the retailer terminal, and the code or number, or translated representation thereof, is then communicated as the activation signal to the lottery host in similar fashion to that described above. The retailer may be prompted for such action as at 137 using interface 133 in
Whether the lottery host receives a pack activation signal that is the actual code or number scanned, a representation of the scanned code or number, or one of the unique ticket numbers on a ticket in the pack, the lottery host operates programming stored in memory to activate the tickets in the ticket pack for sale. Activating the tickets for sale makes the tickets eligible to be scanned in order to be activated for play. In other words, even though the ticket pack is activated for sale, each individual ticket is not activated for play until its own activation code or number has been independently scanned, read or otherwise entered via the terminal 101 and acknowledged by the lottery host 120.
In addition to storing game pack numbers and associated activation signals, the lottery host 120 stores details about the individual tickets in the pack. Each ticket can be printed with game indicia, activation indicia, validation indicia, artwork, instructions, opaque material, clear material, scratch-off material and other desired elements. Content, data, design elements and other items to be printed on the substrate can be generated by a computer system operating programmed instructions stored in a memory. In various embodiments, the data for multiple games are printed on a given individual substrate. The substrate is perforated or scored in order to permit individual game tickets to be removed from the pack, roll or sheet of tickets. In various embodiments, a unique trigger code, game play indicia, a unique ticket number and a unique game validation code are printed on each individual ticket in the pack, and these elements are stored by the lottery host and associated with the unique ticket number for each ticket. As it cannot be known when the tickets will be purchased, no draw date is initially assigned to any of the tickets.
In various embodiments, the system disclosed herein controls and acknowledges when deployed ticket inventory has been sold in its entirety. For example, a game provider and/or operator can be alerted that a given amount of inventory (e.g., gaming ticket pack 300) has been fully sold. In some embodiments, gaming ticket pack 300 includes termination ticket 350, which can include a termination code 352, a number or other termination indicator. In some embodiments, following the sale of the last available ticket 321 in a pack 300 associated with a certain inventory, termination ticket 350 can be processed in a manner similar to activation ticket 301. For example, a retailer can scan the termination bar code 352 included on termination ticket 350 using the scanner 102.
When a ticket is presented for redemption, the unique validation code on the ticket is read or entered into the retailer terminal 101, and communicated to the lottery host. The host then retrieves the ticket data associated with the unique validation code to ensure that the ticket has been activated for play and to determine what prize is associated with the game indicia. Should the validation process determine that the validation code is valid and/or authentic, the host 120 communicates with the terminal that the code is approved, and the retail clerk and/or self-service terminal can pay any associated winnings to the player.
In various embodiments, even though a ticket pack may be activated, the individual tickets in the pack may not be activated. Thus, the holder of a ticket, purchased or not, that has not been activated cannot redeem the ticket for any prize that may have been won, even if the ticket is part of a pack that has been activated for sale. As disclosed, the integrity of wagering game events is controlled, in part, by requiring individual ticket activation in addition to ticket pack activation.
In various embodiments, for example, sale of an individual game ticket (e.g. game ticket 400 in
In various embodiments, a retailer “triggers” an individual game ticket 400 to be activated for play at the time of sale to a consumer. In some embodiments, the retailer can trigger the game ticket 400 by scanning a trigger validation bar code 410. The retailer can scan the trigger validation bar code using, for example, scanner 102. Alternatively, the retailer can manually enter a ticket product code 412 contained on the ticket (e.g., under the trigger validation bar code 410) into the manual interface 103 of retailer terminal 101. The trigger validation bar code 410 is a bar code representation of the alphanumeric characters in the ticket product code 412, such that both codes 410, 412 represent the same information. A trigger code that is unique to each ticket, such as the trigger validation bar code 410, the ticket product code 412, or a representation of the bar code 410 or product code 412 as generated by the retailer terminal, can be communicated from the retailer terminal to the lottery host, either automatically or through manual interaction as described above. The ticket 400 can also include a ticket number 420 that is unique to each ticket, which typically is a number referencing the order in which the ticket appears in the sequence of tickets provided in the ticket pack. In various embodiments, the ticket product code 412 can include a visual representation of the ticket number (as at 422) as part of the ticket product code 412, and the trigger validation bar code 410 can include a bar coded representation of the ticket number. It will be appreciated that the ticket number representation 422 on the ticket product code may be the only instance of the ticket number visually appearing on the ticket, or the ticket number may be separately shown in additional instances such as at 420.
In various embodiments, upon the retailer terminal triggering a ticket and the host receiving the corresponding ticket activation signal from the retailer terminal, the ticket becomes “active” and/or registered for the next game event (e.g., a daily evening drawing associated with a particular game). The consumer can also be advised by the system 100 at the time of sale that the ticket is “active” for the game event to be held at a certain date/time. Such activation and assigned drawing/draw date is also stored in the lottery host's database of ticket information and associated with the triggered ticket. In some embodiments, a receipt is issued from device 101 to the consumer, indicating the associated game event details. An exemplary embodiment of such a receipt 500 is shown, for example, in
In some embodiments, there may be instances where a gaming ticket is sold by a retailer to a consumer but the ticket is not, for whatever reason, properly activated. In such scenarios, it may be possible for a consumer to purchase a ticket that is not initially activated properly, risking the result that the ticket sold is outside of the pool of tickets considered for an upcoming wagering event (e.g., a drawing).
Embodiments of the presently disclosed system, method and apparatus include one or more mechanisms to mitigate against the risk of tickets being sold without being properly activated ahead of the associated wagering event (e.g., a drawing). In some embodiments, the system is configured to “auto-trigger” previously sold but “untriggered” tickets upon triggering of a subsequent ticket in the sequence of tickets, or upon other operations as described herein.
As at step 609, based on the received second signal, the lottery host determines whether prior lottery tickets in the sequence have been activated for play. For example, if the second signal pertains to ticket #33, and the last recorded sale of a ticket in the pack is for ticket #22, the lottery host may determine that a first subset of the tickets (e.g., tickets #1-22) has been sold and activated prior to the lottery host receiving the second signal, but that a second subset of the prior lottery tickets (e.g., tickets #23-32) has not been activated for play. For the subset of prior tickets determined to be unactivated, the system presumes such tickets have been sold, and as at step 611, the lottery host activates those tickets for sale, without requiring any direct scan or reading of the actual prior sold lottery tickets. In this way, the holders of purchased tickets #23-32 are now eligible to win prizes in the drawing, whereas if their tickets had remained unactivated, they would not be eligible to win prizes in the drawing. If the prior tickets have been activated for play, or once any unactived purchased tickets have been activated for play, then as at step 615, the lottery host determines if the lottery drawing ticket sale cutoff time has been reached, and if so, then as at step 613, the lottery host can conduct the drawing with the understanding that all purchased tickets have been activated and are eligible to win. If the cutoff time has not been reached, then the lottery host is still available to receive a different second signal associated with whatever lottery ticket is currently available at that time, as at step 605.
As disclosed herein, however, the system, method and apparatus can be configured to “auto-trigger” Ticket #5 (654) and Ticket #6 (656) upon the sale and triggering of Ticket #7 (658). More particularly, in various embodiments, the system, method and apparatus can be configured to recognize that Ticket #7 (658) was “triggered” even though Ticket #5 (654) and Ticket #6 (656) were not triggered. The presently disclosed system, apparatus and method can, therefore, automatically trigger the tickets 654, 656 not properly triggered by the retailer, thus activating these tickets 654, 656 for the upcoming game event (e.g., drawing). In this way, embodiments of the present disclosure overcome a technical challenge presented by not having the unscanned tickets 654, 656 available to be scanned for activation. The game's integrity can be maintained, at least in part, by the host checking prior unactivated tickets upon receipt of the signal for the currently available ticket.
In various embodiments, the presently disclosed system, method and apparatus include certain other mechanisms to ensure proper activation and triggering of tickets sold, where appropriate. For example, while the auto-trigger mechanism discussed hereinabove can trigger and activate untriggered tickets upon the sale of a subsequently triggered ticket, there may be instances where untriggered tickets still remain inactive. One exemplary scenario can occur when the final ticket sold by a retailer prior to a corresponding wagering event (e.g., drawing) is not properly triggered. In such a scenario, there would be no subsequent sale prior to the drawing event that could “auto-trigger” that ticket in accordance with certain embodiments as disclosed above.
An example according to various embodiments of the presently disclosed system is provided. Assume, for example, that a retailer has properly activated the ticket pack 300 and properly triggered each ticket upon each ticket's respective sale in accordance with the present disclosure. In that exemplary scenario, the end-of-period push notification message 910 might prompt the retailer to simply confirm the next ticket number 920 in the pack 300 (for example, ticket number 52 in pack number 195235 and ticket 37 in pack number 087624 as illustrated at 920 in
If, however, a ticket sold to a consumer was not properly activated (whether by failure to scan the trigger validation bar code 410 or other anomaly), the retailer can be presented with a message 910 containing an assumed ticket number that does not correspond to the actual next ticket number 420 in the retailer's inventory. In such a scenario, the retailer can “override” the message and manually input the correct value for the next ticket number. For example, retailer may have sold ticket number 52 but failed to properly trigger or activate the ticket, therefore depriving the host 120 of information regarding the sale. In some embodiments, by overriding the message and inputting the correct ticket number available to retailer (e.g., 53), the override input is communicated as an override signal from the retailer terminal to the host, the assumed ticket number is also changed to the actual ticket number in the host database, and the ticket 52 is then automatically activated or triggered by the host and available for the upcoming wagering event (e.g. drawing) associated with the game event period. In some embodiments, a retailer can override the message by clicking an “override” button 980 on, for example, the manual input interface 103 or retailer interface 101, and following prompts to enter the correct value. In this way, embodiments of the present disclosure overcome the technical challenge presented by not having the previously sold but unscanned tickets available to be scanned for activation. The game's integrity can be maintained, at least in part, by the host checking prior unactivated tickets upon receipt of the unique ticket number for the next ticket available to be sold.
In various other embodiments, the push notification is received at the retailer interface after the retailer has closed for the associated period. In such scenarios, the system, apparatus and method of the present disclosure can be configured to allow a retailer to confirm or override the message 910 after the close of the game event period. The host can then activate any untriggered tickets at that time, making them available for the previously executed game event (e.g. drawing) and any associated winnings available to the consumer. Optionally, the host first issues a prompt to the retailer terminal, seeking confirmation that any untriggered tickets should be activated before proceeding to activate such tickets. According to various embodiments, if a retailer closes their store before the end of the day push notification, they will be prompted to enter the next ticket number prior to their first sale the following day.
It will be appreciated that alternatives to the above-described operations for controlling the integrity of wagering events. For example, one or more retailer terminals can be employed to activate a ticket pack and individual tickets, and further to manage push notifications, rather than the lottery host or remote central controller. In such embodiments, the terminal(s) can be provided with programming for recording associated code, number and/or indicator data, and rendering ticket groups or individual tickets as activated based thereupon, for example.
It will be appreciated that all of the disclosed methods and procedures herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer-readable medium, including RAM, SATA DOM, or other storage media. The instructions may be configured to be executed by one or more processors which, when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures.
Unless otherwise stated, devices or components of the present disclosure that are in communication with each other do not need to be in continuous communication with each other. Further, devices or components in communication with other devices or components can communicate directly or indirectly through one or more intermediate devices, components or other intermediaries. Further, descriptions of embodiments of the present disclosure herein wherein several devices and/or components are described as being in communication with one another does not imply that all such components are required, or that each of the disclosed components must communicate with every other component. In addition, while algorithms, process steps and/or method steps may be described in a sequential order, such approaches can be configured to work in different orders. In other words, any ordering of steps described herein does not, standing alone, dictate that the steps be performed in that order. The steps associated with methods and/or processes as described herein can be performed in any order practical. Additionally, some steps can be performed simultaneously or substantially simultaneously despite being described or implied as occurring non-simultaneously.
It will be appreciated that algorithms, method steps and process steps described herein can be implemented by appropriately programmed computers and computing devices, for example. In this regard, a processor (e.g., a microprocessor or controller device) receives instructions from a memory or like storage device that contains and/or stores the instructions, and the processor executes those instructions, thereby performing a process defined by those instructions. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.
Any combination of one or more computer readable media may be utilized. The computer readable media may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an appropriate optical fiber with a repeater, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python or the like, conventional procedural programming languages, such as the “C” programming language, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may execute entirely on a user's computer, partly on a user's computer, as a stand-alone software package, partly on a user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) or in a cloud computing environment or offered as a service such as a Software as a Service (SaaS).
Where databases are described in the present disclosure, it will be appreciated that alternative database structures to those described, as well as other memory structures besides databases may be readily employed. The drawing figure representations and accompanying descriptions of any exemplary databases presented herein are illustrative and not restrictive arrangements for stored representations of data. Further, any exemplary entries of tables and parameter data represent example information only, and, despite any depiction of the databases as tables, other formats (including relational databases, object-based models and/or distributed databases) can be used to store, process and otherwise manipulate the data types described herein. Electronic storage can be local or remote storage, as will be understood to those skilled in the art. Appropriate encryption and other security methodologies can also be employed by the system of the present disclosure, as will be understood to one of ordinary skill in the art.
The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the claims of the application rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
This application claims the benefit of and priority to U.S. Provisional Patent Application No. 62/350,488, filed on Jun. 15, 2016, the contents of which are incorporated herein.
Number | Name | Date | Kind |
---|---|---|---|
7627497 | Szrek et al. | Dec 2009 | B2 |
20030003984 | Petruzzi | Jan 2003 | A1 |
20030120381 | Perin, Jr. | Jun 2003 | A1 |
20040023711 | Knapp | Feb 2004 | A1 |
20040193464 | Szrek | Sep 2004 | A1 |
20040209665 | Walker | Oct 2004 | A1 |
20050194741 | Kowell | Sep 2005 | A1 |
20090101714 | Weyler, III | Apr 2009 | A1 |
20090186680 | Napolitano | Jul 2009 | A1 |
20110165933 | Guziel | Jul 2011 | A1 |
20160093137 | Gaddy | Mar 2016 | A1 |
20160210808 | Giunti | Jul 2016 | A1 |
Number | Date | Country |
---|---|---|
WO200103785 | Jan 2001 | WO |
Number | Date | Country | |
---|---|---|---|
62350488 | Jun 2016 | US |