Patent Description:
The present disclosure is generally directed to location devices and, in particular, toward mechanisms for obtaining pseudonymous proximity location information.

There is a new generation of proximity devices emerging that allow an application on a mobile device to interact with the proximity device to determine that the mobile device and a specific application running on the mobile device is at a specific physical location. These types of proximity devices are referred to as a Proximity Location Device (PLD). Near-Field Communication (NFC) tags and Bluetooth Low Energy (BLE) beacons are examples of devices that can be utilizes as a PLD.

A BLE beacon broadcasts a model identifier - usually in the form of a Universally-Unique Identifier (UUID) - having a Major. minor identifier. The application on the mobile device is registered against the UUID and is automatically awoken when it receives the broadcast request and can then determine the user experience by using the Major. minor identifier. Often the Major represents the location (e.g. supermarket in downtown Washington) and the minor a specific sub-location (e.g. electronics section / aisle).

Service Providers are currently investing money to install a network of beacons. Once installed, the beacons are connected to a service platform which allows the Service Provider to offer location-based services to users (e.g., a location-based service can be offered to the supermarket).

A problem encountered by some Service Providers is that the broadcast information of the beacon is freely available and readable to anyone that is in the vicinity of the beacon. In fact, 'Beacon maps' are being developed and deployed that link physical location coordinates and Beacon identifiers. These 'Beacon maps' are being published on the Internet and other uncontrolled and untrusted outlets.

The uncontrolled distribution of 'Beacon maps' allow other Service Providers to create a service platform that effectively piggy-backs on beacons deployed by other Service Providers for free. With the threat of having their deployed PLDs hijacked, some Service Providers are hesitant to invest in installing a large base of PLDs.

<CIT> discloses a security enhancing system for creating temporary identification information used to mask actual identification in a wireless communication device. The temporary identification information conforms to a standard usable by at least one wireless communication medium, and may be used by other devices in communicating with the wireless communication device, however, only other devices possessing secret address component information may determine the actual identity of the masked wireless communication device. The temporary identification information may further be recompiled when a threshold condition is satisfied.

<CIT> discloses systems and methods of providing location information associated with moveable objects that include receiving tag identification (ID) information reports from a plurality of tag sensors. A movable object associated with each of the ID information reports received from the tag sensors is identified. Location information associated with the movable objects is updated responsive to the received ID information reports to provide updated location information for the moveable objects and an owner associated with each of the movable objects is determined. Access to the location information associated with respective ones of the movable objects is allowed only to requestors authorized by the owner associated with the respective ones of the movable objects, wherein the tag sensors have not been provided notification of ID information associated with the movable objects or of the owners associated with the moveable objects.

It is, therefore, one aspect of the present disclosure to create a pseudonymous PLD with the following characteristics:.

The present invention concerns a pseudonymous proximity location system according to claim <NUM> and a method according to claim <NUM>.

These and other objects of the present disclosure can be achieved by using a pseudonymous PLD in the following manner (for example):.

With respect to anonymity, one or a combination of the following may be implemented by the PLD:.

This effectively means that a non-authorized mobile reading device will either get the same identifier from all PLDs, regardless of location or the non-authorized mobile reading device will get a random identifier that is useless to the non-authorized mobile reading device. Both of these scenarios effectively render the identifier from the PLD useless to the non-authorized mobile reading device because the non-authorized mobile reading device will not be able to identify the specific proximity device or its specific location.

With respect to authorized applications retrieving the real identifier, the application can leverage a component that allows the application (or the authorized mobile reading device) to retrieve the real identity of the PLD by one or more of:.

The present disclosure will be further understood from the drawings and the following detailed description. Although this description sets forth specific details, it is understood that certain embodiments of the invention may be practiced without these specific details.

With reference initially to <FIG>, a communication system <NUM> in which location tracking of PLDs <NUM> is made possible will be described in accordance with at least some embodiments of the present disclosure. The communication system <NUM> is shown to include a communication network <NUM> that provides communication capabilities between a plurality of readers or reading devices <NUM>, and a server <NUM>. Other communication components may also be connected to the communication network <NUM> without departing from the scope of the present disclosure.

