Method and system for distributing electronic tickets with visual display for verification

[0024] The system operates on one or more computers, typically one or more file servers connected to the Internet and also on a customer's computing device. A customer's device can be a personal computer, mobile phone, mobile handheld device like a Blackberry™ or iPhone™ or any other kind of computing device a user can use to send and receive data messages. The customer's device is used to display the validating visual object. The term validating visual object is interchangeable with validation display object and a secured validation display object is one that is secured so as to avoid piracy.

[0025] Conventional electronic tickets display a barcode or QR code on a user's telephone, typically a cellphone or other portable wireless device with a display screen. The problem with 3 this approach is that a barcode scanner has to be used by the ticket taker. Barcode scanners are not highly compatible with LCD screen displays of barcodes. The amount of time that it takes to process an electronic ticket is greater than that of a paper ticket. Sometimes the LCD display does not scan at all and a passenger has to be sent away to get a paper printout of a ticket. Given the potential large crowds that often attend open venues, this is impractical.

[0026] In this invention, the ticket is procured electronically and stored on the user's device. However, when the ticket is to be taken the verification is determined by a larger visual object that a human can perceive without a machine scanning it. The particular validating visual object chosen can be constantly changed so that the ticket taker does not have to be concerned that a device displaying the designated validating visual object is invalid. There are many types of visual objects that can be displayed that are easily recognized by a ticket taker. These can include but are not limited to: Patterns of color change, Animations and Geometric patterns. In one embodiment, the validating visual object that is transmitted can be computer code, that when executed by the device, causes the user device to display the desired visual pattern. In another embodiment, the validating visual object is a command that specifies what the visual pattern should be. In that embodiment, the program operating on the user’s device receives the command instruction, decodes it, and determines what visual patterns to generate based on the data in the command instruction. In another embodiment, the validating visual object is video or image data transmitted directly from the server to the device for immediate display.

[0027] In one embodiment of the invention, the user purchases a ticket from an on-line website. The website sends to the user's device a unique identifier, referred to as a token. The 4 unique identifier may be alphanumeric, contain special characters, a byte array, hexadecimal value, string and may include symbols, such as a slash or an asterisk. The term “unique identifier” is intended to include any combination of numbers, byte arrays, hexadecimal values, strings, characters, symbols or the like . The unique identifier may point to only one record and a given record may have one or more static or dynamically generated identifiers. The present invention also envisions that the unique identifier may point to one or more records and a given record may have one or more static or dynamically generated identifiers. The token is also stored in the ticketing database. When the time comes to present the ticket, the venue can select what visual indicator will be used as the designated validation visual object. The user can then request the validation visual object. The user's device will have an application that launches a user interface. The user can select validate or some other equivalent command to cause the application to fetch and download from the ticketing system a data object referred to herein as a ticket payload, which includes a program to run on the user's device. In another embodiment, the ticket payload can be pushed to the device by the venue. As a result, the application transmitted to the user's device is previously unknown to the user and not resident in the user's device. At that point the user's device can execute the program embodied in the ticket payload, which causes the validation visual object to be displayed on the user's device. The ticket taker knows what the validating visual object is, and simply looks to see that the user's device is displaying the correct visual object.

[0028] Piracy is limited in several ways. First, the ticket holder and their device does not have access to the validating visual object until a time select to be close to the point in time where the ticket has to be presented. Second, the validating visual object is one of an very large number of permutations and therefore cannot be guessed, selected or copied ahead of time. Third, the ticket payload can contain code that destroys the validating visual object in a pre-determined period of time after initial display or upon some pre-determined input event. Fourth, a number of security protocols can be utilized to ensure that a copy of the application that executes to display the validating visual object cannot be readily copied or reverse engineered.

Validating Visual Object Displays:

[0029] There many kinds of validation displays that can be utilized. The criterion for what constitutes a validating visual object is one that is readily recognizable from human observation, is encapsulated in such a way as to be transmitted to the customer's device with a minimum of network latency or download time, and that can be reasonably secured so as to avoid piracy.

Barcodes and similar codes like the QR code are not validating visual objects because a person looking at them cannot tell one apart from another. Instead, the person has to rely on a barcode scanner and computing device to verify the barcode.

[0030] In one embodiment, the period that a particular validating visual object may be used is automatically limited. Examples of validating visual objects include:

1. A color display on the device.

2. A color sequence.

3. An animation that is easily recognized.

4. Animations can include easily recognizable geometric patterns, for example an array of diamonds, or an array of rotating cubes.

5. A human recognizable image.

6. The customer's face as an image.

7. Combinations of the above.

[0031] In another embodiment, other images, for example, block letter, can be displayed so that additional information readily apparent to the ticket taker is displayed. For example, a letter can be designated for a Child ticket or a different letter for an Adult ticket.

