Patent ID: 12214288

Like reference numerals refer to corresponding parts throughout the several views of the drawings.

DETAILED DESCRIPTION

In the era of mobile devices and connectivity, playing lottery games virtually can be accomplished using a robotic apparatus that is present within the governing jurisdiction, and a live remote mobile interface associated with the player. Examples of such a robotic apparatus, mobile interface, and methods of use thereof, are described herein.

FIG.1is a system diagram of a network-connected lottery system100in accordance with some implementations, andFIG.2is a schematic diagram of the network-connected lottery system100ofFIG.1including more detailed data flows in accordance with some implementations.

As depicted inFIGS.1and2, the lottery system100includes a ticket processing system102, which is physically located in the jurisdiction that governs the lottery that is administered by the lottery system100.

The ticket processing system102includes a ticket dispensing machine190, a redemption terminal120, a controller110, a scanning device (scanner)118, one or more video cameras112, and a plurality of robotic components including a robotic signature mechanism (signer)114, a robotic scratching mechanism (scratcher)116, a cutting device (cutter)132, and/or a sorting device (sorter)134.

The ticket processing system102may be located in a public location (e.g., a retail or other public location), or in a private location, such as a secure room that is designed to house the various components of the processing system102.

The ticket processing system102, or components included in the ticket processing system102, may be referred to as a robotic machine or apparatus. In some implementations, the components forming the robotic machine or apparatus include the controller110, the signer114, the scratcher116, the cutter132, the sorter134, and hardware for receiving, moving, orienting, or otherwise handling tickets dispensed from the dispensing machine190in order to ensure proper imaging, scanning, signing, scratching, and processing of each ticket dispensed from the dispensing machine190.

The ticket dispensing machine190includes a plurality of lottery tickets192(e.g., loaded with rolls192of tickets or loaded individually depending on the form factor of the tickets). There may be one or more ticket dispensing machines190in a single processing system102.

The dispensing machine190is configured to receive a dispense command from the controller110and output a ticket specified by the dispense command (if there are multiple types of tickets within the dispensing machine190), or output a ticket in accordance with receiving the dispense command regardless of whether the dispense command specifies a particular type of ticket (e.g., if there is only one type of ticket within the dispensing machine190). The dispense command may include a quantity of tickets to dispense. In such a scenario, the dispensing machine190is configured to dispense the number of tickets specified by the dispense command, one at a time, so that the other components of the processing system102may process each ticket in the manner described below.

In some implementations, other components of the processing system102(e.g., the signer114, scratcher116, camera(s)112, and/or scanner118) may be disposed within the dispensing machine190. Alternatively, the dispensing machine190may be a machine that is modified to accept dispense commands from the controller110in place of, or in addition to, dispense commands triggered by physical gameplay on the dispensing machine190itself (e.g., entering money, pressing selection buttons, and so forth). In such scenarios, the other components of the processing system102may be located outside of and in proximity to the dispensing machine190in order to process tickets outputted by the dispensing machine190.

The tickets included in the dispensing machine190(e.g., arranged in a ticket roll192or any other arrangement) may also be referred to as scratch cards, scratch offs, scratch tickets, scratchers, scratch-its, scratch games, scratch-and-wins, instant games, or instant lotteries. The tickets may be constructed of thin paper-based card material or plastic. One or more areas may contain concealed information which can be revealed by scratching off an opaque substance (e.g., a silkscreen latex panel that bonds with the ticket body), or removing an adhesive. The opaque substance may also be referred to as a coating, panel, label, scratch coating, scratch panel, scratch label, scratch substance, or scratching area.

In some implementations, the entire scratchable area (or at least a threshold of the scratchable area) needs to be scratched to see whether a prize has been won. The ticket may be printed either to be a winner or not, or to reveal a secret code. In some implementations, the result does not depend upon the portions that are scratched off. In other implementations, some but not all areas have to be scratched; this may apply in a quiz, where the area corresponding to the right answer is scratched, or in some applications where, depending on which areas are scratched, the card wins or loses. In these cases the card becomes invalid if too many areas are scratched. After losing, one can scratch all areas to see if, how, and what one could have won with this ticket.