The communication network <NUM> may include any type of communication medium or collection of communication equipment that enables remote communication devices to exchange information and/or media with one another using any type of known or yet-to-be developed transport protocol. The communication network <NUM> may facilitate wired and/or wireless communication technologies. The Internet is an example of the communication network <NUM> that constitutes an Internet Protocol (IP) network consisting of many computers, computing networks, and other communication devices located all over the world, which are connected through many telephone systems and other means. Other examples of the communication network <NUM> include, without limitation, a standard Plain Old Telephone System (POTS), an Integrated Services Digital Network (ISDN), the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Session Initiation Protocol (SIP) network, a Voice over IP (VoIP) network, a cellular network (e.g., <NUM>, <NUM>, LTE, etc.), and any other type of packet-switched or circuit-switched network known in the art. In addition, it can be appreciated that the communication network <NUM> need not be limited to any one network type, and instead may be comprised of a number of different networks and/or network types. Moreover, the communication network <NUM> may comprise a number of different communication mediums such as coaxial cable, copper cable/wire, fiber-optic cable, antennas for transmitting/receiving wireless messages, and combinations thereof.

The reader <NUM> may correspond to a portable or stationary unit or device capable of reading data from one or more PLDs <NUM> via a communication channel <NUM>. The reader <NUM>, in some embodiments, corresponds to a wall-mounted reader. In some embodiments, the reader <NUM> corresponds to a portable reading device. In some embodiments, the reader <NUM> corresponds to a mobile communication device that is capable of reading data from a PLD <NUM>. In some embodiments, different types of readers <NUM> may be connected to the communication network <NUM> and each of the readers <NUM> may be provided with one or more tracking nodes <NUM> that enables the server <NUM> to obtain location or tracking information for the PLDs <NUM> that interact with a reader <NUM> via the communication channel <NUM>. In this way, the tracking node <NUM> of each reader <NUM> is utilized to obtain certain location and/or identity information from the PLD <NUM> and forward the information along to the server <NUM>. Upon receiving the location and/or identity information from a tracking node <NUM>, the server <NUM> may employ a tracking application <NUM> to collect and organize the information obtained from the plurality of tracking nodes <NUM>. This collected and organized location and identification information can then be delivered to a customer device or network <NUM> via a customer portal <NUM>. Thus, the tracking application <NUM> working in connection with the tracking nodes <NUM> is able to create a complete and substantially real-time depiction of location information for PLDs <NUM> that interact with readers <NUM>.

The PLDs <NUM> may correspond to any type of device capable of interaction with a reader <NUM> and communicating some form of identification information to the reader <NUM>. Non-limiting examples of PLDs <NUM> include Near-Field Communication (NFC) tags and Bluetooth Low Energy (BLE) beacons. Any other device capable of physical movement, establishment of the communication channel <NUM>, and delivery of some form of data to the reader <NUM> may also be considered a PLD <NUM>. In some scenarios the PLD <NUM> may include a microprocessor and antenna capable of establishing the communication channel <NUM>. Operation of the antenna and messages delivered thereby may be controlled by the microprocessor of the PLD <NUM>.

The communication channel <NUM> may correspond to any contact-based or contactless communication link between the reader <NUM> and PLD <NUM>. A contactless communication channel <NUM> may include one or more of a WiFi channel (e.g., establishing according to <NUM>. 11N communication standards), a Bluetooth channel, an NFC channel (e.g., an inductive coupling between the antenna of the PLD <NUM> and an antenna in the reader <NUM>). Generally speaking, the contactless communication channel may correspond to a proximity-based communication channel that is only established when the PLD <NUM> and reader <NUM> are within a predetermined distance of one another. Contact-based communication channels <NUM> may include, without limitation, a contact-based smart chip connection, USB port connections, Ethernet connections, etc..