[0032] Referring now to Figure 1, the customer uses their device (1) to purchase a ticket from the service operating the system server (2) and database (3).

[0033] In one embodiment, an authorized user associated with the venue, typically the box office manager, logs into the back-end system through a secure web-page. The authorized user can enter the web-page by entering a username, password and venue identifier. The system maintains a database (3) that associates the venue identifier with a set of usernames and password pairs that are authorized to use the system on behalf of the venue. See Fig. 7. The system checks the database (3) to verify that the venue ID, username and password are consistent with each other. The authorized user can navigate through to a point in the system user interface where a particular show may be selected for ticket taking. The user selects the upcoming show, and then selects from a display of possible validating visual objects. The validating visual object is transmitted to a device viewable by ticket taking staff at the entrances to the venue. The staff then can see the authorized object to accept for the upcoming show.

[0034] Ticket holders that have purchased tickets have a data record in the system database that contains the unique token associated with the ticket and other relevant information, including the venuelD and an identifier identifying the specific show the ticket is for. See Fig. 6. At the entrance, customers are requested to operate an application on their devices. This application fetches the stored ticket token and transmits that token to the system, preferably over a secure data channel. The database looks up the token to check that the token is valid for the upcoming show. If the token is valid, then the system transmits back to the device a ticket payload. The ticket payload contains computer code that, when operated, displays the selected validating visual object.

[0035] The customer can navigate the user interface of the application in order to cause the application to request whether to display the validating visual object. As shown in Figure 9, one or more available tickets can be displayed on the user interface, which provides the user the ability to select one of the tickets. When the customer properly actuates the user interface, for example, by actuating the Activate Tickets button (see Fig. 10), the validating visual object is displayed on the screen of the device. The animation can be presented along with other ticketing information (see Fig. 11). In one embodiment, the device transmits the ticket token to the system with a command indicating that the ticket has been used. In another embodiment, the customer can operate the application and request that the application transmit to the database the condition that the ticket was used. In that embodiment, the user can input a numeric code or password that the application uses to verify that the customer is confirming use of the ticket. In yet another embodiment, after the validating visual object has been launched, a predetermined amount of time later it can be deemed used. At that time, the application can cause the color of the object to be changed so that it indicates that there was a valid ticket, but the ticket was used. This condition is 8 useful in cases where the venue checks tickets during shows while letting customers move around the venue's facilities.

[0036] In another embodiment, the purchase of the ticket causes the ticket payload to be downloaded to the customer's device. Likewise, the authorized user for the venue will select a validating visual object for a particular show well in advance of the show. In this case, because a customer may possess the payload some time before its use, precautions must be taken to secure the ticket payload from being hacked so that any similar device can display the validating visual object. While this is a security tradeoff, the benefit is that the customer need not have an Internet connection at a time close to the showtime of the venue.

[0037] The use of electronic ticketing provides opportunities that change how tickets can be bought and sold,. For example a first customer can purchase a ticket and receive on their device a ticket token. A second customer can purchase that ticket using the system. The first customer can use the application to send a message to the system server indicating that the first customer intends to the web-page indicating that it wants to buy that particular ticket. The system can ask the first customer for a username and password to be associated with the first customer's ticket. If the second customer identifies the first customer's username, the system then can match the two together. At that point, the data record associated with the first customer's ticket is modified so that the ticket token value is changed to a new value. That new ticket token value is then transmitted to the second customer's device. At the same time, the system can operate a typical on-line payment and credit system that secures payment from the second customer and credits the first customer. In one embodiment, the system pays the first customer a discounted amount, retaining the balance as a fee.

[0038] In yet another embodiment, the first customer may be unknown to the second customer. In that embodiment, the first customer simply may indicate to the system, through a message transmitted from the application operating on the device or directly through a web-page, that the first customer is not going to use the ticket and wishes to sell it. At that point, the system can mark the data record associated with the ticket as available for sale. When the second customer makes a request to purchase a ticket for the same show, the system creates a new ticket token for the second customer and updates the ticket token stored in the data record.

[0039] In a general admission type of scenario, the ticketing database is simple: each show has a venue ID, some identifier associated with the show itself, various time indicators, the selected validating visual object, and a list of valid ticket tokens. In a reserved seating arrangement, the ticketing database has a data record associated with a show, as indicated by a show identifier, but each seat has a data record that has a unique show identifier and ticket token, which includes the identity of the seat itself.

[0040] In the preferred embodiment, the validating visual object is secured against tampering. One threat model is that a customer who has received a ticket payload would then take the data file comprising the ticket payload and analyze it to detect the actual program code that when executed, produces the validating visual object on the display screen of the device. Once that has been accomplished, the would-be pirate can then re-package the code without any security 10 mechanism and readily distribute it to other device owners, or even cross-compile it to execute on other types of display devices. The preferred embodiment addresses this threat model in a number of ways.