The video camera(s)112may be located at multiple locations within the ticket processing system102, providing multiple live angles. For example, a first camera112may include the ticket dispensing machine(s)190in its field of view, a second camera112may include the top of a dispensed ticket196in its field of view, and a third camera112may include the bottom of a dispensed ticket196in its field of view. As such, users of the lottery system100may remotely view (i) the dispensing machine(s)190in order to determine which machine and/or ticket to select, (ii) the top of a dispensed ticket196in order to view a scratching area, and/or (iii) the bottom of a dispensed ticket196in order to view a signing area.

In some implementations, users can remotely control the pan, tilt, and zoom of the camera(s)112. Optionally, two or more users can be watching the same video feed provided by the camera(s)112during a single ticket playing session (e.g., viewing virtual scratching as described below). In some implementations, there may be guest watchers that have no knowledge of the user or interest in the ticket being dispensed and scratched.

The scanner118is located proximate to an area in which dispensed tickets196are provided, and configured to scan identifying information on dispensed tickets196. For example, identifying information for a ticket may include a unique code such as a lot number or serial number that identifies the ticket. Such a code may or may not be hidden behind the opaque substance. The scanner118is configured to transmit the identifying information (either the scan of the identifying information, or the identifying information itself) to the controller110.

In some implementations, the scanner118is further configured to scan information (e.g., numbers, letters, symbols, markings, and so forth) that is hidden behind the opaque substance and revealed upon the ticket being scratched. The scanner118is configured to transmit such information (either the scan of the information, or the information itself) to the redemption terminal120.

The ticket redemption terminal120either includes the scanner118or is coupled to the scanner118, and is configured to receive data obtained by the scanner118. Depending on the nature of the scanned data, the ticket redemption terminal120may transmit the scanned data (or information, such as a number, derived from the scanned data) to the controller110or the ticket validation server122.

In a first example, the ticket redemption terminal120may send a scanned identification number (e.g., a serial number) of a dispensed ticket196to the controller110, so that the controller110may link the ticket associated with the scanned identification number to a user account associated with a user currently playing that ticket (e.g., via user device104and application105, application server108, and controller110).

In a second example, the ticket redemption terminal120may send scanned data associated with the game play of the ticket (e.g., a code revealed from under the opaque substance) to the ticket validation server122for validation by the ticket agency124(e.g., in order to validate that the ticket is a winner or not a winner). In some implementations, the data associated with the game play may be the identification number (e.g., the serial number). In other words, a single number may not only identify the ticket (and be linked to a user account by the application server108), but also serve as the basis for validating whether the ticket is a winning ticket or not a winning ticket. In such scenarios, the ticket may not even need to be played (e.g., may not need to be scratched), and scanning a single number on a dispensed ticket196may be adequate in order to (i) link the ticket to a user account, and (ii) validate the status of the ticket (e.g., winner or loser).

The ticket redemption terminal120is configured to receive the ticket validation information (e.g., win/loss information) from the ticket validation server122and transmit the ticket validation information to the application server108for further processing.

The controller110comprises at least one processor (also referred to as a processing unit, processor, computer, programmable apparatus, or any electronic technology capable of executing instructions or operations). The controller110comprises or is communicatively coupled to memory storing one or more programs to be executed by the processing unit(s) of the controller. The memory includes computer readable media including, but not limited to, attached storage media (e.g., hard disk drives, network disk drives, servers), internal storage media (e.g., RAM, ROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge), removable storage media (e.g., CDs, DVDs, flash drives, memory cards, floppy disks, flexible disks), firmware, and/or other known or yet to be discovered storage media. Depending on its purpose, the memory may be transitory and/or non-transitory.

The controller110is configured to receive dispense commands from the application server108and transmit received dispense commands to the dispensing machine190. The controller110is also configured to receive video data from one or more cameras112and transmit the video data to the application server108. The controller110is also configured to receive signing data and scratch data (described in more detail below) from the application server108and transmit the signing data and scratch data to the signer114and the scratch116, respectively. The controller110is also configured to receive scan data (e.g., serial numbers and/or gameplay data as described above) from the scanner118, and transmit the scan data to the application server108for linking to a user account106.

In some implementations, the controller110may be configured to receive win/loss information from the redemption terminal120and transmit the win/loss information to the application server108. Alternatively, the redemption terminal120(or the ticket validation server122) may transmit the win/loss information to the application server108without going through the controller110.