The server <NUM> may correspond to any type of known server or collection of servers (e.g., server farm, server cluster, etc.) capable of communicating over the communication network <NUM> and communicating with the customer/device network <NUM>. The customer portal <NUM> used to expose location information obtained via execution of the tracking application <NUM> may, in some embodiments, correspond to an Application Programming Interface (API) or Graphical User Interface (GUI) exposed to the customer device/network <NUM> as a website, webportal, HTML document, XML document, etc. The interface between the server <NUM> and customer/device network <NUM> may be customer-specific or generic among a plurality of customers that are served by the server <NUM>. Thus, although <FIG> only shows the server <NUM> being in communicating with a single customer device/network <NUM>, it should be appreciated that the server <NUM> may provide location information for PLDs <NUM> to a plurality of different customer devices and/or networks <NUM> and such information may be exposed to the different customer's via a different customer portal <NUM> or via a common customer portal <NUM>.

In some embodiments, the server <NUM> utilizes the tracking application <NUM> to develop one or more tracking reports that can be delivered to the customer device/network <NUM> via the customer portal <NUM>. In some embodiments, the tracking report generated by the tracking application <NUM> may encapsulate tracking data (e.g., data broadcast by PLD <NUM> over communication channel <NUM> and received at the tracking node <NUM>) with other metadata about each event and tracking node <NUM> itself. In some embodiments, the reports allow flexible grouping of data from multiple events as well as mixing data coming from different sources (e.g. genuine or verified PLDs <NUM> as well as generic or non-genuine PLDs <NUM>). The report may also be flexible in that it is not required to fix the actual coding of the tracking report and key for grouping of individual events because it will depend on many factors, mainly capabilities of transport network between tracking nodes <NUM> and backend tracking application <NUM>. In some embodiments, an ASN. <NUM> scheme can be used in which each object is described, thereby allowing almost limitless structuring but for restricted networks with small throughput. In other embodiments, it may be possible to achieve a more efficient packet implementation with static structure and fixed fields' lengths. As a non-limiting example, the report generated by the tracking application <NUM> may include a report header that includes data such as a data structure version identifier, a tracking node identifier, and a report generation sequence number (e.g., timestamp or simple counter). The report may further include report data that includes event information (e.g., a description of event type, event data specific for a given type, a measured strength of the event, event time, etc.). The event type may include a description of whether the tracking node <NUM> received information from a genuine/authentic PLD <NUM> or a generic PLD. The event data specific for a given type may include a payload of the packets received at the tracking node <NUM> (e.g., Bluetooth smart packet payload, MAC address of the PLD <NUM>, etc.). The measured strength of the event may include an RSSI value for the communication channel <NUM>, an angle of arrival information (for further refinement to the location determination), time of flight information, etc.). The event time may include both an event timestamp measured at the PLD <NUM> and/or at the tracking node <NUM>. The report may include data for up to N events where N is an integer value greater than or equal to one.

As will be discussed in further detail herein, it may be desirable to employ an anonymization mechanism to protect data in the PLDs <NUM>, the readers <NUM>, and holders thereof. The anonymization mechanism may be based on a notion that each broadcast from a particular PLD <NUM> should be different and there should be no discernible or visible pattern which could link any two or more different broadcasts to one another (e.g., they broadcasts look completely random). This ultimately may require randomization of the PLD's <NUM> MAC address which is used in certain packet types communicated to the reader <NUM>. As a more specific, but non-limiting, example the PLDs <NUM> may correspond to Bluetooth-enabled devices and there may be a randomization of Bluetooth Smart Advertising Addresses by the PLDs <NUM>, which are used in ADV_IND packets. It should be appreciated, however, that other types of PLDs <NUM> may be employed and different addresses or identification information for those PLDs <NUM> may be randomized or partially randomized to preserve a particular amount of anonymity.

With reference to <FIG>, additional details of a reader <NUM> will be described in accordance with at least some embodiments of the present disclosure. The reader <NUM> is shown to include computer memory <NUM> that stores one or more Operating Systems (O/S) <NUM> and a location application <NUM>, among other items. The reader <NUM> is also shown to include a processor <NUM>, one or more drivers <NUM>, a user interface <NUM>, a credential interface <NUM>, a network interface <NUM>, and a power module <NUM>.

