Patent Application
20200097925
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 radio frequency identification (RFID) cards read by card readers, printed, optically read and/or magnetically read tickets read by electronic equipment and/or by hired personnel. Sometimes such tickets and/or cards are referred to as “credentials”, “access credentials” and/or “security credentials”.
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. Further, the ability to update or change a ticket or credential, once issued and in the possession of a user, is limited or non-existent. Such prior approaches also present problems when a person wants to transfer a ticket to another person, attend an event with guests arriving at the event independently, or replace or amend a potentially compromised ticket or credential.
In accordance with one exemplary embodiment, in a system comprising a server, a reader site, a mobile computing device (MCD) and a user access device (UAD), a method for providing electronic access to products includes receiving a request submitted by a user to the server for a set of products having one or more elements (an Order or Request) from a UAD (such as the user's MCD or another electronic communications device coupled to the server over a data communications network), creating at the server at least one Voucher corresponding to the Order or Request, 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 first Ticket, the request including at least the unique identification contained in the Voucher, in response to the subsequently receiving, transmitting a first Ticket corresponding to the Voucher and the Order or Request to the MCD, the first Ticket including a first identification value which may be the unique identification, a modification of the unique identification value, a cypher of the unique identification, or another identification value, subsequently transmitting a second Ticket corresponding to the Voucher and the Order or Request to the MCD, the second Ticket replacing the first Ticket and including a second identification value which may be the unique identification, a modification of the unique identification value, a cypher of the unique identification, or another identification value, receiving at the reader site the second Ticket, determining that the second Ticket is valid; and in response to the determining, providing the one or more elements of the set or products corresponding of the Order or Request.
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, for example, the operating system of a Mobile Computing Device such as a smartphone or a laptop computer or “tablet” or “pad” computing device with a mobile Internet connection.
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. An Order or Request for products may encompass an order or request for a set of products and or services which includes one or more elements.
Mobile Computing Device (MCD)—A mobile device such as a “pad” or “tablet” computing device or smart mobile telephone (smartphone), or any other wired or wirelessly connected computing device 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 or Request—a set of one or more elements of Goods and/or Services (Products) requested by a User from the Server. This may represent a purchase by the User or some or all of 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 MCD running an App is located. Products are provided at the Reader Site in response to reading and verifying the Ticket on the MCD. 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 or Request is placed with the Server by the User the User may designate a “Recipient” to receive the Voucher corresponding to the Order or Request. 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 or Request on the Server.
User—a User is the person or other entity that initiates the Order or Request.
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 or Request. 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 or Request as at a service counter, call center and the like.
Voucher—a Voucher is, in essence, a receipt for the Order or Request. It includes a Unique Identification with which the Server may associate the corresponding Order or Request.
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 or Request 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 Request (or a plurality of Vouchers and portions of the Order or Request).
In accordance with an alternative embodiment the Voucher may be associated with the Order or Request 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 or Request 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 or Request) 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 or Request—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 or Request from the Server. This may occur at any time after the Voucher is associated with the Order or Request. 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 or Request.
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 (e.g., cellular data communications), “texting” or use of the standard SMS protocol or a derivative thereof, near field communications (NFC) technology available on some cell phones, blue tooth protocol communications, Bluetooth Low Energy (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. In doing so all or some of the elements of the set of products corresponding to the Order or Request may be so provided.
At block 404 the server creates at least one Voucher (or assigns a pre-existing Voucher) to correspond to the Order or Request 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 Request (or a plurality of Vouchers and portions of the Order or Request).
In accordance with an alternative embodiment the Voucher may be associated with the Order or Request 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 or Request 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 or Request) 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 or Request—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 or Request from the Server. This may occur at any time after the Voucher is associated with the Order or Request. 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 or Request.
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 doing so all or some of the elements of the set of products corresponding to the Order or Request may be so 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×10e17 outstanding Vouchers (160-bit hash value) the probability 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. Other possible hash mechanisms may alternatively be used as will now be apparent to those of ordinary skill in the art.
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.
MULTI-UNIT DEVELOPMENT VISITOR USE CASE—The approach described herein may be utilized in connection with, for example, a condominium development, apartment building, hotel, office building or the like (“multi-unit development”). Frequently it is desirable for a resident or “tenant” of a multi-unit development to be able to provide temporary access to “Visitors” such as friends, family, service providers (such as maintenance personnel, health care workers, pet care workers and the like) and package delivery personnel seeking to deliver a package to an individual or individuals at a multi-unit development. In performing such a delivery, it may be desirable to provide delivery personnel or equipment (such as robotic delivery devices) with temporary or periodic access to areas within the multi-unit development such as common areas and/or specific rooms or suites. Since the knowledge associated with the Visitor will generally be held by a tenant rather than a landlord or “Facility Manager” (as used herein) it may be desirable to allow the tenant to issue a temporary or recurring Ticket to a Visitor to provide the Visitor with access as desired or required. In accordance with one embodiment, the Facility Manager in a first instance provides an initial Ticket to the tenant authorizing the access desired (e.g., to a room in an office suite of the facility). The tenant may then order or request a new Ticket (e.g., to provide a Visitor with access) by reference to the old Ticket via the server (e.g., using a UAD or an MCD). The server, by referencing the old Ticket can determine that the tenant has permission to issue the new Ticket subject to whatever restrictions were imposed by the Facility Manager in the first instance and any restrictions imposed on Visitors by the Facility Manager (these may vary by tenant). For example, the Facility Manager may require notification and permission from the Facility Manager or some other entity prior to issuance of a new Ticket; time limits may be imposed; quantity and quantity per unit time limits may be imposed; notification requirements to one or more individuals may be imposed; and the like. Alternatively, the Facility Manager may impose no requirements, effectively pre-authorizing all such activity. Advantages of this approach include the ability to have the tenant directly request and cause the issuance of such Tickets, the ability to record Ticket grants and access used, the ability to cancel or expire the Tickets without the need to collect physical keys/cards.
In the various scenarios discussed below in connection with the MULTI-UNIT DEVELOPMENT VISITOR USE CASE there are three primary players: the resident, occupant or “Tenant”, The landlord or “Facility Manager” and the guest, service provider, delivery person or “Visitor”.
Initially the Facility Manager will grant the Tenant access to one or more areas in connection with, for example, a lease. The various areas are typically secured by doors with access control devices deployed thereon. Areas may include specific rooms in a facility, common areas such as garages, swimming pools, party rooms, storage areas, and the like. Some or all of the access control devices may be used with a mobile application on a MCD. In all cases the Facility Manager retains the ability to provide or revoke access at all times. An electronic database associated with the access control devices will record user identification, time and access control device identification associated with each access to an area. The mobile application will distinguish between Tenant users and Visitor Users. A user of an App may be a Tenant for some areas and a Visitor for other areas. A Visitor may not generally create additional access rights or Tickets although that capability could be provided if desired and appropriate under the circumstances. A Tenant may create additional access rights or Tickets subject to whatever rules are put in place by the Facility Manager. The App may show graphically the areas or rooms to which the user has access and may indicate whether the access is as a Tenant or as a Visitor.
When the Tenant wants to permit access for a Visitor the Tenant uses the mobile application on the MCD to issue an authorization request for a mobile key (Ticket) for a Visitor. Such requests may be routed to the Facility Manager for approval. They may include an identification of the Visitor and the purpose for the requested access. They may include areas/rooms for which access is requested and a time period (both during the day and in terms of calendar dates) for which access is requested. Tickets operate as described elsewhere herein. They are unique and will have a status associated with them, such as: Pending (waiting for authorization); Denied (Authorization refused by Facility Manager); Granted (authorized by Facility Manager) Active (Granted and Visitor has received the Ticket on their MCD); Deactivated (revoked by the Facility Manager or Tenant); and Expired (the time for validity of the Ticket has passed). Other status indicators may also be used, if desired. The App for the Tenant may provide a graphical indication of the extant Visitor Tickets and their respective status indicators. The App for the Visitor may provide a graphical indication of the extant Visitor Tickets possessed by the Visitor and their respective status indicators. An App (mobile or otherwise) used by the Facility Manager may provide all information associated with Tickets for the facility or facilities managed by the Facility Manager.
The Facility Manager may choose to control access for Visitor Tickets on a case by case basis, or may establish rules for automatic issuance of such Tickets if desired. For example, in some cases a Facility Manager may simply choose to have all requests automatically approved. In other cases, the Facility Manager may wish to manually approve all requests and may choose to contact the Tenant by telephone or email for further details prior to approving a Visitor Ticket. Essentially any scenario may be supported with the appropriate software. Tenants and/or Visitors may be informed of a Ticket Grant/Deny decision by email, telephone text message or otherwise.
A Tenant may suspend or delete a Visitor Ticket established by the Tenant at any time through use of the App. For example, if a Visitor Ticket was created for a specific event, and the event were to be cancelled or postponed, the Tenant could delete or suspend the Visitor Ticket accordingly.
A Facility Manager may likewise suspend or delete a Visitor Ticket. For example, should an employee with Visitor Tickets be terminated, the Facility Manager could then delete some or all Visitor Tickets and some or all Tenant Tickets associated with the terminated employee. Similarly, should the underlying Tenant leave or become evicted then the Facility Manager will have the ability to cancel all Tickets and Visitor Tickets associated with the former Tenant.
A Facility Manager will have access to a database containing records of all Ticket requests, grants, use and the like for conventional facilities management purposes such as auditing and tracing.
Additionally, the server, the UAD and/or one or more MCDs may be informed of the use of a Visitor Ticket (or any other Ticket) so as to enable logging of the access and/or recordation of the access (as with a video or photographic recording system) or the like.
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” to be implemented 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 USE 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 USE 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 or Request again, renew the Ticket, and the like. In this way user frustration with access denial could be somewhat mitigated.
At block 1004 the server creates at least one first Voucher corresponding to the first order or request and assigns the at least one first Voucher a first unique identification such as a number or the like.
At block 1006 the server stores the at least one first Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1008 the at least one first Voucher is transmitted to a first recipient at a first MCD (MCD1). The transmission may be initiated automatically by the server or in response to a request from the MCD 1.
At block 1010 a request for a First Ticket is received at the server from MCD1 subsequent to MCD1 receiving the at least one first Voucher. The request includes at least the first unique identification associated with the at least one first Voucher.
At block 1012 the server transmits a First Ticket corresponding to the received at least one first Voucher and the first order or request to MCD 1.
At block 1014 the server receives a request from the first recipient for a sub-Ticket for a second set of products (a second order or request) from first recipient's MCD1. The second order or request may be less than or coextensive with the first order or request, i.e., it may be for the same products or some lesser subset thereof. For example, in the tenant/facility context, the sub-Ticket may be for entry to an outer door and not to a garage, storage locker or tenant private area. The second order or request is for a sub-Ticket to be given to a Visitor (second recipient).
At block 1016 the server creates at least one second Voucher corresponding to the second order or request and assigns it a second unique identification. Creation of the second Voucher may be made contingent upon approval of a third party such as the original user or some designee thereof.
At block 1018 the server stores the at least one second Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1020 the at least one second Voucher is transmitted to a second recipient (Visitor) at a second MCD (MCD2). The transmission may be initiated automatically by the server or in response to a request from the MCD2.
At block 1022 a request for a Second Ticket is received at the server from MCD2 subsequent to MCD2 receiving the at least one second Voucher. The request includes at least the second unique identification of the at least one second Voucher.
At block 1024 the server transmits a Second Ticket corresponding to the received at least one second Voucher and the second order or request to MCD2.
At block 1026, the reader at the Reader Site reads the Second Ticket from MCD2 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 1028, 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 1030, the Product(s) are provided. In doing so all or some of the elements pf the set of products corresponding to the Order or Request may be so provided.
At block 1104 the server creates at least one first Voucher corresponding to the first order or request and assigns the at least one first Voucher a first unique identification such as a number or the like.
At block 1106 the server stores the at least one first Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1108 the at least one first Voucher is transmitted to a first recipient at a first MCD (MCD1). The transmission may be initiated automatically by the server or in response to a request from the MCD 1.
At block 1110 a request for a First Ticket is received at the server from MCD1 subsequent to MCD1 receiving the at least one first Voucher. The request includes at least the first unique identification associated with the at least one first Voucher.
At block 1112 the server transmits a First Ticket corresponding to the received at least one first Voucher and the first order or request to MCD 1.
At block 1114 the server receives a request from the first recipient for a sub-Ticket for a second set of products (a second order or request) from first recipient's MCD1. The second order or request may be less than or coextensive with the first order or request, i.e., it may be for the same products or some lesser subset thereof. For example, in the tenant/facility context, the sub-Ticket may be for entry to an outer door and not to a garage, storage locker or tenant private area. The second order or request is for a sub-Ticket to be given to a Visitor (second recipient).
At block 1116 the server creates at least one second Voucher corresponding to the second order or request and assigns it a second unique identification. Creation of the second Voucher may be made contingent upon approval of a third party such as the original user or some designee thereof.
At block 1118 the server stores the at least one second Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1120 the at least one second Voucher is transmitted to a second recipient (Visitor) at a second MCD (MCD2). The transmission may be initiated automatically by the server or in response to a request from the MCD2.
At block 1122 a request for a Second Ticket is received at the server from MCD2 subsequent to MCD2 receiving the at least one second Voucher. The request includes at least the second unique identification of the at least one second Voucher.
At block 1124 the server transmits a Second Ticket corresponding to the received at least one second Voucher and the second order or request to MCD2.
At block 1126, the reader at the Reader Site reads the Second Ticket from MCD2 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 1128, 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 1130, the Product(s) are provided. In doing so all or some of the elements pf the set of products corresponding to the Order or Request may be so provided.
At block 1204 the server creates at least one Voucher corresponding to the first order or request and assigns the at least one Voucher a unique identification such as a number or the like.
At block 1206 the server stores the at least one Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1208 the at least one first Voucher is transmitted to a recipient at a MCD. The transmission may be initiated automatically by the server or in response to a request from the MCD.
At block 1210 a request for a First Ticket is received at the server from the MCD subsequent to the MCD receiving the at least one Voucher. The request includes at least the first unique identification associated with the at least one Voucher.
At block 1212 the server transmits a First Ticket corresponding to the received at least one Voucher and the first order or request to the MCD. The First Ticket includes a first identification value which may be the unique identification, a modification of the unique identification, a cypher of the unique identification, or another identification value.
At block 1214 the server subsequently transmits a Second Ticket corresponding to the received at least one Voucher and the first order or request to the MCD. The Second Ticket includes a first identification value which may be the unique identification, a modification of the unique identification, a cypher of the unique identification, or another identification value.
At block 1216, the reader at the Reader Site reads the Second Ticket from the MCD and carries out a verification process to determine if the Second 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 1218, 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 1220, the Product(s) are provided. In doing so all or some of the elements of the set of products corresponding to the Order or Request may be so provided.
At block 1304 the server creates at least one Voucher corresponding to the first order or request and assigns the at least one first Voucher a unique identification such as a number or the like.
At block 1306 the server stores the at least one Voucher in associated storage such as a hard disk or cloud memory storage or the like.
At block 1308 the at least one Voucher is transmitted to a recipient at a MCD. The transmission may be initiated automatically by the server or in response to a request from the MCD.
At block 1310 a request for a First Ticket is received at the server from the MCD subsequent to the MCD receiving the at least one Voucher. The request includes at least the first unique identification associated with the at least one Voucher.
At block 1312 the server transmits a First Ticket corresponding to the received at least one Voucher and the first order or request to the MCD. The First Ticket includes a first identification value which may be the unique identification, a modification of the unique identification, a cypher of the unique identification, or another identification value.
At block 1314 the server subsequently transmits a Second Ticket corresponding to the received at least one Voucher and the first order or request to the MCD. The Second Ticket includes a first identification value which may be the unique identification, a modification of the unique identification, a cypher of the unique identification, or another identification value.
At block 1316, the reader at the Reader Site reads the Second Ticket from the MCD using the procedure of block 1318, or if that fails, the procedure of bloc 1320.
and carries out a verification process to determine if the Second 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 at block 1318 reads the Second Ticket by monitoring a magnetic field detection circuit for an amplitude modulated load modulation magnetic signal (AMLMMS), and in response to detecting an AMLMMS, decoding the AMLMMS to receive the second identification value. If the AMLMMS is decoded and an identification value successfully obtained then the reader carries out a verification process to determine if the Second 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 procedure carried out by the reader at block 1320 occurs if no AMLMMS is detected, i.e., no magnetic card or device capable of emulating a magnetic card is present as the Ticket or Credential. In this case it is assumed that the credential is capable of two-way communication using one or more of a variety of methods well known to those of ordinary skill in the art, such as RF, WiFi, BLE, Bluetooth, Light, Optical, and the like. This is useful where the reader is capable of more than one communications method, such as AMLMMS and something else. Where the reader is only capable of AMLMMS then, to work, the credential or MCD must be capable of AMLMMS or simulated AMLMMS. If the two-way communication is successful and an identification value successfully obtained, then the reader carries out a verification process to determine if the Second Ticket is valid for the Product(s) desired. The Reader Site may be pre-loaded with information with which to verify the Second Ticket or it may communicate with the Server after reading the Second Ticket.
At block 1322, 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 1324, the Product(s) are provided. In doing so all or some of the elements of the set of products corresponding to the Order or Request may be so provided.
Some examples of one-way protocols used by readers to communicate with access credentials include: 125 kHz proximity card protocol and MST (Mag Stripe) protocol for Mag Stripe Cards (MSCs). In each of these protocols the access credential is able to send information to the reader but the reader is not able to convey information to the credential although it will probe it with a magnetic or electromagnetic field. Both of these communications protocols are well known to those of ordinary skill in the art and will not be further described herein.
Some examples of two-way protocols used by readers to communicate with access credentials include: BLE (Bluetooth Low Energy), Bluetooth, Audio (Sound/Tones), NFC (Near-Field Communication), Visual (QR-code; other visual codes; bar codes), Contactless Smart Card, and WiFi. There are others but these are the most common. In each of these protocols the reader conveys information to the access credential and the access credential responds to the reader with its own information. These are all well known to those of ordinary skill in the art and will not be further described herein.
MAGNETIC STRIPE CARD/PROXIMITY CARD EMULATION USE CASE—In the case of proximity cards and Magnetic Stripe Cards as more fully described below, it would be advantageous to be able to use the existing protocols with the present system and an MCD taking the place of the proximity card and the MSC in order to preserve the utility of existing proximity card readers and MSC readers and to provide additional features such as updateability as well. As demonstrated below, this is now possible.
While there are many ways to read data from a MCD, there are a great number of magnetic card stripe readers and proximity card readers in the installed base that provide access to facilities yet are not otherwise useable with MCDs. A solution is to emulate a magnetic stripe card (MSC) or proximity card with an MCD so that the MCD can communicate with the proximity card reader and/or MST. This can be done as described below.
An MCD can be provided with an internally mounted or externally mounted low frequency coil which typically comprises several meters of thin gauge copper wire wound as a loop coil. Loading the coil while the coil is located within the exciter field of the (typically) 125 kHz reader presents a load to the reader as the coil interacts inductively with the exciter field. This is what most proximity cards do (e.g., a typical building entry or garage entry non-magstripe access card). In most cases the proximity card reader is tolerant of data jitter so there is generally no need to use the exciter (reader) frequency to clock the microcontroller (of the MCD). The coil may be driven as well as loaded. When driven this is referred to as magnetic coupling.
There are three well-known modulation schemes which may be used. These are FSK, PSK and ASK.
FSK is frequency shift keying, wherein data is encoded by using two different frequencies. FSK—data bits are often encoded using a Manchester encoding scheme on top of low-level bits. Low level bits are generated by one of two carrier frequencies. Each frequency is generated by toggling the coil line and waiting a certain amount of time then toggling it again. In one case the carrier period is 64 microseconds long so the coil is disconnected for 32 usec and then loaded for 32 usec. In another case the carrier period is 80 usec long so it is disconnected for 40 and loaded for 40. There is a special case every 5 short periods where an extra cycle is generated to “balance” out the zero and one times. The short period times are considered to be FSK 0's and the longer period FSK 1's. Combinations of these FSK 0's and 1's are used to encode logical 1's and 0's using Manchester encoding. Those of ordinary skill in the art will now recognize that many other encoding schemes may alternatively be used.
PSK is phase shift keying. PSK may be bi-phase—two phases—0 and 180 degrees. Other arrangements may alternatively be used.
ASK is amplitude shift keying, wherein data encoded by amplitude modulation. ASK—the ASK format is encoded directly with Manchester (self-clocking) encoding. Each bit time typically has a period of 500 usec. The coil is disconnected or loaded every 250 usec if there are no state changes or one of the states is stretched 250 usec on a bit change.
MCDs such as mobile phones may be in a “sleep” mode and so may not be prepared to communicate with a reader at all times. In order to “wake” it, various techniques can be used, such as detecting movement of the MCD (most now have acceleration sensors built in), detecting the presence of an RF field with the MCD, light detection, and the like.
Readers are often configured to save energy by going to “sleep”, i.e., the operate in a reduced power mode awaiting an event which would tell them they are to be used. Thus, the reader may need to be awakened prior to use. Generally, the inductance of the coil in the phone or the metal in the phone itself will suffice to “tell” the reader of its presence and cause it to “wake”. Thus, the proximity card reader will periodically emit a magnetic signal. When it appears that a relatively large inductance is present it will “wake” and attempt to interact with the proximity card (which has a large coil in it which presents a large inductive load to the proximity card reader).
Once the reader and the MCD are “awake” the MCD transmits a signal, the reader sees it, reads it, responds to provide access.
A Magnetic Stripe Card (MSC) is essentially a piece of magnetic computer tape embedded in a flat plastic card. To read or write to it, the stripe of magnetic computer tape is passed by a magnetic read/write head similar to that found in a data tape recorder. MSC readers are typically “read-only”.
To make a MCD emulate a MST so that it can be “read” by a MST reader, the MCD is brought close to the read/write head of the MST reader and emits a magnetic signal with its coil. That signal can in many cases be read and decoded by the MST reader read/write head as if a MSC had been passed by the head.
The ability to substitute an MCD with its inherent ability to communicate with a server some distance away over a data communications network for an MST or a proximity card reader provides a number of large advantages.
In the traditional MST/proximity card situation the Mag Stripe Card (MSC) is issued with a Mag Stripe carrying data such as an identification number which remains more or less unchanged over the life of the card. While it can be reprogrammed, it would have to be placed in a special device to do that and it cannot be reprogrammed on the fly. Similarly, a proximity card is fabricated with a particular identification value stored on it and that value is stored on nonvolatile memory and cannot be changed in normal use. It cannot be changed on the fly. By using an MCD instead of a proximity card or MSC for access and related activities the identification value of the MCD can be changed at will so that its identification value changes based upon instructions sent to it over a data communications network. In this way, if the identification value becomes compromised or is otherwise due for a change, it can be changed with relative ease. The precise approach to doing this is described below.
Thus, in one approach, the proximity card reader notices the proximity card or MCD simulating a proximity card, “wakes” if necessary, emits a 125 kHz magnetic field, the magnetic field is load modulated by the proximity card or MCD, and the proximity card reader can then read the data sent via load modulation.
In such a reader the reader may detect the coil located inside the MCD (or proximity card) and wake up. The reader then may send one or more signals using various protocols to see if a response is obtained. If a response is obtained, then the reader may proceed with that protocol. If no response is obtained, communications may proceed using the one-way protocol of proximity card or MST.
Alternatively, with an MCD it is possible to “ping” the reader to wake it up if it has that capability, cause it to emit the 125 kHz magnetic field, send data and carry out the transaction.
In another embodiment, a multi-mode reader may be provided to read MSC and/or proximity cards as well as cards and/or MCDs using two-way communication protocols.
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.
The present application is a continuation-in-part of and claims the benefit under 35 U.S.C. Sec. 120 of co-pending U.S. patent application Ser. No. 15/447,850 filed Mar. 2, 2017, in the name of inventors Kirk B. Bierach, Scott E. Lindley, Mario Sorce and Mihai Barbulescu, commonly owned herewith and the contents of which are hereby incorporated by reference as if set forth fully herein. The present application is also a continuation-in-part of and claims the benefit under 35 U.S.C. Sec. 120 of co-pending U.S. patent application Ser. No. 16/120,169 filed Aug. 31, 2018, in the name of inventors Mihai Barbulescu, Alain Morissette, Mario Sorce, Kirk B. Bierach and Scott E. Lindley, commonly owned herewith and the contents of which are hereby incorporated by reference as if set forth fully herein.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15447850 | Mar 2017 | US |
| Child | 16698250 | US | |
| Parent | 16120169 | Aug 2018 | US |
| Child | 15447850 | US |
