SYSTEM AND METHOD FOR TRACKING ITEMS AT AN EVENT

A network device generates secure item records for items evaluated at an event. A network device receives, at a provider network, event registration information including an event location and receiving item information for an item (e.g., a car, boat, etc.) to be evaluated at the event. The systems and methods assign an enrollment code for the item and provide the enrollment code to an event participant as part of a pre-registration procedure. The network device receives an item registration record, for the item, with a first digital signature; receives an item judging record, for the item, with a second digital signature; and receives an item judging validation, for the item, with a third digital signature. The network device generates a hash value from the first, second, and third digital signatures and stores the item registration record, the item judging record, the item judging validation, and the hash value.

BACKGROUND

Items presented at events, such as conventions or trade shows, are often evaluated by a critics, judges, or experts. It is often desirable to maintain records of these evaluations associated with a particular item. For example, in the case of a car show, judges' scores of items (e.g., vehicles) should be maintained as part of the item history and may affect valuation of the item.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Systems and methods provided herein may generate secure item records for items evaluated at an event. The systems and methods may include receiving, at a provider network, event registration information including an event location and receiving item information for an item (e.g., a car, boat, animal, furniture, etc.) to be evaluated at the event. The systems and methods may assign an enrollment code for the item and provide the enrollment code to an event participant as part of a pre-registration procedure.

A user device (e.g., a smart phone or tablet computer) may be provided with an application (referred to herein as an event data management application) to facilitate item registration and/or item evaluation at the event. At the time/location of the event, a user (e.g., an event staff person) may use the application on the user device to scan the enrollment code previously obtained from a network device and associate the enrollment code with an item description, an item photograph, an item serial number, and/or a serial number photograph from the item. The user device may identify a location of the user device proximate to the time and vicinity of the scanning the enrollment code. The user device may then combine, in an item registration record, the enrollment code, the location information, and the one or more of the item description, the item photograph, the item serial number, and/or the serial number photograph. The user device may generate a digital signature for the item registration record and send to the provider network the item registration record with the digital signature.

As described further herein, the event data management application (or a different application) residing on the user device may be used to collect judging results and or judging verifications. Similar to the item registration record, each of the judging results and judging verifications may be assigned a unique digital signature before the user device sends the judging results and judging verifications to the provider network.

According to an implementation described herein, the provider network may receive the item registration record with the first digital signature, the item judging record with the second digital signature, and the item judging validation with the third digital signature. The systems and methods may generate a hash value from the first, second, and third digital signatures and may store, in a memory and as a single record, the item registration record, the item judging record, the item judging validation, and the hash value. This process ensures that the event data entered into the system remains intact and unchanged.

FIG. 1is a diagram illustrating an exemplary environment100in which systems and/or methods described herein may be implemented. As illustrated, environment100may include user devices110-1through110-N (collectively “user devices110” and individually “user device110”), a provider network120that includes a web server130, a database140, an eligibility server150, and an application server160; a global positioning system170; and a third-party device180interconnected by a network190. Components of environment100may be connected via wired and/or wireless links.

User device110may include a computational or communication device. User device110may include, for example, a personal communications system (PCS) terminal, a smart phone, a tablet computer, a laptop computer, or another type of mobile computational or communication devices. In another implementation, user device110may include a fixed-location computing device, such as a desktop computer, or a fixed-location computing device in communication with a mobile accessory (e.g., a camera in wired/wireless communication with a personal computer). User device110may generally be equipped with hardware and software to provide location detecting capabilities and to capture images of a local environment. For example, user device110may include a location identification system (e.g., global positioning system (GPS) or another assisted location determining system) and a content recording device (e.g., a camera, a video camera, etc.). In implementations described herein, user device110may be configured with an application (e.g., an event data management application) to collect registration information (e.g., including photographs and/or code scans) and/or judging information for items at an event, generate a digital signature for a record of the collected information, and provide the collected information and digital signature to provider network120.

Provider network120may include network devices to supply backend services to user devices110for tracking items at events. Provider network120may include, for example, one or more private IP networks that use a private IP address space. Provider network120may include a local area network (LAN), an intranet, a private wide area network (WAN), etc. In one implementation, provider network120may implement one or more Virtual Private Networks (VPNs) for providing communication between, for example, any of web server130, database140, and eligibility server150. Provider network120may be protected/separated from other networks, such as network190, by a firewall. Although shown as a single element inFIG. 1, provider network120may include a number of separate networks.