The memory <NUM> may correspond to any type of non-transitory computer-readable medium. In some embodiments, the memory <NUM> may comprise volatile or nonvolatile memory and a controller for the same. Non-limiting examples of memory <NUM> that may be utilized in the reader <NUM> include RAM, ROM, buffer memory, flash memory, solid-state memory, or variants thereof. Any of these memory types may be considered non-transitory computer memory devices even though the data stored thereby can be changed one or more times.

The O/S <NUM> may correspond to one or multiple operating systems. The nature of the O/S <NUM> may depend upon the hardware of the reader <NUM> and the form factor of the reader <NUM>. The O/S <NUM> may be viewed as an application stored in memory <NUM> that is processor-executable. The O/S <NUM> is a particular type of general-purpose application that enables other applications stored in memory <NUM> (e.g., the location application <NUM>) to leverage the various hardware components and driver(s) <NUM> of the reader <NUM>. In some embodiments, the O/S <NUM> may comprise one or more APIs that facilitate an application's interaction with certain hardware components of the reader <NUM>. Furthermore, the O/S <NUM> may provide a mechanism for viewing and accessing the various applications stored in memory <NUM> and other data stored in memory <NUM>.

The location application <NUM> may correspond to one example or a portion of a tracking node <NUM> as shown in <FIG>. In particular, a location application <NUM> may correspond to a portion of instructions stored in memory <NUM> that enables the reader <NUM> to execute the functions of the tracking node <NUM> as discussed herein. Even more specifically, the location application <NUM> (or tracking node <NUM>) can utilize a real identity of a PLD <NUM> (as received via a communication channel <NUM>) in connection with providing one or more services to a user of the reader <NUM>. The application <NUM>, in some embodiments, may accesses a Proximity Location Device (PLD) Identity Component (PIC) to determine the real identity based on a pseudo anonymous response received from the PLD <NUM>, where the pseudo anonymous response does not expose the real identity to applications which do not have access to the PIC.

The processor <NUM> may correspond to one or many microprocessors that are contained within the housing of the reader <NUM> with the memory <NUM>. In some embodiments, the processor <NUM> incorporates the functions of the user device's <NUM> Central Processing Unit (CPU) on a single Integrated Circuit (IC) or a few IC chips. The processor <NUM> may be a multipurpose, programmable device that accepts digital data as input, processes the digital data according to instructions stored in its internal memory, and provides results as output. The processor <NUM> implement sequential digital logic as it has internal memory. As with most known microprocessors, the processor <NUM> may operate on numbers and symbols represented in the binary numeral system.

The driver(s) <NUM> may correspond to hardware, software, and/or controllers that provide specific instructions to hardware components of the reader <NUM>, thereby facilitating their operation. For instance, the user interface <NUM>, credential interface <NUM>, and network interface <NUM>, may each have a dedicated driver <NUM> that provides appropriate control signals to effect their operation. The driver(s) <NUM> may also comprise the software or logic circuits that ensure the various hardware components are controlled appropriately and in accordance with desired protocols. For instance, the driver <NUM> of the credential interface <NUM> may be adapted to ensure that the credential interface <NUM> follows the appropriate proximity-based protocols (e.g., BLE, NFC, Infrared, Ultrasonic, IEEE <NUM>. 11N, etc.) such that the credential interface <NUM> can exchange communications with the credential <NUM>. Likewise, the driver <NUM> of the network interface <NUM> may be adapted to ensure that the network interface <NUM> follows the appropriate network communication protocols (e.g., TCP/IP (at one or more layers in the OSI model), UDP, RTP, GSM, LTE, Wi-Fi, etc.) such that the network interface <NUM> can exchange communications via the communication network <NUM>. As can be appreciated, the driver(s) <NUM> may also be configured to control wired hardware components (e.g., a USB driver, an Ethernet driver, etc.).