[0041] First, the ticket payload can be secured in a region of the device under the control of the telecommunications provider. In this case, the customer cannot access the code comprising the ticket payload. In another embodiment, the ticket payload can be encrypted in such a way that the only decrypting key available is in the secure portion of the telecommunications device. In that embodiment, the key is only delivered when an application running on the secure part of the device confirms that the ticket payload that is executing has not been tampered with, for example, by checking the checksum of its run-time image. At that point, the key can be delivered to the ticket payload process so that the validating visual object is displayed on the device.

[0042] Second, the selected animation is packaged for each device. That is, the code that operates to display the validating visual object itself operates certain security protocols. The phone transmits a ticket transaction request. The request includes a numeric value unique to the device, for example, an IMEI number. Other embodiments use the UDID or hardware serial number of the device instead of or in combination with the IMEI number. The system server then generates the ticket token using the IMEI number and transmits that value to that device. In addition, the ticket payload is created such that it expects to read the correct IMEI number. This is accomplished by the system server changing portions of the ticket payload so that the it is customized for each individual IMEI number associated with a ticket token. The animation code comprising the ticket payload is designed so that it has to obtain the correct IMEI number at run time. In another 11 embodiment, at run-time, the animation code will read the particular ticket token specific for the phone that instance of the animation was transmitted to. The code will then decode the token and check that it reflects the correct IMEI number for that device.

[0043] In another embodiment, the security protocol first requires the user to login to the server with a login username and password. The application also transmits the IMEI, UDID or serial number of the device or any combination of them. When verified by the server, an authorization key (Authkey) is transmitted to the device. The Authkey is a random number. When the user's application transmits a request for a validating visual object, it transmits the Authkey and the IMEI, UDID or serial number (or combination) that is used for verification. This is checked by the server for validity in the database. On verification, the validating visual object is encrypted using the Authkey and transmitted to the device. The application running on the device then uses the Authkey to decrypt and display the validating visual object. The Authkey is a onetime key. It is used once for each ticket payload. If a user buys a second ticket from the system, a different, second Authkey is associated with that second ticket payload. In one embodiment, the Authkey is unique to the ticket for a given event. In another embodiment, the Authkey is unique to the ticket, device and the event. In other embodiments, the Authkey can be replaced with a keypair in an assymetric encryption system. In that case, the validating visual object is encrypted with a public key, and then each user is issued a private key as the Authkey to be used to decrypt the object.

[0044] In yet another embodiment, the Authkey can be encrypted on the server and transmitted to the device in encrypted form. Only when the application is operating can the Authkey be decrypted with the appropriate key. In yet another embodiment, the application that 12 displays the validating visual object can request a PIN number or some other login password from the user, such that if the device is lost, the tickets cannot be used by someone who finds the device.

[0045] In another embodiment, the application running on the device can fetch a dynamic script, meaning a piece of code that has instructions arranged in a different order for subsets of devices that request it. The ticket payload is then modified so as to have the same number of versions that are compatible with a corresponding variation in the dynamic script. As a result, it is difficult to reverse engineer the application because the application will be altered at run time and the ticket payload customized for that alteration. One embodiment of the dynamic script would be expressed in Java(tm) computer language and rendered using OpenView. The ticket payload can be an HTML file called using Ajax.

[0046] Security can also be enhanced by actively destroying the validating visual object so that it resides in the device for a limited time. In one embodiment, the ticket payload has a time to kill parameter that provides the application with a count-down time to destroy the validating visual object. In another embodiment, the validating visual object is displayed when the user holds down a literal or virtual button on the user interface of the device. When the button is released, the application destroys the validating visual object.

[0047] Security can also be enhanced by retaining as steganographic data embedded in the validating visual object, the IMEI, UDID, Serial number or phone number of the device. The application can be operated to recover that information and display it on the screen. This makes it possible for security personnel at a venue to view that information from a validly operating device.

If the device is showing a pirated validating visual object, then the actual data associated with the device will not match and it will be apparent from inspection of the device. This way, suspicious ticket holders can be subject to increased scrutiny, the presence of which deters piracy.