Web server130may include one or more network or computational devices to manage service requests from eligible user devices110. In one implementation, web server130may provide an application (e.g., an event data management application) and/or instructions to user device110to enable user device110to collect information for items at events. For example, the application and/or instructions may provide user interfaces to solicit pre-registration codes, photographs, and other user input used to generate item registration records, item judging records, and/or judging verifications. The application and/or instructions may also generate digital signatures for uploading records (e.g., item registration files, item judging files, etc.). In another implementation, as described further herein, web server130may provide multiple types of browser-based user interfaces to facilitate event registrations, item registrations (e.g., for items at particular events), and item judging records (e.g., for items at particular events). Web server130may receive event registrations, item registration records, item judging records, and/or judging verifications from user devices110, may process/collate the received data, and may forward the data to database140for storage.

Database140may include one or more databases or other data structures to store records for event registrations, item registrations, and/or item record uploads (e.g., provided by user devices110via web server130). In one implementation, database140may also store data retrieved from and/or used by eligibility server150.

Eligibility server150may include one or more network or computational devices to provide backend support for authorizing use of a provider network120by user devices110. For example, eligibility server150may store identification information for registered users and/or user devices110to verify that a particular user/user device110has access to services and/or information provided by provider network120. Upon verifying eligibility of a user/user device110, eligibility server150may, for example, provide a link (e.g., a URL) to permit user device110to access other devices in provider network120, such as web server130.

Application server160may include one or more network or computational devices to perform services accessed through web server130. For example, application server160may manage application downloads provided to user devices110, may process incoming data files for storage in database140, and/or may generate hash values for uploaded records.

Positioning system170may include one or more devices configured to provide location information for user devices110. In some implementations, location information may include, for example, GPS information or another form of global navigation satellite system (GNSS) information. In one implementation, positioning system170may include one or more cellular towers, wherein user devices may retrieve location information in the form of cellular tower triangulation information. Additionally, or alternatively, positioning system170may include a GPS satellite to determine a location of user device110. In still other implementations, positioning system170may include a device with a fixed address or location associated with a wired network connection or IP address. For example, user device110may report, as location data, a service set identifier (SSID) (e.g., associated with a local wireless router) to which user devices110may be connected.

Third-party device180may include a computational or communication device, such as a personal computer, tablet computer, or mobile communication device. In one implementation, third-party device180may include a device similar to user device110. Third-party device180may include, for example, an email program or web browser to facilitate communications with devices in provider network120.

Network190may include a local area network (LAN); an intranet; the Internet; a wide area network (WAN), such as a cellular network, a satellite network, a fiber optic network, a private WAN, or a combination of the Internet and a private WAN; etc., that is used to transport data. Although shown as a single element inFIG. 1, network190may include a number of separate networks that function to provide services to user devices110and/or provider network120.

InFIG. 1, the particular arrangement and number of components of network200are illustrated for simplicity. In practice there may be more user devices110, provider networks120, web servers130, databases140, eligibility servers150, application servers160, positioning systems170, third-party devices180, and/or networks190. For example, there may be hundreds or thousands of user devices110.

FIG. 2is a diagram of exemplary components of a device200. Each of user device110, web server130, eligibility server150, application server160, and third-party device180may be implemented/installed as a combination of hardware and software on one or more of device200. As shown inFIG. 2, device200may include a bus210, a processing unit220, a memory230, an input device240, an output device250, and a communication interface260.

Bus210may permit communication among the components of device200. Processing unit220may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processing unit220may be implemented as or include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like.

Memory230may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processing unit220, a read only memory (ROM) or another type of static storage device that stores static information and instructions for the processing unit220, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.

Input device240may include a device that permits a user to input information to device200, such as a keyboard, a keypad, a mouse, a pen, a microphone, a camera, one or more biometric mechanisms, and the like. Output device250may include a device that outputs information to the operator, such as a display, a speaker, etc.

Communication interface260may include any transceiver-like mechanism that enables device200to communicate with other devices and/or systems. For example, communication interface260may include mechanisms for communicating with other devices, such as other devices of network200.

AlthoughFIG. 2shows exemplary components of device200, in other implementations, device200may include fewer components, different components, differently arranged components, or additional components than those depicted inFIG. 2. As an example, in some implementations, a display may not be included in device200. In these situations, device200may be a “headless” device that does not include input device240. Alternatively, or additionally, one or more components of device200may perform one or more other tasks described as being performed by one or more other components of device200.

FIGS. 3-5Binclude exemplary user interfaces that may be provided on user device110via the event data management application.FIG. 3provides a user interface300for identifying a location of user device110during an item registration at an event. For example, the event data management application may request, via user interface300, permission of a user to identity and use location information of user device110(e.g., as determined with information from positioning system170). If allowed by the user, the event data management application may incorporate location information into data collections processes described herein.