The signer114is a mechanical device that is configured to manipulate a writing tool (e.g., a pen, marker, or other signing tool) to sign the signing area of a ticket in accordance with signing data received from a user device104via the application server108and the controller110. The signer114may also be referred to as a signing or signature device, signing or signature mechanism, signing or signature machine, automatic signer, or automatic pen. For example, the signer114may be a robotic arm.

The signer114may be controlled remotely by the user interface of an application105of a user device104. The user may virtually (remotely) control the signer114to sign the dispensed ticket196by locally signing a user interface element resembling the signing area of the ticket on the application105of the user device104. For example, the user may use a touchscreen, computer mouse, stylus, digital pen, keyboard, or other input method of the user device104, thereby causing the application105to capture X-Y signature data (with the X and Y axes representing horizontal and vertical directions on a face of the ticket). In some implementations, the X-Y signature data corresponds to two-dimensional user-provided gestures corresponding to signature input at the user device. In some implementations, the user may view the signature being rendered on the ticket in real time, with signature feedback being replicated (displayed) on the user interface of the application105.

The scratcher116is a mechanical device that is configured to manipulate a scratching tool (e.g., a needle, scratching tool, or other hard object) to scratch the opaque substance off of the scratching area of the ticket in accordance with scratching data received from a user device104via the application server108and the controller110. The scratcher116may also be referred to as a scratching device, scratching mechanism, scratching machine, or automatic scratcher. For example, the scratcher116may be a robotic arm that physically scratches the ticket.

In some implementations, the scratcher116and the signer114may share some components. For example, a single robotic arm may be used to (i) sign the signing area of the ticket when configured in a signing mode (e.g., with a signing tool inserted at a moving end of the arm) and (ii) scratch the scratching area of the ticket when configured in a scratching mode (e.g., with a scratching tool inserted at the moving end of the arm). While the robotic arm is configured in one mode, the tool associated with the other mode may be retracted from the moving end of the arm.

In some implementations, the scratcher116and the signer114may be independently constructed and operated, such as for cases in which the scratching area is on one side of the ticket and the signing area is on the other side of the ticket. Alternatively, for such a ticket configuration, a ticket flipping mechanism may reorient the ticket so that a single robotic arm may both sign and scratch the ticket as described above.

The scratcher116may be controlled remotely by the user interface of an application105of a user device104. The user may virtually (remotely) control the scratch116to scratch (or remove an opaque substance from) a scratching area of the dispensed ticket196by locally interacting with a user interface element resembling the scratching area of the ticket on the application105of the user device104. For example, the user may use a touchscreen (e.g., by using swiping gestures), computer mouse, stylus, digital pen, keyboard, or other input method of the user device104, thereby causing the application105to capture scratching data. In some implementations, the scratching data captured at the application105is X-Y scratching data (with the X and Y axes representing horizontal and vertical directions on a face of the ticket), corresponding to two-dimensional user-provided gestures corresponding to scratching input at the user device. Alternatively, the scratching data captured at the application105may include or comprise a command instructing the scratcher116to scratch (or remove an opaque substance from) a scratching area of the dispensed ticket, using a scratching pattern that is independent of any user-provided gestures. For example, the user may select a “scratch ticket” affordance on the user interface of the application105, causing a scratch command to be sent to the scratcher116. The scratcher116may receive the scratch command and use a preconfigured scratching pattern or a random scratching pattern to scratch (or remove an opaque substance from) the scratching area of the dispensed ticket.

In some implementations, the user may view the scratching on the dispensed ticket196in real time, with scratching feedback being replicated (displayed) on the user interface of the application105. The scratching feedback may be a digital simulation of a ticket being scratched on the user interface, and/or live video feed of the dispensed ticket196being scratched by the scratcher116.

In some implementations, rather than manually interacting with a scratching element of the user interface of the application105, the scratching of the dispensed ticket196may be fully automated, requiring no interaction by the user, other than to begin and/or stop scratching (e.g., controlled by one or more affordances on the user interface).

The ticket cutter132(also referred to as a cutting device or cutting mechanism) is a mechanical device including a cutting element configured to separate dispensed tickets196from tickets in the stream194that have not yet been dispensed or otherwise processed. The ticket cutter132receives a cut command from the controller110after the ticket196has been processed (e.g., after the ticket has been signed, scratched, and scanned).