[0048] In another embodiment, the ticket payload can operate a sound sampling application that requests the customer to speak in to the device. The application can then use that data to check whether the voice print of the speaker matches the expected voice print. In yet another embodiment, the device can take a picture of the customer's face, and then facial recognition code embedded in the ticket payload can operate to check whether the features of the face sufficiently match a pre-determined set of features, that is, of the customer's face at the time the ticket was purchased. In yet another embodiment, the verification can be supplemented by being sure that the use of the ticket is during a pre-determined period of time. In yet another embodiment, the verification can be supplemented by the ticket payload operating to check that the location of the venue where the ticket is being used is within a pre-determined range of tolerance to a GPS (Global Positioning System) location. In yet another embodiment, after a certain pre-determined number of downloads of ticket payloads for a specific show, the validating visual object is automatically changed. This last mechanism may be used for promotions, to select the first set of ticket buyers for special treatment at the venue. In yet another embodiment, two different validating visual objects may be used, which are selected based on the verified age of the customer. In this way, a venue can use the system to not only to verify ticket holders coming into the venue, but to verify their drinking age when alcholic drinks are ordered.

[0049] In yet another embodiment, the system’s servers control the ticket activation process. Fig. 12. In this embodiment, the token is generated randomly by the user’s mobile computing device and then transmitted to and stored on the system server as a result of the user’s request to activate the ticket. When the server receives a request to activate a ticket, the server checks whether there is already an activation token stored in its database that corresponds to that ticket. The token is stored in a data record associated with the user that is activating the ticket. The user logs into the account and then requests that a ticket be activated. If it is, then it checks whether the token received from the user’s mobile device matches the stored token. That is, it authenticates against that stored token. If the user’s request for activation is the first activation of the ticket, then the server stores the received token into the data record associated with the user’s account and keeps it there for a predetermined period of time, in order to lock the ticket to that device for that period of time. This process locks a ticket to that unique token for that lock period. Typically this will lock the ticket to the user’s mobile computing device. If the stored token does not match the token received from the user’s computing device, the ticket activation is denied.

[0050] The predetermined lock time permits a reusable ticket to be locked to a device for the predetermined lock time. This is useful in the event the user changes the mobile computing device that the user uses to the ticket. For example, a monthly train commuting ticket would be activated once each day, and would remain activated for the day of its activation. In this case, the user would validate the ticket once each day, and that activation would be locked to the device for the day. The next day, the user would be able to activate the ticket using a different mobile computing device if the predetermined time locking the activation has expired, that is, if the data record associated with the ticket has been automatically reset into an deactivated state. The 15 activation process also permits a user account to be shared within a family, for instance, but that each ticket sold to that account to be locked to one device.

[0051 ] As depicted in the protocol diagrams Fig. 13a and 13b, the user can use their mobile computing device to request that their ticket get activated for the first time. However, once that activation process has occurred, the server will store the unique token received from the activating user’s computing device in the database in a manner that associates it with the ticket and the user’s account. If another user associated with the account attempts to use the ticket by activating it, a different random token will be transmitted to the server. Because these two tokens do not match, the second activation will be prohibited.

[0052] The activation process can also permit a ticket to be shared. In this embodiment, the user who has activated the ticket can submit to the server a request that the ticket be transferred to another user. For example, a data message can be transmitted from the user’s device to the system that embodies a request to move the ticket to another user. In that case, the stored token is marked as blocked, or is equivalently considered not present. This is accomplished by storing a data flag in the database that corresponds to the ticket. One logic state encodes normal use and the opposite logic state encodes that the ticket has been shared. A data message may be transmitted to the second user indicating that the ticket is available for activation. The second user may submit a request to activate the ticket and a random token value is transmitted from the second user’s device to the server. That second token value is checked to see if it’s the first activation. Because the first user has activated the ticket, but then transferred it, the activation by the second user is not blocked. That is, the server detects that the first token is now cancelled or equivalently, 16 the system has returned to the state where the first activation has not occurred and therefore permits the new activation to take place. The new activation can also have a predetermined time to live value stored in the database that is associated with it. In this case, the activation by the second user expires and the second user can be prevented from reactivating the ticket. At the same time, the flag setting that disables the first token can be reset, thereby setting the ticket up for reactivation by the first user. By this mechanism, it is possible for the electronic ticket to be lent from one user to another.

[0053] In yet another embodiment, the ticket activation process can open a persistent connection channel over the data network that links the server and the user’s mobile computing device. In this embodiment, if the activation of the ticket and therefore the device is successful, the server can maintain a persistent data channel with a computer process running on the user’s computing device. In this embodiment, the request for ticket activation causes the user computer device to open the persistent channel. In this embodiment, the server establishes a communication process operating on the server that receives data and then causes that data to be automatically routed to the user’s computing device. The process on the user’s mobile computing device can thereby automatically respond to that received data. In tandem, the computer process operating on the users computing device can send data directly to the server process associated with that user’s session. For a server servicing many user devices, there will be one persistent channel established between the server and each mobile device that has an activated ticket.