As mentioned above, the user interface <NUM> may comprise one or more user input devices and/or one or more user output devices. Examples of suitable user input devices that may be included in the user interface <NUM> include, without limitation, buttons, keyboards, mouse, pen, camera, microphone, etc. Examples of suitable user output devices that may be included in the user interface <NUM> include, without limitation, display screens, lights, speakers, etc. It should be appreciated that the user interface <NUM> may also include a combined user input and user output device, such as a touch-sensitive display or the like.

The credential interface <NUM> may correspond to the hardware that facilitates communications with the credential <NUM> for the reader <NUM>. The credential interface <NUM> may include a Bluetooth interface (e.g., antenna and associated circuitry), a Wi-Fi/<NUM>. 11N interface (e.g., an antenna and associated circuitry), an NFC interface (e.g., an antenna and associated circuitry), an Infrared interface (e.g., LED, photodiode, and associated circuitry), and/or an Ultrasonic interface (e.g., speaker, microphone, and associated circuitry). In some embodiments, the credential interface <NUM> is specifically provided to facilitate proximity-based communications with a credential <NUM> via communication channel <NUM> or multiple communication channels <NUM>.

The network interface <NUM> may comprise hardware that facilitates communications with other communication devices over the communication network <NUM>. As mentioned above, the network interface <NUM> may include an Ethernet port, a Wi-Fi card, a Network Interface Card (NIC), a cellular interface (e.g., antenna, filters, and associated circuitry), or the like. The network interface <NUM> may be configured to facilitate a connection between the reader <NUM> and the communication network <NUM> and may further be configured to encode and decode communications (e.g., packets) according to a protocol utilized by the communication network <NUM>.

The power module <NUM> may include a built-in power supply (e.g., battery) and/or a power converter that facilitates the conversion of externally-supplied AC power into DC power that is used to power the various components of the reader <NUM>. In some embodiments, the power module <NUM> may also include some implementation of surge protection circuitry to protect the components of the reader <NUM> from power surges.

With reference now to <FIG>, various different identity retrieval scenarios will be described in accordance with at least some embodiments of the present disclosure. The various scenarios are not intended to limit the scope of the present disclosure, but rather are meant to show different modifications to the reader <NUM> and/or server <NUM> that can be made to carry out the pseudo anonymous location tracking functions described herein. Any combination of scenarios can be utilized, including those combinations neither depicted nor described herein.

With reference initially to <FIG>, a first identity-retrieval scenario is depicted. In this first scenario, the application <NUM> may perform an in-application calling of a PLD Identity Component (PIC) <NUM> to retrieve/determine the actual identity of a read PLD <NUM> (e.g., real Identity (I)). In particular, the application a PIC304 (e.g., in the form of a software library) that contains a function to retrieve the real PLD identity (I). In some embodiments, the PIC <NUM> could compute the real PLD identity (I) cryptographically.

One example of how the PIC <NUM> could compute the real PLD identity (I) of the PLD <NUM> cryptographically is as follows:.

In another example, and as shown in <FIG>, the application <NUM> may perform an in-application calling of the PIC <NUM> and the actual identity of the read PLD (e.g., real Identity (I)) may be obtained by reconnecting to the PLD <NUM>. In some embodiments, the application <NUM> will have an embedded PIC <NUM> (e.g., a software library) that contains a function to retrieve the real Identity (I). The PIC <NUM> can be configured to compute the real Identity (I) cryptographically or it could be configured to reconnect to the PLD <NUM> to retrieve the real Identity (I).

One example of how the PIC <NUM> could obtain the real PLD identity (I) by reconnecting with the PLD <NUM> is as follows:.

In another example, and as shown in <FIG>, a temporary PLD access token may be utilized to secure the real identity (I). Specifically, in a scenario similar to the PLD reconnection scenario described above, a service <NUM> is used to retrieve an access ticket that can be presented to the PLD <NUM> to retrieve the identity instead of storing a secret key locally at the application <NUM>.

An example of how such an access token could be used is as follows:.