FIG. 4Aprovides a user interface400for scanning a bar code for an item during an item registration at an event.FIG. 4Bprovides a sample user interface410for manipulating a data record of an item during an item registration at an event. As shown inFIG. 4A, user interface400of the event data management application may provide instructions and an interface to capture (e.g., via an integrated camera) and interpret a barcode (e.g., a one- or two-dimensional barcode) associated with an item to be evaluated. As shown inFIG. 4B, user interface410of the event data management application may provide instructions and an interface to input additional information about the item to be evaluated relative to event location and associate the additional information with a portion of a unique item identifier (e.g., an item's VIN).

FIG. 5Aprovides a user interface500indicating a pre-registered item during an item registration at an event.FIG. 5Bprovides a user interface510summarizing multiple items registered at an event. As shown inFIG. 5A, user interface500may present item information for a pre-registered item based on, for example, a bar code reading (e.g., collected via user interface400) or a manually entered selection. As shown inFIG. 5A, user interface510may include item information for multiple items that may be registered at an event. Details of each item may be selected, for example, by selecting a particular item displayed in user interface510.

FIG. 6is a flow diagram of an exemplary process600for registering an event with items to be tracked. In one implementation, process600may be performed by user device110. In another implementation, some or all of process600may be performed by another device or group of devices, including or excluding user device110. For example, a device in provider network120may perform one or more parts of process600.

Process600may include receiving event registration information with an event location (block610) and storing the event registration information with location information (block620). For example, an event coordinator may use a user device110to access web server130and provide event registration information for a scheduled event, such as a trade show. Registration information may include, for example, an event date/time, an event name, and/or an event location. The event location may include, for example, a physical address, a location name (e.g., a convention center name, an airport name, etc.), latitude and longitude, or GPS coordinates, etc. Web server130may receive the event registration information and store the event registration information in database140.

Process600may also include receiving participant information (block630) and associating the participant information with the event and assigning an enrollment code (block640). For example, participants and/or event coordinators may access web server130to upload information about expected participants and/or expected items (e.g., items to be evaluated) for the event. In one implementation, participant information may be collected from individuals (e.g., via user devices110or third-party devices180) as part of a participant pre-registration process for the event. In another implementation, participant information may be provided as part of the event registration. Participant information may include items and item categories (e.g., for which particular items may be judged). Web server130may receive the participant information and associate the information with the event information in, for example, database140. In one implementation, web server130may assign an event-unique enrollment code for each item.

Process600may also include receiving judge information (block650) and associating the judge information with the event (block660). For example, judges (or other evaluators) and/or event coordinators may access web server130to upload information about expected judges for the event. In one implementation, judge information may be collected from individual judges (e.g., via user devices110) as part of a judge registration process for the event. In another implementation, judge information may be provided as part of the event registration. Judges may be associated with, for example, particular items and/or categories for the event. Web server130may receive the judge information and associate the judge information with the event information in, for example, database140.

FIG. 7is a flow diagram of an exemplary process700for registering an item at an event location. In one implementation, process700may be performed by user device110. In another implementation, some or all of process700may be performed by another device or group of devices, including or excluding user device110. For example, a device in provider network120may perform one or more parts of process700.

Process700may include obtaining participant and event information (block710) and obtaining and/or verifying descriptive item information, including a vehicle identification number (VIN) (block720). For example, a user of user device110(e.g., an event staff person) may register an event participant at the beginning of an event. The participant may provide personal verification (e.g., an identification card, pre-registration letter, etc.) and/or item verification (e.g., a pre-registration enrollment code from process600), and present an item to be judged at the event. The item to be judged may be listed with descriptive information (e.g., particular color, year, make, and model of a vehicle) and at least a portion of a unique item identifier (e.g., a VIN, serial number, etc.). User device110may include, for example, an event data management application. The user (e.g., event staff person) may use user device110to enter the participant/item information or retrieve the participant information from an earlier registration (e.g., from web server130/database140). In one implementation, descriptive information about the item to be judged can be retrieved from provider network120and populated in a user interface of the event data management application based on an enrollment code provided at the time of the event registration.

Process700may also include obtaining an item photograph (block730), obtaining a VIN photograph (block740), and obtaining user device location data (block750). For example, user device110may capture one or more images of the item (e.g., using an integrated camera) at the event site and one or more images of the item VIN (e.g., as printed/stamped on the item). In one implementation, user device110may prompt the user to take the necessary photographs. User device110may obtain location data (e.g., of user device110at the time of the photographs), using for example, GPS information or other location determining techniques.

Process700may further include combining the participant information, the descriptive item information, the item image, the VIN image, and the location data into an item registration record (block760). For example, user device110may collect information described above in connection with blocks710-750and may store the collected information as a single record or a single set of associated items. In one implementation, user device110may store the single record or set of associated items in a temporary cache or another local memory location. In another implementation, the single record for the item registration package may include less or additional information than the information described above in connection with blocks710-750.

Process700may also include soliciting and/or receiving verification from an authorized user (block770). For example, at some point prior to transferring item registration data, user device110may solicit a pass code (e.g., a personal identification number, security code, etc.) from the user. The pass code may be assigned to the user prior to the item registration process by, for example, an event coordinator. Assuming a valid pass code is received, user device110may permit item registration data to be uploaded to, for example, a device (e.g., database140or another device) in provider network120.

Process700may also include submitting the item registration package with a digital signature to a backend system (block780). For example, the registration package may be provided to, for example, web server130(or another device in provider network120) using an encryption process. As part of the data transfer process, user device110may initiate an exchange of keys (such as public/private key pairs and/or digital certificates) or other credentials so that the registration package can be securely tied to other communications between user device110and web server130. For example, along with an initial device set up, web server130may provision authentication keys to user device110to initiate a handshake sequence between user device110and web server130. As described herein, user device110may submit the item registration package using an “originating key set” that is valid only for the duration of the event.

FIG. 8is a flow diagram of an exemplary process800for providing judging records for an item at the event location. In one implementation, process800may be performed by user device110. In another implementation, some or all of process800may be performed by another device or group of devices, including or excluding user device110. For example, a device in provider network120may perform one or more parts of process800.

Process800may include registering and/or verifying a judge (block810), and identifying an item to be judged (block820). For example, a judge may identify himself/herself using an authentication procedure (e.g., providing unique judge information such as a user name/password). Once authenticated, user device110may grant the judge access to an event data management application. The event data management application may allow the judge to enter a description/serial number of an item to be judged or to select an item from a pre-populated list of registered items (e.g., items registered using process700above).

Process800may include obtaining an item photograph (block830) and obtaining a VIN photograph (block840). For example, user device110may capture, at the time of judging, one or more images of the item (e.g., using an integrated camera) and one or more images of the item VIN (e.g., as printed/stamped on the item). In one implementation, user device110may prompt the judge to take the necessary photographs (e.g., prior to providing user interface to record judging scores. In one implementation, user device110may again obtain location data (e.g., of user device110at the time of the photographs/judge inputs, using for example, GPS information or other location determining techniques.

Process800may include receiving a judge's scores and/or results for the item (block850) and combining the judge information, the item information, the item photograph, the VIN photograph, and the judge's scores to form an item judging package (block860). For example, user device110may collect information described above in connection with blocks810-850and may store the collected information as a single record or a single set of associated items. In one implementation, user device110may store the single record or set of associated items in a temporary cache or another local memory location. In another implementation, the single record for the item judging package may include less or additional information than the information described above in connection with blocks810-850.

Process800may also include submitting the item judging package with a second digital signature to a provider network (block870). For example, user device110may submit the item judging package using an “originating key set” that is valid only for the duration of the event. The judging package with the second digital signature may be provided, for example, to web server130for storage in database140.

Additionally, or alternatively, process800may include submitting a judging validation with a third digital signature (block880). For example, a user (e.g., event staff or judge) of user device110may retrieve the item judging package from a local memory. The user may perform a final review of the judging results and provide a final approval and/or (physical) signature. The final approval may be combined with user identification information (e.g., a user name and password of the final reviewer). User device110may store the validated judging file and submit the validated judging file with the third digital signature to provider network120.

According to implementations herein, two pairs of encryption keys may be used for digital signatures—an “origination key set” and an “alteration key set.” While both keys of a key pair are generated on a backend server (e.g., web server130or application server160) only one key of each pair is actually stored on each device, with a backend device (e.g., web server130) and a front end device (e.g., user device110) both containing an individual key each. The key located on user device110(e.g., the event data management application) would exist for the duration of the event for which it was provisioned and then become useless afterward. That is, the “origination key set” is a temporarily assigned key for a single event at a certain time and place. Thus, a digital signature provided by the origination key set mechanism is irrefutable in origination. The second key, the “alteration key set” is granted to or revoked from a party of distinction or preference. While the temporarily-assigned origination key would insert or create the initial data system record (e.g., an item judging record or item registration record), the alteration key would be able to override and potentially alter the record based on privilege.

The following scenario is provided as an example: Assume an event occurs and a volunteer at an event is given privilege to register an item at the event (e.g., a car show). The event chairperson or administrator assigns a Personal Identification Number (PIN) to the volunteer. The volunteer logs into the event data management application on his/her user device110using the PIN to enable the user interface/menus. Each time the menu task is completed (e.g., an item is registered or judged, etc.), the submission within the event data management application requires the PIN (e.g., corresponding to an origination key) to commit the transaction. At the end of the event, the volunteer leaves and finds the application PIN no longer allows access to the device menus or submission of data. A few days later, a participant from the event disputes the final score of a judged item and asks for a review and possible “re-tally” of event results for the particular item. Upon review, a decision is made to withdraw some deductions from the item judging record. The event manager/administrator logs in with his PIN (e.g., corresponding to an alteration key) and makes an adjustment. The event manager/administrator later discovers upon conclusion of another show that his PIN does not allow for him to make changes because his role has changed and his altering capability has been revoked.

FIG. 9is a flow diagram of an exemplary process900for receiving and managing item records from an event. In one implementation, process900may be performed by web server130. In another implementation, some or all of process900may be performed by another device or group of devices, including or excluding web server130. For example, another device in provider network120may perform one or more parts of process900.

Process900may include receiving event registration data (block910), receiving an item registration package with a first digital signature (block920), receiving an item judging package with a second digital signature (block930), and receiving a judging validation with a third digital signature (block940). For example, web server130may receive an event registration for which items to be evaluated/judged will be associated. Items may be pre-registered with enrollment codes assigned. At the time of the event, an item registration package with a first digital signature may be received (e.g., via the event data management application and process700described above). At the time the item is judged, an item judging package with a second digital signature and a judging validation with a third digital signature may be received (via the event data management application and process800described above).

Process900may include storing the item record including the item registration package, the item judging package, and the judging validation (block950). For example, web server130may receive the item record including the item registration package, the item judging package, and the judging validation, for a particular item, from one or more user device110. Web server130may associated the item record including the item registration package, the item judging package, and the judging validation using the assigned enrollment code and/or other item information and may store the receive data in database140.

Process900may include generating a hash value of the first, second, and third digital signatures from the item record (block960) and associating the hash value with the item record (block970). For example, a final digital signature of the three previous signatures may be generated to establish a comparison point. The final digital signature may include a hash value of the first, second, and third digital signatures that may be calculated from a particular hash algorithm, such as MD5, SHA-1, SHA-256, etc. The final digital signature may be associated with the item record and stored with the item record in database140.

Item records stored in database140may be accessed, for example, by third-parties with authorization (e.g., using third-party devices180). The final digital signature with each item record may be used to establish a comparison point similar to a hash for downloaded files. If the hash of the downloaded file doesn't match the published hash, it is assumed the file is incomplete, corrupt or tampered with. Similarly, if the digital signature of each item record does not match a published digital signature from process block970, the item record may be considered suspect. If any piece of the item record is modified (e.g., as an authorized modification), the digital signatures must be recreated or the records will reflect that the data has been tampered with. If something in the item record has to be modified after the fact, the original record, a description of the modification, and user signature would become the basis for the new digital signature.

Systems and/or methods described herein may be used to establish an irrefutable record of an item's attendance (or presence), judging, and scoring, at an event. The systems and/or methods described herein use a unique combination of two-factor authentication, GPS coordinates, date-time stamp, and digital signatures to ensure the records stored are accurate and irrefutable.

In an exemplary illustration, a person registering a vehicle at an event may begin by taking a photograph of the vehicle using the event data management application running on a iPhone or Android device with the embedded GPS coordinates enabled as part of a check in process to establish the vehicle is present at the show. Additionally, the person can photograph the VIN tag and validate the last N digits by entering them into a text box (as prompted by the event data management application). This information will be packaged together and stored on a central server with a digital signature.

When the vehicle is judged a similar process is undertaken with an additional image of the vehicle and VIN. This along with the results of the judging and the judges' signatures will be stored together with a new digital signature. Finally, a final review of the judging results is a final sign-off which is digitally signed.

A final digital signature of the three previous signatures will establish a comparison point similar to hash for downloaded files. If the hash of the downloaded file doesn't match the published hash, it is assumed the file is incomplete, corrupt or tampered with.

If any piece of the record is modified, the digital signatures must be recreated or the records will reflect that the data has been tampered with. If something had to be modified after the fact, the original record, description of the modification and user signature would become the basis for the new digital signature. This process ensures that the data entered into the system during judging remains intact and unchanged.

In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense. For example, while series of blocks has been described with respect toFIGS. 6-9, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.

It will be apparent that different aspects of the description provided above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects is not limiting of the invention. Thus, the operation and behavior of these aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement these aspects based on the description herein.