[0054] The persistent channel between the server and the user’s computer device can be used in a variety of ways. In the preferred embodiment, the persistent connection is designed so 17 that that it maintains a bi-directional, full-duplex communications channel over a single TCP connection. The protocol provides a standardized way for the server to send content to the process operating on the user’s computing device without being solicited by the user’s device each time for that information, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-direction) ongoing interaction can take place between a process operating on the user’s computing device the server. By means of the persistent channel, the server can control the activity of the user computer device. For each user computing device, there can be a distinct persistent connection.

[0055] In one embodiment, the persistent connection is established when the user requests an activation of a ticket. See Fig. 14. In other embodiments, it can be used if the system is used to verify payment of a purchase price. In either case, the user computing device transmits a request message to the server. For each user computing device, there can be a distinct persistent channel. Each persistent channel has a label or channel name that can be used by the server to address the channel. In the case of ticketing, when the ticket is activated the data representing the validating visual object can be transmitted in real time from the server to the user computing device and immediately displayed on the device. This provides an additional method of securing the visual ticketing process. In this case, when the ticket is activated and the persistent channel is created, the label of the channel is stored in the database in a data record associated with the user and the ticket. When the server transmits the validating visual object for that ticket, it fetches from the database the label of the channel and then uses that label to route the transmission of the validating visual object. The use of the persistent channel causes the user computer device to immediately and automatically act on the validating visual object. In one embodiment, the receipt of the 18 validating visual object causes the receiving process to immediately in response interpret the command and select and display the required visual pattern. In another embodiment, the process receives a block of code that the process calls on to execute, and that code causes the visual pattern to be displayed. In yet another embodiment, the process receives image or video data and the process passes that data on to the user device screen display functions for presentation on the user device screen.

[0056] In another embodiment, a validating visual object can be transmitted to the user’s computing device to be automatically displayed on the screen without the user having to input a command to cause the display. That visual object can be displayed by the user computing device. For additional security, the server can transmit to the user computing device a visual object that contains the channel name or a unique number that the server can map to the channel name. For clarity, this additional visual object is not necessarily used for visual verification by ticket takers, as explained above. This visual object can be used by other machinery to confirm the ticket purchase transaction or even other transactions not directly related to the purchase of the ticket. The additional visual object can be in the form of a QR code, barcode or any other visual object that can be scanned, for example at a point of sale system, and from that scanned image, an embedded data payload extracted. In that visual object, data can be embedded that uniquely identifies the source of the scanned object. The channel name of the persistent channel or a number uniquely mapped on the server to identify the channel can be embedded in that scanned object.

[0057] In one embodiment, as shown on Fig. 15, a merchant can use a point of sale system operated by the merchant to scan the display screen of the user’s computing device. That point of sale system can then capture from the scanned image the channel name or a unique number that is 19 uniquely mapped on the server to the channel name. That information is transmitted to the server as a challenge for verification. The received challenge data is checked to see if it matches the channel name or corresponding unique number used to transmit the visual object that the merchant scanned. If they match up, there is a verification of a transaction. This exchange provides verification that the user’s device is present at the merchant location and that a transaction with the merchant should be paid for.

[0058] In yet another embodiment, the persistent connection provides a means for the server to control the actions of the process operating on the user’s computer device that is at the other end of the connection. In this embodiment, the server can automatically transmit a command to the process on the user’s computing device that automatically deletes the verifying visual object that has been transmitted to ensure that it cannot be reused or copied.

[0059] In one embodiment, the persistent connection is used to automatically transmit visual information to the user’s mobile computing device and to cause that information to be displayed on the screen of the device. The visual information can be the validating visual object or any other visual object that the server selects to transmit for display. In this embodiment, the persistent connection can be used by the server to transmit other information to the user’s device. In this embodiment, the server transmits text, images, video or sound and in some cases in combination with other HTML data. In another embodiment, this material comprises advertising that the server selects to display on the user’s device. The selection process can utilize the GPS feature described above to determine the approximate location of the user’s device and then based on that location, select advertising appropriate to be transmitted to that device. In yet another 20 embodiment, the server selects the advertising content by determining predetermined features of the validated ticket or purchasing transaction and then making a selection on the basis of those features. For example, a validation of a ticket to a baseball game played by a team specified in the data associated with the validated ticket may cause the selection of an offer to purchase a ticket for the next baseball game of the same team. In yet another embodiment, the character of the transaction being verified can be used to cause the selection of advertising or the transmission of data comprising a discount offer related to the transaction.

[0060] In this embodiment, the server receives from the merchant the data that determines the persistent channel. The merchant, by relying on the system for payment will also transmit transaction details, for example, an amount of money and an identity of goods or services. When the channel name or unique number associated with the channel is matched for verification, the server can transmit data representing a confirmation display down to the user’s device using the persistent connection. This data is received by the user computing device and then automatically rendered by the process at the other end of the channel connection. In addition, the server can use the transaction information to determine one or more advertisements or discount offers to transmit to the user’s computing device. The selection method can consist of one or more heuristics. In one example, the validation of the ticket for a baseball game can trigger the display of advertising for food or drinks. Likewise, a transaction for purchasing a cup of coffee can trigger an advertisement for purchasing a newspaper.