It should be appreciated that other protection mechanisms to protect the real identity (I) in the response to the PIC <NUM> can be envisaged such as the creation of an ephemeral public/ private keypair and the PIC <NUM> passing the public key to the PLD <NUM> in the request (R) and the PLD <NUM> encrypting the real identity (I) with the public part of the ephemeral keypair.

In yet another example, a service-based identity retrieval mechanism can be utilized whereby the application <NUM> can call a cloud service to retrieve the identity of the PLD <NUM>. Specifically, the PLD <NUM> may broadcast a nonce (N) and an encrypted identifier (R=Nlenc(S,IIN)). The encryption will occur using a symmetric key with small block cypher length and the same key is stored securely in the PIC <NUM> (where the PIC is maintained in the cloud-based service).

Employing any of the mechanisms described above, the following advantages can be realized:.

With reference now to <FIG>, a method of obtaining and using real identity information will be described in accordance with at least some embodiments of the present disclosure. The method begins when a communication channel <NUM> is established between a PLD <NUM> and a reader <NUM> (step <NUM>). The communication channel <NUM> can be a contactless or contact-based communication channel without departing from the scope of the present disclosure. In some embodiments, the communication channel <NUM> is established at least in part by virtue of the PLD <NUM> being placed within a read range of the reader <NUM>.

The method continues with the PLD <NUM> generating at least one message that is transmitted to the reader <NUM> via the communication channel <NUM> (step <NUM>). The formatting of the message may depend upon the protocol of the communication channel <NUM>. For instance, if the communication channel <NUM> corresponds to a WiFi channel, then communication packets formatted according to <NUM>. 11N standards may be utilized. As another example, if the communication channel <NUM> corresponds to an NFC channel, then one or more messages formatted according to NDEF formatting standards may be utilized.

Regardless of the protocol used to exchange messages between the PLD <NUM> and the reader <NUM>, when the reader receives the message(s) from the PLD <NUM>, the reader <NUM> may utilize the PIC <NUM> to extract at least one random value from the message and an encrypted version of the real identity from the message (if such a scenario is being utilized) (step <NUM>). The PIC <NUM> may be deployed locally at the application <NUM> of the reader <NUM> or the reader <NUM> may leverage a remotely-located PIC <NUM> (e.g., a PIC <NUM> of a trusted service).

The PIC <NUM> utilizes the extracted information (e.g., location and/or anonymized identity information) to determine a real identity of the PLD <NUM> (assuming the PLD <NUM> corresponds to an authentic/genuine PLD <NUM> programmed to operate according to the defined identity-retrieval scenario being deployed) (step <NUM>). This identity information can then be bound to the location information also obtained from the PLD <NUM> at the tracking application <NUM> to update its location report(s) based on the most recent interaction event between the PLD <NUM> and the reader <NUM> (step <NUM>). This updating further allows the tracking application <NUM> to determine a current location of the identified PLD <NUM>, update its location report, and possibly communicate some or all of that location information (e.g., location report) to a customer device/network <NUM>. In some embodiments, the customer at the customer device/network <NUM> can use the real identity information and/or location information provided by the tracking application <NUM> to implement a location-based service or set of services (consistent with preferences of the customer and/or holder of the reader <NUM>).

With reference now to <FIG>, two data structures <NUM>, <NUM> that can be used to deliver information from a PLD <NUM> to a reader <NUM> will be described in accordance with at least some embodiments of the present disclosure. Although <FIG> depict certain fields contained within the data structures <NUM>, <NUM> and a particular organization of those fields, it should be appreciated that the data structures <NUM>, <NUM> depicted and described herein are illustrative and are not intended to limit the scope of the present disclosure. Indeed, any message format and data structure usable with that message format can be used to deliver some, all, or similar types of data between a PLD <NUM> and a reader <NUM> (or between a reader <NUM> and server <NUM>). Furthermore, the sizes of the various fields are for illustrative purposes and should not be construed as limiting the scope of the present disclosure.