The ticket sorter134(also referred to as a sorting device or sorting mechanism) is a mechanical device including a sorting element configured to eject or separate the winning tickets from the losing tickets. The ticket sorter134receives a sort command from the controller110after the ticket196has been processed (e.g., after the ticket has been signed, scratched, and scanned). The ticket sorter134may place the winning tickets into a winning ticket pile or receptacle138and the losing tickets into a losing ticket pile or receptacle136, making them available for system auditing and, in some cases, physical proof of winning tickets that may be sent (e.g., mailed or otherwise delivered) to the ticket agency124and/or the user who purchased and/or played the ticket. In some implementations, in the event of a system error, an incomplete scan, or an incomplete scratch, the ticket sorter134may place tickets corresponding to such errors into an error ticket pile or receptacle (not shown), making them available for system troubleshooting.

The application server108comprises at least one processor (also referred to as a processing unit, processor, computer, programmable apparatus, or any electronic technology capable of executing instructions or operations). The application server108comprises or is communicatively coupled to memory storing one or more programs to be executed by the processing unit(s) of the controller. The memory includes computer readable media including, but not limited to, attached storage media (e.g., hard disk drives, network disk drives, servers), internal storage media (e.g., RAM, ROM, EPROM, FLASH-EPROM, or any other memory chip or cartridge), removable storage media (e.g., CDs, DVDs, flash drives, memory cards, floppy disks, flexible disks), firmware, and/or other known or yet to be discovered storage media. Depending on its purpose, the memory may be transitory and/or non-transitory.

The application server108is configured to receive commands (e.g., system102selection commands, machine190selection commands, and/or ticket dispense commands) and data (e.g., signing and scratching data) from a plurality of user devices104(with one representative device being depicted inFIGS.1and2) and transmit the commands and data to a plurality of ticket processing systems102(with one representative system102being depicted inFIG.2). The application server108is also configured to receive commands and data (e.g., scan data and/or video data) from the plurality of user devices104and transmit the commands and data to the plurality of user devices104.

In some implementations, the application server108is also configured to receives win/loss (ticket status) information from the redemption terminal120or from the controller110, and transmit notifications to the user device104communicating the win/loss information.

In some implementations, the application server108is also configured to assign or link dispensed tickets196(based on or associated with received scan data, such as ticket serial numbers) to user accounts106corresponding to users who caused the tickets to be dispensed.

The user device104is an electronic communication device, such as a mobile device, tablet, computer, or web browser. Using one or more processors, the user device104executes a remote lottery application105, which runs a user interface configured to provide outputs to the user (e.g., video feed(s) from the application server108, menus providing options for selection dispensing machines and tickets, user interface affordances for accepting dispense commands, winning ticket notifications, and so forth). The user interface also accepts user inputs configured to operate the signer114and scratcher116as described above.

Using the application105, a user can be physically present in a remote location while playing a lottery ticket offered by the ticket processing system102. In some implementations, the user may not be located remotely, but may be physically present (such as in a bingo hall) at the location of the ticket processing system102, optionally using the application105for convenience or due to physical limitations.

The application105displays video feed data (from the camera(s)112) and receives selections for desired tickets and/or dispensing machines (if the same ticket is available in multiple dispensing machines). The application105receives inputs via an input module of the user device104. The input module may comprise a touchscreen, computer mouse, stylus, digital pen, keyboard, or other input device capturing X-Y movements (e.g., for signing and/or scratching).

The application105receives win/loss information (including winning amounts) from the application server108. The application105may cause the user device104to alert the user regarding the win/loss information using a visual, audible, and/or tactile alert.

The ticket agency124is associated with the tickets and/or ticket dispensing machines190offering the tickets. The ticket agency, through its ticket validation server122, validates tickets and their win/loss statuses. Upon a ticket being confirmed to be a valid, winning ticket (by the ticket validation server122) the ticket agency124deposits winning funds into the user account106linked to the ticket by the scanned identification number (e.g., serial number, as described above). The ticket agency124may deposit funds to the user via a provider bank account126and payment processing module or service128. The user account106may be linked to a bank or card account130. In some implementations, funds may be transferred to a virtual currency account (such as bitcoin) associated with the user account.

In some implementations, system100may include additional components, or only a subset of the components described above. For example, some implementations of system100may not include the ticket agency124, ticket validation server122, provider bank account126, payment processing module128, and/or user bank/card account130. Instead, system100may be configured to communicate with one or more of these components.