Operating Environment:

[0061] The system operates on one or more computers, typically one or more file servers connected to the Internet. The system is typically comprised of a central server that is connected 21 by a data network to a user’s computer. The central server may be comprised of one or more computers connected to one or more mass storage devices. A website is a central server that is connected to the Internet. The typical website has one or more files, referred to as web-pages, that are transmitted to a user's computer so that the user's computer displays an interface in dependence on the contents of the web-page file. The web-page file can contain HTML or other data that is rendered by a program operating on the user's computer. That program, referred to as a browser, permits the user to actuate virtual buttons or controls that are displayed by the browser and to input alphanumeric data. The browser operating on the user's computer then transmits values associated with the buttons or other controls and any input alphanumeric strings to the website. The website then processes these inputs, in some cases transmitting back to the user's computer additional data that is displayed by the browser. The precise architecture of the central server does not limit the claimed invention. In addition, the data network may operate with several levels, such that the user’s computer is connected through a fire wall to one server, which routes communications to another server that executes the disclosed methods. The precise details of the data network architecture does not limit the claimed invention. Further, the user’s computer may be a laptop or desktop type of personal computer. It can also be a cell phone, smart phone or other handheld device. The precise form factor of the user’s computer does not limit the claimed invention. In one embodiment, the user’s computer is omitted, and instead a separate computing functionality provided that works with the central server. This may be housed in the central server or operatively connected to it. In this case, an operator can take a telephone call from a customer and input into the computing system the customer’s data in accordance with the disclosed method. Further, the customer may receive from and transmit data to the central server by means of the Internet, whereby the customer accesses an account using an Internet web-browser and browser displays an interactive webpage operatively connected to the central server. The central server transmits and receives data in response to data and commands transmitted from the browser in response to the customer’s actuation of the browser user interface.

[0062] A server may be a computer comprised of a central processing unit with a mass storage device and a network connection. In addition a server can include multiple of such computers connected together with a data network or other data transfer connection, or, multiple computers on a network with network accessed storage, in a manner that provides such functionality as a group. Practitioners of ordinary skill will recognize that functions that are accomplished on one server may be partitioned and accomplished on multiple servers that are operatively connected by a computer network by means of appropriate inter process communication. In addition, the access of the website can be by means of an Internet browser accessing a secure or public page or by means of a client program running on a local computer that is connected over a computer network to the server. A data message and data upload or download can be delivered over the Internet using typical protocols, including TCP/IP, HTTP, SMTP, RPC, FTP or other kinds of data communication protocols that permit processes running on two remote computers to exchange information by means of digital network communication. As a result a data message can be a data packet transmitted from or received by a computer containing a destination network address, a destination process or application identifier, and data values that can be parsed at the destination computer located at the destination network address by the destination application in order that the relevant data values are extracted and used by the destination application.

[0063] It should be noted that the flow diagrams are used herein to demonstrate various aspects of the invention, and should not be construed to limit the present invention to any particular logic flow or logic implementation. The described logic may be partitioned into different logic blocks (e.g., programs, modules, functions, or subroutines) without changing the overall results or otherwise departing from the true scope of the invention. Oftentimes, logic elements maybe added, modified, omitted, performed in a different order, or implemented using different logic constructs (e.g., logic gates, looping primitives, conditional logic, and other logic constructs) without changing the overall results or otherwise departing from the true scope of the invention.

[0064] The present invention envisions the use of a conductive contact pad stamp to activate (or validate) the ticket payload. One example of a conductive contact pad stamp is a Snow Shoe Stamp TM, which is described in U.S. Patent Application Numbers 13385049 and 13961387, which are incorporated herein by reference. The step of activating the ticket payload to provide an activated ticket is further comprising the steps of: detecting on a capacitive touch sensor a first set of points of capacitively interactive contact resulting from proximity of a hardware tool to the capacitive touch sensor, wherein the hardware tool is not a human hand; wherein the first set of points is arranged in a spatial pattern; wherein detecting the first set of points comprises detecting the first set of points substantially simultaneously; computing, from the first set of points, a first set of parametric descriptors; generating a first comparison between the first set of parametric descriptors and a set of known parametric descriptors; and activating the ticket on the electronic device based on the first comparison. The step of activating the ticket payload to provide an activated ticket is performed by a conductive contact pad stamp in communication with the remote display device, wherein the ticket payload is activated upon detecting the conductive contact pad 24 stamp has made contact with the remote display device. The remote display device may be configured to mathematically compare the location of the conductive contact pad stamp to a reference file containing parametric data for authorized conductive contact pad stamps and upon confirmation that the conductive contact pad stamp is an authorized conductive contact pad stamp activate the ticket payload. The conductive contact pad stamp may be a unique conductive contact pad stamp having a mass of conductive material with at least one contact pad positioned in a specific configuration that is unique to that conductive contact pad stamp.