With reference initially to <FIG>, a first data structure <NUM> is shown to include a payload <NUM> having one or more flags <NUM> and manufacturer specific data <NUM>. The manufacturer specific data <NUM> can be further partitioned to include a length and tag field <NUM>, a manufacturer identification field <NUM>, and a tracking data field <NUM>. The tracking data field <NUM> may further contain a structure identifier <NUM>, a device identifier <NUM>, additional tracking data <NUM>, and a packet identifier <NUM>.

This data structure <NUM>, in some embodiments, offers better tracking capabilities than static iBeacon structures because it is capable of changing dynamically with every broadcast event. In addition, it may also provide space for additional data which can be used by the tracking application <NUM> to report tracking events of different types. The data structure <NUM> does not require any specific computing power on the PLD <NUM> but, as consequence, it may not be secured against unwanted tracking or re-play attacks.

In some embodiments, the data structure <NUM> can be used to maintain full interoperability with Bluetooth Smart specifications thereby allowing a wide range of supported devices (e.g., PLDs <NUM>). Therefore, an applicative data space within Bluetooth Smart advertising packets can be used and a proprietary data structure <NUM> can be defined on top of the advertising element as defined in Bluetooth Smart Generally Accepted Practices (GAP). This provides a theoretical space of <NUM> (payload <NUM> of advertising packet) - <NUM> ("Flags" AD element <NUM> which is mandatory for Bluetooth Smart advertisement) - <NUM> (AD element tag and length <NUM>) - <NUM> (manufacturer ID <NUM>) = <NUM> bytes. To accommodate an anonymity requirement, any common symmetric cryptography schemes can be used and one more bytes of the data structure <NUM> can be reserved for anonymized structure <NUM>.

In some embodiments, most of the fields of the data structure <NUM> may be formatted according to a predetermined standard (e.g., Bluetooth). However, the tracking data field <NUM> may be specifically formatted to preserve anonymity within the communication system <NUM>. In some embodiments, the structure identification field <NUM> may correspond to a field of a particular size (e.g., <NUM> bits) that provides space of <NUM> values which can clearly identify coding of the additional tracking data field <NUM>. In some embodiments, only one value may be defined as "<NUM>" (= 0x80) which corresponds to a random value (e.g., = "Additional Tracking Data" field <NUM> should be ignored on the side of broadcast receiver/reader <NUM>). All other values (ranges "<NUM>" to "<NUM>" and "<NUM>" to "<NUM>") may be reserved for future use.

The device identification field <NUM> may correspond to a field of a predetermined size (e.g., <NUM> bits). The full range of the field <NUM> (e.g., <NUM> to <NUM>,<NUM>) can be used for storing a unique tracking device identifier, which may correspond to particular field in tracking report generated by the tracking application <NUM>. To maintain compatibility with static iBeacon systems, some embodiments of the present disclosure may allocate the range <NUM> to <NUM>,<NUM> for these purposes. To further support tracking event type A, there may be an option to assign another part of this range for tracking nodes <NUM>. However, some embodiments could be agnostic to broadcasting from tracking nodes <NUM> and PLDs <NUM> so this is rather a suggestion than an ultimate rule.

The additional tracking data field <NUM> may correspond to a data field of a predetermined length (e.g., <NUM> bytes) that is reserved for future use (e.g., typically to facilitate data tracking from tracking events of type A or C). Until such use, the additional tracking data <NUM> may be used to store random data (e.g., corresponds to "Structure ID" field value "<NUM>") meaning that the PLD <NUM> broadcasting device should generate random data (e.g., to allow better identification of the same broadcasts received by multiple reader <NUM>) but in fact it can use any static value (such as 0x00. <NUM>) because this field is not interpreted by the backend location application <NUM>.

The packet identification field <NUM> may correspond to a data field of a predetermined length (e.g., <NUM> bytes) that is used to store information that identifies packets transmitted from a PLD <NUM> to a reader <NUM>. In some embodiments, the values contained in the packet identification field <NUM> differ for each broadcasted packet during a life-time of PLD <NUM> in the system <NUM>. The data contained in the field <NUM> could be either a simple sequence counter or a timestamp (e.g., in case that PLD <NUM> has autonomous RTC synchronized with the rest of tracking backend).