In some implementations, one or more of the components of system100may be combined (i.e., operations for two or more components may be executed by a single server, device, controller, etc.). For example, the ticket validation server122and redemption terminal120may combined, the redemption terminal120and the controller110may be combined, and so forth.

In some implementations, one or more of the components of ticket processing system102may be implemented as a robotic machine. For example, a machine may be controlled by controller110and include the signer114, scratcher116, scanner118, camera(s)112, redemption terminal120, cutter132, sorter134, and/or dispensing machine190.

The ticket processing system102(specifically, the controller110and the redemption terminal120) communicate with the other components of system100over one or more communication network connections (denoted by arrows in the figures). The communication network connections may be wired or wireless communications connections that are ongoing (e.g., dedicated connections, dedicated online connection, and/or hardwired connections) or accessible on demand (e.g., supporting the ability for the machine to make a temporary connection to a server or the ability for the user device to contact a server). Examples of such network connection technology may include hardwired, telephone network technology, cellular technology (e.g., GSM, CDMA, or the like), Wi-Fi technology, wide area network (WAN), local area network (LAN), or any wired or wireless communication technology over the Internet that is known or yet to be discovered. Stated another way, each communication network connection may be implemented over a communication network using a wired or wireless communication protocol (e.g., any of WiFi, Bluetooth, ZigBee, Z-Wave, 6LoWPAN, Thread, 4G, 5G, and the like).

Communications within the ticket processing system102(denoted by arrows in the figures) may take place using the communication technologies described above. Additionally or alternatively, such communications may take place using short-range communication technology, such as Bluetooth (such as Bluetooth 4.0, Bluetooth Smart, Bluetooth Low Energy (BLE)), near-field communication (NFC), Ultra Wideband (UWB), radio frequency identification (RFID), infrared wireless, induction wireless, or any wired or wireless technology that could be used to communicate a small distance (approximately a hundred feet or closer) that is known or yet to be discovered.

FIG.3is a flow diagram of a method of operating a ticket processing system of the lottery system100ofFIGS.1and2in accordance with some implementations. Method300is, optionally, governed by instructions that are stored in computer memories or non-transitory computer readable storage mediums of processing system102, application server108, redemption terminal120, and/or validation server122. Such instructions may be executed by one or more processors of the aforementioned devices. The computer readable storage mediums may include magnetic or optical disk storage devices, solid state storage devices such as Flash memory, or other non-volatile memory devices. The instructions stored on each computer readable storage medium may include one or more of: source code, assembly language code, object code, or other instruction formats that are interpreted by one or more processors. Some operations in method300may be combined and/or the order of some operations may be changed.

Method300may begin with operation302or304. At operation302, the controller110obtains, from one or more video cameras112in proximity to a ticket dispensing machine190, a first video stream (showing a live feed of the dispensing machine), and transmits the first video stream to an application server108for delivery to a user device104.

Using the user interface of an application105running on the user device104, a user selects a desired ticket and/or dispensing machine190, optionally based on the first video stream (e.g., the user views the available tickets and/or dispensing machines in the video feed and makes a selection in the user interface).

Upon receiving the user selection, the user device transmits a dispense command to the controller110via the application server108, where it is received at operation304. Upon receiving the dispense command, the controller110causes the selected dispensing machine to dispense the selected ticket. The dispensed ticket is a physical lottery ticket that has a scratching area, a signature area, and/or an identification code (e.g., a lot number or serial number) that is either viewable upon being dispensed, or must be revealed by a scratcher.

As the ticket advances, a first camera112(e.g., a bottom camera) images the ticket and a scanner118scans the identification code (operation306) of the ticket. The controller110transmits the scanned identification number (referred to as first ticket data) to the application server108. In operation308, the application server108links (i.e., assigns, associates) the identification code of the ticket to a user account106associated with the user device104.

Before, during, or after operation306, the controller110receives user-provided signing data (operation310) and/or user-provided scratching data (operation314) from the application server108(obtained by the user device104). The signing data causes a robotic signature device to sign the signature area of the ticket (operation312), and/or the scratching data causes a robotic scratching device to scratch the scratching area of the ticket (operation316).

In other words, the user can opt to sign the ticket (operation310) using the user interface of the application105. The user inputs a signature using a touchscreen, computer mouse, stylus, digital pen, keyboard, or other input method capturing the X-Y Signature. The signature file is sent from the mobile application to the application server to the controller to a robotic arm that physically signs the ticket (operation312). The user can view the signature being rendered on the ticket in real time. In some implementations, the signature feedback is replicated on the user interface.