[0065] As described in referenced application 13385049, Fig. 16 shows the simplest embodiment of the Smart Stamp tool (conductive contact pad stamp) 110, in which it simply comprises a block 112 of electrically-conductive material, e.g., aluminum, with a number of contact pads 114 formed integrally therewith or assembled thereto, in electrical contact with the block 112. The contact pads 114 are proud of the surface of the block 112, and are of equal height, so that they can contact the touch screen of a smart phone or like intelligent device simultaneously. See Fig. 17, illustrating the manner in which the user places the Smart Stamp tool 110 in contact with the screen 120 of the smart phone 16. As illustrated, the tool 110 may be provided with a conductive gripping knob 118, so that the capacitance of the user's hand is in electrical contact with the contact pads 114.

[0066] In order to accept user input by way of finger contact, the screen 120 is designed so as to be able to sense a change in the electromagnetic state at the outer surface of the screen (such as the change that would be effected by the presence of a human finger or similarly sized conductive body), and the smartphone (remote display device) 116 comprises software so as to be able to locate the coordinates of the center of a point of contact. In this way, users can provide input data with a high degree of resolution using a fingertip as a blunt 25 pointer, in effect. As mentioned above, the Apple iPhone smartphone 116 is capable of simultaneously locating up to at least five contact points to a high degree of resolution; other smart devices may be able to identify fewer or larger numbers of points.

[0067] Fig. 18 illustrates one manner in which such a smartphone 116 can uniquely identify a given Smart Stamp tool 110. In the example given, it is assumed that the five contact pads 114 contact the screen 120 at five locations A, B, C, D, and E, and that the smart phone's software can identify these locations to a high degree of resolution, as above. However, because it would be undesirably complicated to ensure that the contact pads 114 of the Smart Stamp tool 110 contacted the screen 120 at any particular relative position, the points of contact themselves are not used directly to unambiguously identify the particular Smart Stamp tool 110 to the smart phone 116. Instead, the spatial relationship of the contact pads 114 themselves is determined and compared to stored data.

[0068] One method that provides sufficiently many unambiguous identifications of a particular Smart Stamp is to determine the distances between the contact pads and sum these; the resolution of the screen of, for example the iPhone smart phone is adequate to provide some hundreds of thousands of unique values. This sum can be determined as follows. Assuming that these points are located by the smart phone 116 as pairs of coordinates Xa, Ya, Xb, Yb, ..Xe, Ye (see Fig. 18) the distances between each pair of contact points (point A and B in the example) can be calculated by a simple Pythagorean-theorem calculation:

Distance AB = ((Xa-Xb)² +(Ya-Yb)²) ^1/2

[0069] If a similar calculation is carried out for each of the ten pairs of points AB, AC, AD, AE, BC, BD, BD, CD, CE and DE (collectively, the pairwise distances) and the total summed, the result is a single number. This sum, as well as each of the individual pairwise distances, can then be compared to such numbers stored as part of a like number of versions of the vendor's app (that is, if the smart phone's user has downloaded similar apps from more than one vendor) to authenticate the Smart Stamp to the app.

[0070] The app can then perform the task(s) necessary to carry out the desired transaction; in the coffee shop example, the app will store, for example, the fact that a transaction has occurred, or perhaps the dollar amount (depending on the desired reward format). The app could also, once a purchase has been verified via the Smart Stamp, initiate electronic payments to settle a bill of sale for the transaction.

[0071] It will be appreciated that in the above the orientation of the Smart Stamp with respect to the screen of the smart phone is irrelevant, so long as all of the contact pads touch the screen simultaneously. This will simplify use of the tool to authenticate itself to the app.

[0072] It will be further appreciated that the total number of possible parametric descriptors of contact pad configurations, and thus the number of possible, unique keys each identifying a given Smart Stamp to the app, is limited by the screen size, the minimum size of the contact pads, and by the minimum proximity of the contact pads. Accordingly, as an alternative to comparing pairwise distances, individually or in sum, between the observed points and the authorized points, the angles formed between lines connecting the various pairs of contact points could be calculated by the app, using simple trigonometry; the combination of the ten angles thus determined, together with the sum of the distances between the points, would also provide a large number of possible unique identifiers, so that a large number of Smart Stamps could be uniquely manufactured and identified.