With reference now to <FIG>, additional details of a data structure <NUM> which is similar to data structure <NUM>, but with use of a block cipher <NUM> and anonymity key <NUM> will be described in accordance with at least some embodiments of the present disclosure. The anonymization mechanism described herein (e.g., cipher <NUM> and key <NUM>) is just extending properties of the data structure <NUM>. The anonymization mechanism described herein is based on a simple requirement that each broadcast from a particular PLD <NUM> should be different and there should be no visible pattern which could link any of them together (e.g., they look completely "random"). This ultimately requires a randomization of a Bluetooth Smart Advertising Address (e.g., MAC) which is used in ADV_IND packets. This is very low level parameter of Bluetooth Smart stack and it can be challenging to randomize this value on a target device. If it is not achieved (or it is done just partially - e.g. MAC address is changed every X hours) it significantly lowers the anonymization effect at the application layer.

The anonymization may be applied over the whole tracking data field <NUM> or a portion of the tracking data field <NUM> (e.g., less than all of the tracking data field <NUM>, such as not encrypting the packet identification field). It may also be possible to apply two (or more) different ciphering/encryption methods to different portions of the tracking data field <NUM>. For example, one portion of the tracking data field <NUM> may have a first cipher/key applied thereto whereas a second portion of the tracking data field <NUM> may have a second cipher/key applied thereto. To be able to identify the anonymized tracking data field <NUM> from any other data contained inside manufacturer specific data field <NUM>, a length (e.g., <NUM> bytes) may be reserved for anonymized tracking data <NUM>. If any other application wants to use this element with this length it can cause collisions and may not be compatible with the tracking solution described herein.

The ciphering scheme <NUM> used may depend upon the capabilities of the PLD <NUM> and/or reader <NUM>. In particular, the performance should match timing and power efficiency criteria or there might be a lack of hardware acceleration. In some embodiments, a 3DES-CBC scheme <NUM> (e.g., <NUM>-bit or <NUM>-bit key <NUM>) can be used. In some embodiments, AES FFX may be used as the cipher <NUM> with one or multiple <NUM> bit-keys <NUM>.

Claim 1:
A system for pseudonymous identification comprising:
- a pseudonymous proximity location device (<NUM>);
- a reading device (<NUM>) comprising an application (<NUM>) stored thereon;
- a server (<NUM>) comprising a tracking application (<NUM>);
wherein the pseudonymous proximity location device (<NUM>) is configured for allowing the application (<NUM>), that utilizes a real identity of a proximity location device (<NUM>) in connection with providing one or more services to a user of the reading device (<NUM>), to interact with the proximity location device (<NUM>) to determine that the reading device (<NUM>) and a specific application running on the reading device (<NUM>) are at a specific physical location,
the pseudonymous proximity location device (<NUM>) comprising:
a communication interface configured to enable communications with the reading device (<NUM>) via a proximity-based communication channel (<NUM>), wherein the proximity-based communication channel (<NUM>) is only established when the proximity location device (<NUM>) and the reading device (<NUM>) are within a predetermined distance of one another, wherein event information about an interaction event between the proximity location device (<NUM>) and the reading device (<NUM>) is included in a report generated by a tracking application (<NUM>) on the server (<NUM>) comprising a strength of the event, wherein the measured strength of the event includes an angle of arrival information;
a microprocessor; and
computer memory including the following stored thereon:
a real identifier that is uniquely associated with the pseudonymous proximity location device; and
microprocessor-executable instructions configured to generate a first message that is transmitted via the communication interface to the reading device (<NUM>), wherein the first message comprises a transmitted identifier that reveals the real identifier to an authorized reading device while simultaneously concealing the real identifier from a non-authorized reading device,
wherein the application (<NUM>) accesses a Proximity Location Device, PLD, Identity Component, PIC, (<NUM>) to determine the real identifier based on the first message received from the proximity location device (<NUM>),
by extracting from the first message at least one extracted random nonce value and an extracted encrypted real identifier, wherein the first message does not expose the real identifier to applications which do not have access to the PIC (<NUM>).