Before, during, or after the signing operation, the user may virtually scratch the ticket (operation314) using the touchscreen, mouse, stylus, digital pen, or other user input. In some implementations, the scratching of the ticket may be fully automated, requiring no interaction by the user (other than to begin and/or stop). In some implementations, the scratching device can use random x-y coordinates. As the user performs scratching gestures on the user interface and/or watches the live video feed, the robotic arm physically scratches the ticket. In some implementations, there is a simulated ticket on the user device104(with or without the video feed) and real-time feedback is provided to digitally simulate the ticket scratching on the user device104.

Upon completion of the scratching operation, the scanner118scans (operation318) information that is revealed in the scratching area (referred to as second ticket data). The information may include a unique code, gameplay numbers, or any other data initially hidden underneath the opaque substance before the scratching operation. In some implementations, the information does not need to be revealed. In some implementations, the information is in a fixed spot and/or a scratching operation is not required. The scanner118transmits the second ticket data (the revealed information) to the ticket redemption terminal120for processing by the ticket validation server122(or is sent directly to the ticket validation server122).

Upon receiving the second ticket data, the ticket agency (by way of the validation server122) determines ticket status data corresponding to a win status or a loss status of the ticket based on the second ticket data in operation320. If the ticket is a winning ticket (the ticket status data corresponding to a win status), the validation server122transmits a notification to the application server108(for delivery to the user device)) including an amount associated with the win status of the ticket in operation322.

The application server108updates the user account based on the win/loss status, and notifies the user device accordingly (operation324). Funds corresponding to the amount associated with the win status may be automatically transferred to a bank account linked to the user account associated with the user device (e.g., by the ticket agency using a payment processing service128).

In some implementations, after the ticket is processed (upon completion of operations312,316, and318), the controller110may cause a cutting device132to cut or otherwise separate the processed ticket from a stream of tickets. The controller110may further cause a sorting device134to ejects or separate the winning tickets from the losing tickets, thereby storing the processed ticket in accordance with win or loss status. In some embodiments, there may be a pile of error tickets in cases where there was a system error, an incomplete scan, or incomplete scratch.

In some implementations, each ticket processing transaction (e.g., operations302-318at the processing system102) may be video logged and stored (e.g., at the controller110and/or the application server108) for later recall and authentication verification, thereby satisfying auditing and/or governing requirements.

It will be appreciated by those skilled in the art that changes could be made to the exemplary embodiments shown and described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the exemplary embodiments shown and described, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the claims.

For example, specific features of the exemplary embodiments may or may not be part of the claimed invention, different components as opposed to those specifically mentioned may perform at least some of the features described herein, and features of the disclosed embodiments may be combined.

As used herein, the terms “about” and “approximately” may refer to + or −10% of the value referenced. For example, “about 9” is understood to encompass 8.2 and 9.9.

It is to be understood that at least some of the figures and descriptions of the invention have been simplified to focus on elements that are relevant for a clear understanding of the invention, while eliminating, for purposes of clarity, other elements that those of ordinary skill in the art will appreciate may also comprise a portion of the invention. However, because such elements are well known in the art, and because they do not necessarily facilitate a better understanding of the invention, a description of such elements is not provided herein.

It will be understood that, although the terms “first,” “second,” etc. are sometimes used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without changing the meaning of the description, so long as all occurrences of the “first element” are renamed consistently and all occurrences of the second element are renamed consistently. The first element and the second element are both elements, but they are not the same element.

As used herein, the term “if” may be, optionally, construed to mean “upon” or “in response to determining” or “in response to detecting” or “in accordance with a determination that,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” is, optionally, construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event]” or “in accordance with a determination that [a stated condition or event] is detected,” depending on the context.

The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the claims.

As used in the description of the implementations and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context.

Similarly, the phrase “if it is determined (that a stated condition precedent is true)” or “if (a stated condition precedent is true)” or “when (a stated condition precedent is true)” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.

Further, to the extent that the method does not rely on the particular order of steps set forth herein, the particular order of the steps should not be construed as limitation on the claims. The claims directed to the method of the present invention should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the steps may be varied and still remain within the spirit and scope of the present invention.