[0073] In still a further embodiment, an array of contact pads can be actuated in a predetermined sequence, which is then detected and stored by the app for comparison to one or more stored sequences, vastly increasing the number of possible keys. The Smart Stamp in this embodiment might be configured as in Fig. 19, where the contact pads 114 are disposed on an insulative substrate 130 and each is connected by a corresponding switch 122 controlled by a microprocessor 126 to ground 124 in a defined sequence. The app will detect the physical location and timing of a sequence, e.g., AAABDEDCD, and compare it to one or more stored sequences to identify the Smart Stamp tool. (As described the smart phone will not know which pad is A, which is B, and so on, but can in turn assign each pad to one of A, B, C, D, and E, compare the sequence to the stored sequences, reassign the pads, perform the comparison again, and so on until a match is determined, or not, as the case may be.) In this embodiment the number of contact pads is not limited by the number of contact points the smart device can simultaneously locate.

[0074] The method described herein can be executed on a computer system, generally comprised of a central processing unit (CPU) that is operatively connected to a memory device, data input and output circuitry (IO) and computer data network communication circuitry. Computer code executed by the CPU can take data received by the data communication circuitry and store it in the memory device. In addition, the CPU can take data from the I/O circuitry and store it in the memory device. Further, the CPU can take data from a memory device and output it through the IO circuitry or the data communication circuitry. The data stored in memory may be further recalled from the memory device, further processed or modified by the CPU in the manner described herein and restored in the same memory device or a different memory device operatively connected to the CPU including by means of the data network circuitry. The memory device can be any kind of data storage circuit or magnetic storage or optical device, including a hard disk, optical disk or solid state memory.

[0075] Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held, laptop or mobile computer or communications devices such as cell phones and PDA’s, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. [0076] Computer program logic implementing all or part of the functionality previously described herein may be embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator.) Source code may include a series of computer program instructions implemented in any of various programming languages (e.g., an object code, an assembly language, or a high-level language such as FORTRAN, C, C++, JAVA, or HTML) for use with various operating systems or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form.

[0077] The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform 29 particular tasks or implement particular abstract data types. The computer program and data may be fixed in any form (e.g., source code form, computer executable form, or an intermediate form) either permanently or transitorily in a tangible storage medium, such as a semiconductor memory device (e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic memory device (e.g., a diskette or fixed hard disk), an optical memory device (e.g., a CD-ROM or DVD), a PC card (e.g., PCMCIA card), or other memory device. The computer program and data may be fixed in any form in a signal that is transmittable to a computer using any of various communication technologies, including, but in no way limited to, analog technologies, digital technologies, optical technologies, wireless technologies, networking technologies, and internetworking technologies. The computer program and data may be distributed in any form as a removable storage medium with accompanying printed or electronic documentation (e.g., shrink wrapped software or a magnetic tape), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the communication system (e.g., the Internet or World Wide Web.) It is appreciated that any of the software components of the present invention may, if desired, be implemented in ROM (read-only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques.

[0078] The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. Practitioners of ordinary skill will recognize that the invention may be executed on one or more computer processors that are linked using a data network, including, for example, the Internet. In another embodiment, 30 different steps of the process can be executed by one or more computers and storage devices geographically separated by connected by a data network in a manner so that they operate together to execute the process steps. In one embodiment, a user’s computer can run an application that causes the user’s computer to transmit a stream of one or more data packets across a data network to a second computer, referred to here as a server. The server, in turn, may be connected to one or more mass data storage devices where the database is stored. The server can execute a program that receives the transmitted packet and interpret the transmitted data packets in order to extract database query information. The server can then execute the remaining steps of the invention by means of accessing the mass storage devices to derive the desired result of the query. Alternatively, the server can transmit the query information to another computer that is connected to the mass storage devices, and that computer can execute the invention to derive the desired result. The result can then be transmitted back to the user’s computer by means of another stream of one or more data packets appropriately addressed to the user’s computer.

[0079] The described embodiments of the invention are intended to be exemplary and numerous variations and modifications will be apparent to those skilled in the art. All such variations and modifications are intended to be within the scope of the present invention as defined in the appended claims. Although the present invention has been described and illustrated in detail, it is to be clearly understood that the same is by way of illustration and example only, and is not to be taken by way of limitation. It is appreciated that various 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 which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable combination. It is appreciated that the particular embodiment described in the specification is 31 intended only to provide an extremely detailed disclosure of the present invention and is not intended to be limiting.

[0080] Modifications of the above disclosed apparatus and methods which fall within the scope of the invention will be readily apparent to those of ordinary skill in the art. Accordingly, while the present invention has been disclosed in connection with exemplary embodiments thereof, it should be understood that other embodiments may fall within the spirit and scope of the invention, as defined by the following claims.