Patent Application
20180253747
The present disclosure relates generally to a method and system for providing electronic access to products such as goods and/or services which may include various forms of facility access.
Access to various facilities needs to be controlled and limited for security, commercial purposes and for other reasons. Such facilities, for example, include: (1) office buildings, the offices and conference rooms therein and various items within the office building such as a parking lot, file storage room, computer equipment room and the like; (2) factories and production facilities, the machinery and inventory storage areas contained therein; (3) apartments, condominiums, hotels, the individual dwelling units therein, parking lots, amenity areas such as swimming pools, tennis courts and the like; (4) entertainment venues, parking access, facility access, seat access, access to special access areas such as VIP lounges, food, drinks, souvenirs, and the like; and other facilities requiring limitations on access.
Traditionally such access control has been carried out with physical metal locks and metal keys, electronic locks controlled by fixed magnetic or RFiD cards read by card readers, printed, optically read and/or magnetically read tickets read by electronic equipment and/or by hired personnel.
Prior approaches allow little ability to modify tickets or access granted on the fly, to instantly transfer possession of tickets, to collect real time data on ticket use, or to react thereto. Such prior approaches also present problems when a person wants to transfer a ticket to another person or to attend an event with guests arriving at the event independently.
In accordance with one exemplary embodiment, in a system comprising a server, reader site, and a mobile computing device (MCD), a method for providing electronic access to products includes receiving a request initiated by a user at the server for a set of products (an Order), creating at the server at least one Voucher corresponding to the Order, the Voucher including a unique identification, storing the Voucher, transmitting the Voucher to a recipient, subsequently receiving at the server a request from the MCD for a ticket, the request including at least the unique identification contained in the Voucher, in response to the subsequently receiving, transmitting a Ticket corresponding to the Voucher and the Order to the MCD, receiving at the reader site the Ticket, determining that the Ticket is valid, and in response to the determining, providing the products.
The foregoing overview is merely a summary and thus may contain simplifications, generalizations and omissions of detail. Those persons of ordinary skill in the art will appreciate that the overview is illustrative only and is not intended to be in any way limiting.
The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more exemplary embodiments and, together with the description of the exemplary embodiments, serve to explain the principles and implementations of the invention.
In the drawings:
Exemplary embodiments are described herein in the context of a method and system for electronic access. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other embodiments will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the exemplary embodiments as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.
In the interest of clarity, not all of the routine features of the implementations described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
References herein to “one embodiment” or “an embodiment” or “one implementation” or “an implementation” means that a particular feature, structure, part, function or characteristic described in connection with an exemplary embodiment can be included in at least one exemplary embodiment. The appearances of phrases such as “in one embodiment” or “in one implementation” in different places within this specification are not necessarily all referring to the same embodiment or implementation, nor are separate and alternative embodiments necessarily mutually exclusive of other embodiments.
In accordance with this disclosure, the components, process steps, and/or data structures described herein may be implemented using various types of operating systems, computing platforms, computer programs, and/or general purpose machines. In addition, those of ordinary skill in the art will recognize that devices of a less general purpose nature, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herein.
In accordance with the claims associated with this disclosure, the following terms have the following meanings.
App—An “App” is an application program configured to run under the operating system of a Mobile Computing Device.
Goods and/or Services—Goods and/or Services are the goods and/or services (also sometimes referred to as “Products” intended to be sold via the Server and delivered in response to presentation of a “Ticket”. The term is intended to include conventional goods and services of all types including, for example, access to various facilities.
Mobile Computing Device (MCD)—A mobile device such as a pad device or smart mobile telephone having input and output interfaces and capable of running an App with which it may communicate with a Reader Site, receive a Voucher, and request and receive a Ticket.
Order—a set of one or more Goods and/or Services (Products) requested by a User from the Server. This may represent a purchase by the User or the Products may be provided at no charge to the User.
Products—a set of one or more Goods and/or Services.
Reader Site—a location at which one or more devices capable of communicating with a Mobile Computing Device running an App is located. Products are provided at the Reader Site in response to reading and verifying the Ticket on the Mobile Computing Device. For example, a reader site could be located at a door or gate, a vending machine, an entrance to a venue, a restaurant or bar, a shop, or the like.
Recipient—when the Order is placed with the Server by the User the User may designate a “Recipient” to receive the Voucher corresponding to the Order. The User may be the Recipient or the User may designate another person or entity to be the Recipient or, in turn, the Recipient may designate another person to be the Recipient. The recipient is sometimes referred to herein as a Consumer.
Server—the Server as used herein is intended to broadly encompass one or more devices accessible over a digital communications network and capable of performing the acts described herein. For example, a web server, a cloud server, and other forms of servers are intended to be encompassed by the term “Server”.
Storing—Storing simply means remembering. This can be accomplished by using some appropriate form of memory device associated with and/or connected to the Server.
Ticket—a Ticket is an electronic representation of the Order for Products. It is sent to the MCD in response to a request containing the unique identification information in the Voucher.
Unique Identification—The Unique Identification is, in essence, a serial number or other relatively unique identification value used to associate the Voucher in a 1 to 1 manner with a corresponding Order on the Server.
User—a User is the person or other entity that initiates the Order.
User Access Device—a User Access Device or “UAD” is a device with which the User may communicate with or access the Server to place the Order. It may be the MCD to which the Voucher is ultimately transmitted, or it may be another MCD or a laptop or other type of computing/communication device. For example, it may be a kiosk-type computing device located in a public area. Alternatively, it may be a device linked to the server with which someone in communication with the user may enter an Order as at a service counter, call center and the like.
Voucher—a Voucher is, in essence, a receipt for the Order. It includes a Unique
Identification with which the Server may associate the corresponding Order.
In some embodiments, the server 100 can further comprise a non-transitory computer-readable storage medium 108 storing the one or more programs 106 for execution by the one or more processors 102 of the server 100.
In some embodiments, the server 100 can further comprise one or more input devices 110, which can be configured to send or receive information to or from any one from the group consisting of: an external device (not shown), the one or more processors 102, the memory 104, the non-transitory computer-readable storage medium 108, and one or more output devices 112.
In some embodiments, the server 100 can further comprise one or more output devices 112, which can be configured to send or receive information to or from any one from the group consisting of: an external device (not shown), the one or more processors 102, the memory 104, and the non-transitory computer-readable storage medium 108.
The server 100 is configured to carry out the steps of the processes and method described hereinbelow in more detail. In so configuring the server 100 it is provided with programs and modules which correspond to a set of instructions for performing a particular function. These modules and programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory may store a subset of the modules and data structures identified above. Furthermore, memory may store additional modules and data structures not described above.
The illustrated aspects of the disclosure may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.
Moreover, it is to be appreciated that various components described herein can include electrical circuit(s) that can include components and circuitry elements of suitable value in order to implement the embodiments of the subject innovation(s). Furthermore, it can be appreciated that many of the various components can be implemented on one or more integrated circuit (IC) chips. For example, in one embodiment, a set of components can be implemented in a single IC chip. In other embodiments, one or more of respective components are fabricated or implemented on separate IC chips.
What has been described above includes examples of the embodiments of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but it is to be appreciated that many further combinations and permutations of the subject innovation are possible. Accordingly, the claimed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims. Moreover, the above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.
In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the claimed subject matter. In this regard, it will also be recognized that the innovation includes a system as well as a computer-readable storage medium having computer-executable instructions for performing the acts and/or events of the various methods of the claimed subject matter.
The aforementioned systems/circuits/modules have been described with respect to interaction between several components/blocks. It can be appreciated that such systems/circuits and components/blocks can include those components or specified subcomponents, some of the specified components or sub-components, and/or additional components, and according to various permutations and combinations of the foregoing. Subcomponents can also be implemented as components communicatively coupled to other components rather than included within parent components (hierarchical). Additionally, it should be noted that one or more components may be combined into a single component providing aggregate functionality or divided into several separate sub-components, and any one or more middle layers, such as a management layer, may be provided to communicatively couple to such sub-components in order to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein but known by those of skill in the art.
In addition, while a particular feature of the subject innovation may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” “including,” “has,” “contains,” variants thereof, and other similar words are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.
As used in this application, the terms “component,” “module,” “system,” or the like are generally intended to refer to a computer-related entity, either hardware (e.g., a circuit), a combination of hardware and software, software, or an entity related to an operational machine with one or more specific functionalities. For example, a component may be, but is not limited to being, a process running on a processor (e.g., digital signal processor), a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Further, a “device” can come in the form of specially designed hardware; generalized hardware made specialized by the execution of software thereon that enables the hardware to perform specific function; software stored on a computer-readable medium; or a combination thereof.
Moreover, the words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
Computing devices typically include a variety of media, which can include tangible computer-readable storage media and/or communications media, in which these two terms are used herein differently from one another as follows. Tangible computer-readable storage media can be any available storage media that can be accessed by the computer, is typically of a non-transitory nature, and can include both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, tangible computer-readable storage media can be implemented in connection with any method or technology for storage of information such as computer-readable instructions, program modules, structured data, or unstructured data. Tangible computer-readable storage media can include, but are not limited to, RAM (random access memory), ROM (read-only memory), PROM (programmable read-only memory), EEPROM (electrically eraseable programmable read-only memory), flash memory, jump drives, USB (universal serial bus) drives (and the like) or other memory technology, compact disk (CD and CD-ROM), digital versatile disk (DVD and DVD-ROM), paper card, paper tape or other information storage media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible and/or non-transitory media which can be used to store desired information. Tangible computer-readable storage media can be accessed by one or more local or remote computing devices, e.g., via access requests, queries or other data retrieval protocols, for a variety of operations with respect to the information stored by the medium.
On the other hand, communications media typically embody computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal that can be transitory such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term “modulated data signal” or signals refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in one or more signals. By way of example, and not limitation, communication media include wired media, such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.
In view of the exemplary systems described above, methodologies that may be implemented in accordance with the described subject matter will be better appreciated with reference to the flowcharts of the various figures. For simplicity of explanation, the methodologies are depicted and described as a series of acts. However, acts in accordance with this disclosure can occur in various orders and/or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts may be required to implement the methodologies in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the methodologies could alternatively be represented as a series of interrelated states via a state diagram or events. Additionally, it should be appreciated that the methodologies disclosed in this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computing devices. The term article of manufacture, as used herein, is intended to encompass a computer program accessible from any computer-readable device or storage media.
The system also includes a reader site 204. A purpose of the system is to provide electronic access to goods and/or services. The goods and/or services may comprise one or more of access to a venue (such as passage through a locked or monitored doorway or gateway at an access-controlled facility such as an office building or an entertainment venue), access to parking facilities, provision of goods and/or optional services at the venue (such as meals and programs at an entertainment venue, for example), access to pass through additional locked or monitored doorways or gateways at the facility (such as certain file rooms, conference rooms, or other secured rooms at an office building or VIP areas or other secured areas within the entertainment facility).
The person possessing the MCD 202 and/or UAD 202a is also referred to as a user and the MCD 202 may be one or more of a smart cellular telephone or a similar device capable of being connected to a data telecommunications network. Such devices may include pad computers, watch computers, other wearable computers, laptops, portable computers and other devices with similar capabilities which are now or may become available in the future. Such devices may be carried by, worn by or implanted in the user. In one embodiment, the MCD runs an “app” or application program under its operating system in order to carry out the functions described herein although other approaches to carrying out these functions are also contemplated herein including the use of a device which is specifically configured and used for the purposes described herein.
The server 100 is any suitable computing device or system of devices connected to a data communications network 200 and configured to provide vouchers and tickets as defined herein in response to requests received from the user's MCD 202 or a User Access Device (UAD) 202a.
The reader site 204 is any suitable device or collection of devices configured to interact with the user's MCD to read the data from a ticket stored thereon, optionally update that information, optionally transmit that information and optionally transmit additional information to a server, determine if the ticket is authentic, determine if the ticket has not already been presented or has expired (if good for multiple uses and/or for a period of time), and, in appropriate circumstances, provide access to goods and/or services. The reader site 204 includes at least one device 208a, 208b, etc. configured to communicate with the user's MCD (a “reader”) to obtain the ticket and/or its associated information and optionally a local reader site server 206 which may, for example, manage a plurality of readers 208a, 208b—for example, in a situation where a facility has a number of entrances and each entrance has its own reader. Alternatively, server capability may be built into the reader devices 208a, 208b themselves for communication directly back to server 100 or for storage of the information required for them to operate autonomously of server 100.
Reader site 204 may include one or more reader site servers 206 each in communication with one or more readers 208a, 208b which, in turn, are configured to communicate (preferably wirelessly) with a MCD 202. Reader site server(s) 206 may, in turn, be in communication with server 100 over data communications network 200 to receive information which would allow server(s) 206 to verify the validity of tickets provided to readers 208a, 208b and/or to update server 100 on ticket utilization should that be desirable.
At block 304 the server creates at least one Voucher (or assigns a pre-existing voucher) to correspond to the Order and the Voucher has a unique identification such as a unique value or number. In this way, there is a one-to-one correspondence between the Voucher with the Unique Identification and the Order (or a plurality of Vouchers and portions of the Order).
In accordance with an alternative embodiment the Voucher may be associated with the Order without the need for the user to communicate directly with Server 100. For example, a user could appear at a vendor site and be served by a human attendant who would enter the requisite information into Server 100 via a UAD 202a—but in this case the UAD would be a terminal or some other device connecting the attendant to the Server 100 rather than the user to the Server 100. Similarly, the Order could be emailed by the user and manually or automatically uploaded to the Server in a conventional manner.
At block 306 the Voucher (now corresponding to the Order) is stored—either locally at the Server or in some other manner. For example, the Voucher could have been pre-stored and then simply modified to correspond to the Order—so the concept of “storing” is intended to encompass this approach as well.
At block 308 the Voucher is transmitted to a recipient optionally designated by the User. For example, the recipient may be the User. Alternatively, the User may send the Voucher or cause the Voucher to be sent to another person or entity or persons or entities as might occur in the case of a gift or an invitee.
At block 310 a MCD furnished with the Voucher requests the actual Ticket associated with the Voucher and the Order from the Server. This may occur at any time after the Voucher is associated with the Order. The request needs to include the unique identification from the Voucher (or a substitute therefor such as an encrypted version thereof).
At block 312, in response to the request at block 310, the Server transmits the Ticket (or Tickets) associated with the Voucher to the MCD. The Ticket will be stored in a manner accessible by the MCD 202 (e.g., locally, or on a cloud storage device) so that it may be retrieved when needed by an application program running on the MCD 202.
At block 314, someone in possession of the MCD with the Ticket(s) presents the MCD at a Reader Site to a reader in order to attempt to obtain the Products associated with the Order.
Wireless communication between the MCD 202 and other devices such as server 100 or readers 208a, 208b, for example, may be carried out using a variety of technologies now available or contemplated for future MCD use. These include data communication over a telephone service network, “texting” or use of the standard SMS protocol, near field communications technology available on some cell phones, blue tooth protocol communications, “BLE” and similar communications protocols and technologies providing two-way data communications capabilities.
It is also contemplated that MCD 202 may communicate with a reader 208a, 208b using visual or audible communications techniques. For example, for visual communications the display screen of the MCD 202 may be used to display a barcode or a two-dimensional bar code or a similar optically encoded image useable for communicating data. Similarly, a series of images may be displayed to the same effect. An audio signal encoded with data may be used as may an amplitude modulated light signal from a light emitting diode on the MCD or from its display. All such communications techniques may operate to communicate from MCD 202 to reader 208a, 208b or vice versa.
At block 316, the reader at the Reader Site reads the Ticket from the MCD and carries out a verification process to determine if the Ticket is valid for the Product(s) desired. The Reader Site may be pre-loaded with information with which to verify the Ticket or it may communicate with the Server after reading the Ticket.
At block 316, the Reader Site determines that the Ticket is valid for the Product(s) desired. (Alternatively, of course, it may determine that the Ticket is not valid and optionally offer suggestions to the presenter of the Ticket via some sort of display or other audible or visually perceivable interface on how to proceed next to gain the desired access).
At block 318, the Product(s) are provided.
At block 404 the server creates at least one Voucher (or assigns a pre-existing voucher) to correspond to the Order and the Voucher has a unique identification such as a unique value or number. In this manner, there is a one-to-one correspondence between the Voucher with the Unique Identification and the Order (or a plurality of Vouchers and portions of the Order).
In accordance with an alternative embodiment the Voucher may be associated with the Order without the need for the user to communicate directly with Server 100. For example, a user could appear at a vendor site and be served by a human attendant who would enter the requisite information into Server 100 via a UAD 202a—but in this case the UAD would be a terminal or some other device connecting the attendant to the Server 100 rather than the user to the Server 100. Similarly, the Order could be emailed by the user and manually or automatically uploaded to the Server in a conventional manner.
At block 406 the Voucher (now corresponding to the Order) is stored—either locally at the Server or in some other manner. For example, the Voucher could have been pre-stored and then simply modified to correspond to the Order—so the concept of “storing” is intended to encompass this approach as well.
At block 408 the Voucher is transmitted to a recipient optionally designated by the User. For example, the recipient may be the User. Alternatively, the User may send the Voucher or cause the Voucher to be sent to another person or entity or persons or entities as might occur in the case of a gift or an invitee.
At block 410 a MCD furnished with the Voucher requests the actual Ticket associated with the Voucher and the Order from the Server. This may occur at any time after the Voucher is associated with the Order. The request needs to include the unique identification from the Voucher (or a substitute therefor such as an encrypted version thereof).
At block 412, in response to the request at block 410, the Server transmits the Ticket (or Tickets) associated with the Voucher to the MCD. The Ticket will be stored in a manner accessible by the MCD 202 (e.g., locally, or on a cloud storage device) so that it may be retrieved when needed by an application program running on the MCD 202.
At block 414, someone in possession of the MCD with the Ticket(s) presents the MCD at a Reader Site to a reader in order to attempt to obtain the Products associated with the Order.
At block 416, the reader at the Reader Site reads the Ticket from the MCD and carries out a verification process to determine if the Ticket is valid for the Product(s) desired. The Reader Site may be pre-loaded with information with which to verify the Ticket or it may communicate with the Server after reading the Ticket. The Reader Site determines that the Ticket is valid for the Product(s) desired. (Alternatively, of course, it may determine that the Ticket is not valid and optionally offer suggestions to the presenter of the Ticket via some sort of display or other audible or visually perceivable interface on how to proceed next to gain the desired access).
At block 418, the Product(s) are provided.
In accordance with one embodiment, for example, the Ticket could have stored thereon information defining additional acts that may be required in order to gain access, such as presentation of a finger to a fingerprint reader, entry of a PIN in a PIN reader, or acceptance by some other type of biometric and/or photographic reader device. In such a case, access would not be granted until the Ticket was presented and the additional act or acts were successfully completed and the results verified. The desired information could be stored in encrypted form on the Ticket, or not, as dictated by the security requirements of the venue.
Some examples of specific approaches to creating the ticket and voucher are now described in some additional detail.
The voucher will contain a “registration” or “certificate” unique “hash” number which is immutably associated or “chained” to one or more ticket unique data. The voucher may also contain specific metaticket information associated with the ticket, e.g. seat 34, row LL, Section 405, alternatively metaticket information can be less specific, e.g. “General Admission”. The voucher may be issued for a period of time, may be revoked at any time and the voucher expires once the ticket(s) have been consumed. The Voucher's uniqueness is assured by combining pseudo-random number sampling or variant generation with empirical historical data and time, which, enables the generation of a unique set of number which has an elastic distribution, non-repetitive numbers and with a very low probability of collision. For example, if we have 1.71 X 10e17 outstanding vouchers (160-bit hash value) the Odds of a collision is 1 in 100 trillion. An example of a voucher number representation can be case sensitive alpha-numeric, e.g. Ab12-CH34-xXp1-We8F.
The ticket information can either be visible and included as reference within the voucher or be an encrypted message of variable length which only the reader site 208, can decrypt and interpret. The data content of the message is structured such that the reader site 208 can extract access information that it authenticates with the reader server at the reader site. In one example, for example for an office building, an embodiment the ticket message data might contain an employee identifier, e.g., a badge number that can be read out at the reader site and matched to the valid badges at the site. What makes the process of securely delivering the ticket to the reader site 200, is the concept of “containers” and the conditions (transmission) by which, either we store the ticket into the containers (mobile device writes into it) or extract the ticket from the container (the reader site 208 reads from it). The containers themselves and, transmission of thereof, are, in one embodiment, encrypted using standard algorithms, e.g. AES-256.
Tickets may additionally include metadata which may, for example, identify a vendor or company owning the facility to which the ticket is applicable, the site or sites to which it applicable, the reader or readers to which it is applicable, valid dates and/or times to which it is applicable, valid access modes to which it is applicable and, potentially, additional information. The metadata may be used to additionally limit access and/or to record information locally to the reader 208a, 208b in response to a request for access and/or a grant of access.
Metadata may, for example, be attached to a Ticket to provide personal at the venue with information which could be used to improve the experience of the Ticket user at the venue. Alternatively, or additionally such metadata may be used to keep a record of access embedded in the Ticket which could be read at the reader site and utilized in some fashion.
Tickets (including associated metadata) may be updated after issuance in a number of ways, for example, updates may be issued to the MCD 202 over the data communications network 200. Updates may be received when the MCD 202 is presented to a reader 208a, 208b, and the like. Updates may include such items as: an access valid date may be changed as when an event has a change of date, an access date range may be extended or otherwise changes as when an employment arrangement is modified, access times may be changed as appropriate, readers for which access is granted may be changed from time to time as the user associated with the MCD 202 has more or less need for access to various areas, additional items may be authorized as when a user purchases extras to go along with, for example, an entertainment venue ticket, e.g., parking, programs, food, VIP lounge access, and the like.
Some examples of particular ways to use the presently disclosed embodiments are presented now.
CONDOMINIUM/APARTMENT/HOTEL USE CASE—The approach described herein may be utilized in connection with, for example, a condominium development, apartment building or hotel. The Ticket could be set up to permit and disallow the use of certain facilities. For example, a youngster with a Ticket might be disallowed from entering the pool or spa area during certain times of the day when a life guard is not present, residents might be disallowed from access to the tennis courts if they had not paid a supplemental charge for access, and the like. Obviously normal access to doors, gates, garages and the like could be included as appropriate for a particular user.
OFFICE BUILDING/FACTORY/SCHOOL USE CASE—In the case of an office building or factory or other work place or school the access approach would be similar to that of condominiums, apartments and hotels however additional functionality could be provided—for example were a “lock down” ordered this could be integrated into the access control system to disallow use of certain ticket for certain access to be denied during the “lock down”. Additional time and day restrictions might be added to a work/school place, and the like. Access to certain facilities might vary from time to time depending upon scheduling issues and the like.
PERSONALLY IDENTIFIABLE UNIQUE DIGITAL BADGING CASE—In a work, school, hospital, government, high security situation, or the like, it is sometimes desirable that people wear a badge visible to others that is, in effect, self-authenticating, such as a photo badge. When required, the ticket approach described herein could be tied to a wearable display card (or integrated with such) which would display such visually perceivable information taken from metadata stored on the Ticket and displayed while in the secure facility.
ENHANCED SECURE AUTHENTICATION CASE—In a work, school, hospital, government, high security situation, or the like, it is sometimes desirable that people provide additional identification information along with the voucher number. When required, via the MCD (app), the voucher/ticket approach described herein could prompt the User to enter personal information, e.g. name, date of birth, biometric data, which can then be validated by the server 100, prior to issuing the ticket to the user.
ENTERTAINMENT VENUE USE CASE—In the case of an entertainment venue such as, for example, a football game, a number of separate goods and services are generally desired by a person attending. For example, parking, access to the venue, access to a seat in the venue, access to possible VIP areas within the venue, programs, food, souvenirs and the like can all be presold to a user and the user's invitees so that upon arrival all of these things are taken care of without further expenditure of funds. Additionally, sometimes sports venues like to award gifts to certain attendees—this could be expedited by adding the gift to the Ticket for redemption by the Ticket holder as desired. Refunds for items not delivered could also be accommodated in this manner.
STORAGE BOX USE CASE—The approach described herein may be used to provide access to various forms of storage boxes. Such storage boxes include post office boxes at post offices and mail service facilities and apartment/condominium buildings, delivery boxes maintained by on-line sales organizations for the secure delivery of ordered items and the like. In such a case the Ticket would be used to determine whether a particular person could access the box—and optionally make that access dependent upon the contents of the box. Thus, for example, if an alcohol delivery were made, only authorized ticket holders over a certain age would be allowed access even if under other circumstances they would have access to other types of deliveries. Access would be provided to a perimeter securing the storage boxes if provided as well as to the individual box assigned to the user. Time and day limitations could be provided as desired.
VENDING MACHINE USE CASE—in the case of a vending machine, since vending machine purchase decisions are often made at the last second, the ticket could be presented, a price and purchase negotiated with the Server 100 via the vending machine, the ticket updated, and the purchase completed.
TRANSPORTATION USE CASE—the Ticket approach can be used as described above to provide ticketing on and access to various forms of transportation including air, rail, car, driverless car, subway, and the like and can be used to provide amenities such as meals and other goods along with the underlying travel service.
In accordance with additional embodiments, it is possible that more than one voucher can be associated with a particular ticket. For example, if a Ticket has been issued, a new voucher may be used to update the Ticket without actually expunging it.
It is also possible that more than one ticket may be associated with a particular voucher. This would occur if, for example, it was decided that there should be one ticket for each good or service ordered and the voucher caused the download of these multiple tickets to the MCD.
In accordance with another embodiment, at the reader site, if the Ticket were rejected for some reason, e.g., wrong date, Ticket expired, invalid Ticket, and the like, the Reader Site may optionally display a message with a visually or audibly perceivable display to the recipient instructing the recipient on how to proceed next, e.g., go home, call the security office, send an email to a specified recipient, place the Order again, renew the Ticket, and the like. In this way user frustration with access denial could be somewhat mitigated.
While exemplary embodiments and applications have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that numerous modifications, variations and adaptations not specifically mentioned above may be made to the various exemplary embodiments described herein without departing from the scope of the invention which is defined by the appended claims.
