Images

Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
  • H04L9/0872—Generation of secret information including derivation or calculation of cryptographic keys or passwords using geo-location information, e.g. location data, time, relative position or proximity to other entities
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Definitions

• the present invention relates to data analytics, and more specifically, to privacy enhanced spatial and temporal analytics.
• Some analytics associate entities (such as ships) with their features (such as gross tonnage) and feature elements (such as unit of measure and gross weight).
• Spatial and temporal analytics further allow entities to be associated with space and time data.
• Some spatial and temporal analytics use an entity feature known as a SpaceTimeBox (STB).
• An STB reflects a spatial region and a time interval, at a specific granularity. Any event, that is, any point in spacetime specified by its time and place, can be assigned to at least one STB.
• an entity such as a ship
• other entities can be compared with the entity and be associated with that entity's spatial location at a certain time at a granularity defined by the STB's granularity.
• the STB granularity is configurable, as are parameters that allow for filtering of STBs in various conditions.
• the STB functionality provides spatial and temporal reasoning capabilities for advanced entity resolution, relationship awareness, and insight/relevance detection.
• Motion processing typically relies on quantization of space and time, thus making STBs useful for this purpose as well.
• the motion of entities with respect to STBs can be used to detect specific entity behavior, in real time, which can be published to downstream analytic applications.
• the activities of entities over time as quantized into intervals also can be used to detect specific entity behavior that also can be published to downstream analytic applications.
• LBS Location Based Services
• challenges can arise. For example, two different organizations or two different groups within the same organization may each have space and/or time data that they do not want to share freely with each other.
• An anonymized key is generated.
• the anonymized key represents a spacetime region with which an entity is associated.
• the spacetime region represents a spatial region and a time interval.
• the entity is associated with the spacetime region based on spacetime coordinates for the entity
• FIG. 1 is a schematic block diagram showing a system for motion processing, in accordance with one embodiment.
• FIG. 2 is a schematic block diagram showing a computing node ( 10 ) of FIG. 1 , in accordance with one embodiment.
• FIG. 3 is a flowchart showing a process for creating an anonymized STB key, in accordance with one embodiment.
• FIG. 4 is a schematic view of a threshold percentage selection for including items in more than one STB using a circle of inclusion, in accordance with one embodiment.
• FIG. 5 is a schematic view of a threshold percentage selection for including items in more than one STB using sampling points, in accordance with one embodiment.
• FIG. 6 is a schematic view showing STBs of different granularities, in accordance with one embodiment.
• FIG. 7 is a schematic view of how events expire at hangout interval boundaries, in accordance with one embodiment.
• FIG. 8 is a schematic view of how hangouts are detected in accordance with a user-supplied Qualifying Timebox Percentage, in accordance with one embodiment.
• FIG. 9 is a schematic illustration of an entity tracking skiplist, in accordance with one embodiment.
• FIG. 10 is a flowchart showing the operation of a first thread in a multi-threaded hangout detector in accordance with one embodiment.
• FIG. 11 is a flowchart showing the operation of a second thread in a multi-threaded hangout detector in accordance with one embodiment
• the various embodiments described herein pertain to real-time analysis of events.
• analytics engines can associate entities with events via STBs, each of which reflects both a spatial region and a time interval.
• STBs each of which reflects both a spatial region and a time interval.
• the embodiments described herein address issues that may occur when entity data are collected and associated with STBs, as well as how the data can be subsequently processed and shared anonymously between parties to ensure the privacy of the data.
• STBs can be created by STB calculator routines implemented, for example, as a plugin module in an analytics engine, based on an event (i.e., an entity being observed at a particular geospatial location and a particular time), by using a geohash public-domain geospatial-quantizing algorithm, along with a simple time-quantizing algorithm.
• the routines concatenate the algorithms' outputs to form an STB key for the event, which can subsequently be anonymized using various anonymization techniques that will be described in further detail below.
• the STB key can be specific to a spatial region and a time interval containing the event.
• an analytics engine can compare the two STB keys to determine whether the entities are in the same generalized region of space and time, whether they are in adjacent generalized regions of space and time, or otherwise.
• the analytics engine can use this information to determine whether entities are related by their locations. Given sufficient granularity, the analytics engine also can use this information, along with other information about the entities, to determine whether the entities are one and the same.
• the flexible configurability of time and space generalization allows for outputting of multiple concurrent keys for use together with exact-match comparison of STBs to enable such things as advanced entity resolution, relationship awareness, and insight/relevance detection.
• the concurrent keys can reflect STBs of “tighter” and “looser” granularities, for a single observed entity.
• the STB comparison enables detection of, among other things, “hang outs” in a certain set of STBs.
• a single STB may at any given time contain zero, few, or many observed entities.
• the various embodiments of the invention allow rapid identification of any entities that are newly associated with an STB, and further processing of these identified entities.
• anonymized STBs allow multiple parties to take records representing entities that have space and time attributes, to generalize the entities' space and time attributes into STBs, to anonymize the STBs into anonymized STB keys (i.e., strings that represent the anonymized STBs)—also referred to as “anonymized keys” herein—and only then to exchange the anonymized STB keys.
• anonymized STB keys i.e., strings that represent the anonymized STBs
• STBs can be used, in order to enhance the understanding of the general concepts of the various embodiments.
• This example describes a business process, but as the skilled person realizes, STBs can be used in many other types of processes as well.
• a wireless communications provider possesses geospatial data about where its subscribers' mobile devices are in space and time.
• a sandwich shop franchise may want to improve business in its underperforming shops, but may not want to reveal the locations of those underperforming shops to the wireless communications provider. Therefore, the sandwich shop franchise creates 50 STBs in the form of anonymized STB keys representing shop locations on particular days and times. Since the STB keys are anonymized, they can be shared freely with the wireless communications provider without revealing the actual days and times.
• aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
• the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
• a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
• a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
• a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
• a computer readable signal medium may be any computer medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
• Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
• Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
• the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
• the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
• LAN local area network
• WAN wide area network
• Internet Service Provider an Internet Service Provider
• These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
• the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowcharts and/or block diagram block or blocks.
• FIG. 1 shows a schematic of an example of a system ( 100 ) used for motion processing, in accordance with one embodiment.
• the system ( 100 ) includes one or more computing nodes ( 10 ), which collaborate as will be described in further detail below to process data received in inbound messages from one or more data sources ( 102 ).
• Each node ( 10 ) can be an independent computer or processor that contributes to a larger task of performing the techniques described herein, for a given set of entities and events specified by the inbound messages from the data source(s) ( 102 ).
• AIS Automatic Identification System
• VTS vessel traffic services
• the nodes ( 10 ) are connected to a shared Relational Database Management System (RDBMS) ( 104 ), which can collect data from the nodes ( 10 ) and provide data to the nodes ( 10 ).
• RDBMS Relational Database Management System
• the shared RDBMS ( 104 ) is only one example of a suitable basis for analytics processing and/or motion processing and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention described herein.
• the RDBMS ( 104 ) can contain, for example, data about data sources, observations, entities, features, and elements.
• a data source is usually a database table, query or extract from a system of record. An observation occurs when a record is added, changed, or deleted in a data source.
• An entity is usually a particular type of record in a database table like a customer master record or a transaction record.
• a feature is a particular piece of information about an entity. Sometimes a table contains multiple fields that in fact describe the same thing. A feature may be represented by a group of fields that all describe the same thing. Many fields represent features all by themselves, but some can be grouped into a higher level. For instance, names and mailing addresses usually contain multiple fields or elements. An element is a further breakdown of a feature, such as the postal code that forms part of a typical address, and is usually represented by a field in a table.
• the computing nodes ( 10 ) can work together to compare entities and features against each other and to determine entities sharing features, whether these features be anonymized STB keys, or otherwise.
• the entities sharing features can be provided in an outbound message to one or more data destination(s) ( 106 ), which can be defined by a user.
• a data destination includes an analytics engine (as its data supply).
• motion processing is merely one example of an area in which the techniques presented herein may be used, and that persons having ordinary skill in the art can easily come up with other alternatives of data destinations that are suitable for use.
• other data destinations can include machine learning systems, automated navigation advisers for travelers (like the dashboard-mounted kind, or for hikers), systems for plotting the motion of astronomical objects, and systems for the study of particle physics, just to mention a few examples.
• RDBMS 104
• data destination just to mention a few examples.
• FIG. 1 in a real-life scenario, there may be multiple data sources ( 102 ), multiple (or zero) RDBMSs ( 104 ) and multiple data destinations ( 106 ) included in the motion processing system ( 100 ).
• FIG. 2 shows a schematic example of a computing node ( 10 ).
• the computing node ( 10 ) is only one example of a suitable computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention described herein. Regardless, the computing node ( 10 ) is capable of being implemented and/or performing any of the functionality set forth herein.
• a computing device ( 12 ) In the computing node ( 10 ) there is a computing device ( 12 ).
• Examples of well-known computing devices include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed computing environments that include any of the above systems or devices, and the like.
• the computing device ( 12 ) may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system.
• program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types.
• the computing device ( 12 ) may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network.
• program modules may be located in both local and remote computer system storage media including memory storage devices.
• the computing device ( 12 ) in the computing node ( 10 ) is shown in the form of a general-purpose computing device.
• the components of the computing device ( 12 ) may include, but are not limited to, one or more processors or processing units ( 16 ), a system memory ( 28 ), and a bus ( 18 ) that couples various system components including system memory ( 28 ) to the processor ( 16 ).
• the bus ( 18 ) represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.
• bus architectures include Industry Standard Architecture (ISA) bus, Peripheral Component Interconnect (PCI) bus, PCI Express bus, InfiniBand bus, HyperTransport bus, and Serial ATA (SATA) bus.
• the computing device ( 12 ) typically includes a variety of computer system readable media. Such media may be any available media that is accessible by the computing device ( 12 ), and it includes both volatile and non-volatile media, and removable and non-removable media.
• the system memory ( 28 ) can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and/or cache memory 32 .
• the computing device ( 12 ) may further include other removable/non-removable, volatile/non-volatile computer system storage media.
• the storage system ( 34 ) can be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown and typically called a “hard drive”).
• a magnetic disk drive for reading from and writing to a removable, non-volatile storage medium (e.g., a “USB flash drive”)
• an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media
• each can be connected to the bus ( 18 ) by one or more data media interfaces.
• the memory ( 28 ) may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.
• the program/utility ( 40 ), having a set (at least one) of program modules ( 42 ), may be stored in the memory ( 28 ) by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment.
• the program modules ( 42 ) generally carry out the functions and/or methodologies of embodiments of the invention as described herein.
• the computing device ( 12 ) may also communicate with one or more external devices ( 14 ) such as a keyboard, a pointing device, a display 24 , etc.; one or more devices that enable a user to interact with the computing device ( 12 ); and/or any devices (e.g., network card, modem, etc.) that enable the computing device ( 12 ) to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces ( 22 ). Still yet, the computing device ( 12 ) can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via the network adapter ( 20 ).
• LAN local area network
• WAN wide area network
• public network e.g., the Internet
• the network adapter ( 20 ) communicates with the other components of the computing device ( 12 ) via the bus ( 18 ).
• bus ( 18 ) It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server ( 12 ). Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.
• An STB can be thought of, in a general sense, as having a number of dimensions, which each represent a specific feature.
• the dimensions can be spatial (e.g.
• An STB can represent a two-dimensional spacetime region (i.e., a surface region and a time interval), a three-dimensional spacetime region (i.e., a space region and a time interval), or really any n-dimensional spacetime region (e.g., the combination of a space region, time interval and a radio frequency range).
• an STB will be used in the examples below as reflecting a geospatial region and time interval, at a specific granularity.
• the “granularity” of the STBs can be configured, for example, by specifying a precision for each dimension of the STB. As will be described in further detail below, the precision for each dimension can be determined, at least in part, by a user, and/or by the “granularity” of the data associated with the entity.
• an analytics engine may be used as a data destination ( 106 ) for the system ( 100 ) as shown.
• many analytics engines are oriented toward standardized message format input and output, such as XML (eXtensible Markup Language). For that reason, such engines are also well suited for exact-match comparisons of alphanumeric strings.
• the public-domain geohash algorithm can be used to compute alphanumeric strings representing a given geospatial region (see http://en.wikipedia.org/wiki/Geohash). Though this algorithm may perform adequately, it can be insufficient for the temporal representation needed during real-time analysis of geospatial events. Thus, in accordance with one aspect of the invention, improved high-performance time-quantizing techniques are provided that give a flexible approach to time quantization and that enhance the existing public-domain geohash algorithm.
• a bit vector can be used to represent a geospatial region and/or a time interval. Storing geospatial regions and time intervals as bit vectors can consume less space, and thus can better contribute to scalability, than storing alphanumeric strings. It should be noted, however, that the bit vectors can represent any type of spatial regions, and that they do not necessarily need to be geospatial.
• routines implemented to calculate STBs can create one or more STBs for a geospatial event by using the geohash public-domain geospatial-quantizing algorithm, along with a simple time-quantizing algorithm.
• the algorithms' outputs can be programmatically concatenated to form one or more STB keys which can then be anonymized per inventive arrangements as described elsewhere herein.
• FIG. 3 shows a process in accordance with one embodiment for creating an anonymized STB key for an entity.
• an entity that is observed at a given time is associated with an STB (i.e., a spacetime region), based on the entity's latitude and longitude coordinates and a datetime value (i.e., the spacetime coordinates for the entity) (step 302 ).
• the key representing the STB is retrieved (step 304 ).
• the keys will be described in further detail below, but in essence a key is an alphanumeric string that represents a spatial area and a time interval that is described by the STB. Thus, two entities that reside in the same STB during the same time interval will have comparable keys.
• a user can configure the string length to set a geospatial granularity of STBs.
• a user also can configure a single input set of coordinates, corresponding to a single event, to be assigned to multiple STBs of varying geospatial granularity. This will be described in further detail below.
• the key representing the STB is anonymized (step 306 ), which ends the process.
• the anonymization allows an analytics engine to track and store entities' space and time data in a form that safeguards the data from unwanted disclosure while keeping the data recoverable and/or useful for advanced entity resolution, relationship awareness, and insight/relevance detection.
• anonymization can be done through one or more cryptographic algorithms, which may include using secret keys for protection and confidentiality.
• some embodiments use irreversible cryptographic algorithms (e.g., one-way functions), where the secret key is a “salt” value.
• Other embodiments use a reversible cryptographic algorithm (e.g., encryption or encoding), where the secret key is the decryption key necessary to reveal the owner of the data record.
• anonymization data is not limited to the specific examples provided herein. Many variations of anonymization can be envisioned by those of ordinary skill in the art.
• the STB functionality described herein enables an analytics engine to accept and respond to STB creation requests in the form of XML message structures.
• the geospatial data sent into the analytics engine can be extended by an analytics plugin module, or by a standalone executable module, to include the configured STBs for observed spacetime coordinates.
• These anonymized STB keys then become available for such things as advanced entity resolution, relationship awareness, and insight/relevance detection.
• a user can work with a predefined XML message hierarchy for specifying observations, observed entities, entity features, and feature elements.
• a user can send the analytics engine a set of latitude, longitude, and time values as feature elements within a “GEO_LOC” feature.
• the following is an example of a complete message specifying an observation of an entity that has an associated latitude, longitude, and time.
• the STB calculator can create multiple STBs and keys in response to a single input geospatial event.
• the STBs can reflect regions and time intervals at different granularities, all encompassing the event.
• the following is an example of a complete message representing a set of typical STBs encompassing the event reflected by the latitude, longitude, and time values provided in the sample XML above.
• ⁇ EFEAT_RETURN> Return document tag ⁇ OBS_FEAT> Observed feature tag ⁇ FTYPE_CODE>STB_KEY ⁇ /FTYPE_CODE> Feature type code for data describing an STB ⁇ UTYPE_CODE>PRESENCE ⁇ /UTYPE_CODE> ⁇ USED_FROM_DT>1999-12-31 ⁇ /USED_FROM_DT> ⁇ USED_THRU_DT>2000-01-01 ⁇ /USED_THRU_DT> ⁇ OBS_FELEM> Observed feature element ⁇ FELEM_CODE>EXPRESSION ⁇ /FELEM_CODE> Feature element code for an expressed feature ⁇ FELEM_VALUE>GR1_GH4_1DAY
• the analytics engine's standard database schema includes two tables used to configure the STB plugin module. These tables represent an STB master list stored in a “PLU_STB_MASTER” table and an STB assignment list stored in a “PLU_STB_ASSIGN” table. Together, these tables determine the set of STBs the plugin module will create for a given geospatial event.
• the PLU_STB_MASTER table contains fields with the following names, for the purpose of establishing a set of spacetime granularities for use with the plugin module.
• the PLU_STB_MASTER table defines the entire set of possible STB types that the analytics engine can track and compare using the plugin module, in accordance with one embodiment.
• the entries in the PLU_STB_MASTER table define STB types and their ranges of geospatial and time interval precisions.
• a user can specify geospatial precisions as geohash string length values indicating that generated STB keys will include 2-character to 26-character geohash values.
• a user can specify time interval precisions in units that may include milliseconds, seconds, minutes, hours, days, or years.
• a user also can specify a positive integer value ahead of the time unit specifier, to generate STBs whose time interval boundaries fall on multiples of that number in those units.
• the entries in the PLU_STB_MASTER table can be described in further detail as follows.
• STB_NAME SpaceTimeBox name: An identifier for an STB type. Typically the master list is populated with descriptive identifiers. For example, an identifier such as “GR1_GH6 — 1HOUR” depicts an STB type in grid one whose geospatial precision is a geohash value of six characters and whose time interval precision is one hour. Any events assigned to such an STB will be the same to other events occurring in the same six-character geohash region during the same hour.
• the actual names can be arbitrary, but in order to improve human readability, it may be advantageous in some embodiments to use names that describe the granularity.
• STB_GRID_ID SpaceTimeBox grid id: An identifier for a grid. Although a single grid will be most common, various embodiments can support an indefinite number of grids. The grids can be overlapping, competing, or altogether unrelated.
• STB_SPACE_ORD SpaceTimeBox geospatial ordinal: A descriptor for STB types that can be used to perform geospatial ordering. In some embodiments, all master table entries that have the same number of geohash characters have the same geospatial ordinal value.
• STB_TIME_ORD SpaceTimeBox time ordinal: A descriptor for STB types that can be used to perform temporal ordering. In some embodiments, all master table entries of the same time interval precision have the same time ordinal value.
• SPACE_FUNC Global System for Mobile communications
• SPACE_PARMS Geographical range-defining parameters: A comma-separated list defining the actual geohash precision, along with filtering parameters, associated with any STB assigned to the master list entry.
• TIME_FUNC Time interval-defining function: A function used to generate STB time intervals that can be compared.
• a “TIMEBOXER” function generates datetime intervals whose “lower” and “upper” boundaries are denoted in the form yyyy-mm-dd hh:mm:ss:uuu.
• the TIMEBOXER function elides low-order fields for time intervals of day-or-longer duration and elides microsecond fields unless these are specifically called for by the TIME_PARMS value.
• this is merely an example and that other functions also can be used.
• TIME_PARMS Time interval-defining parameters: A comma-separated list defining the actual time interval precision, along with filtering parameters, associated with any STB assigned to the master list entry.
• allowable unit-specifying strings include EVER, YEAR, MONTH, DAY, HOUR, MIN, SEC, and MS. Any time is comparable to an STB whose time unit is EVER.
• the PLU_STB_ASSIGN contains fields with the following names, for the purpose of associating input geospatial events with a subset of the possible STB types defined by the PLU_STB_MASTER table:
• the STB plugin module For each incoming event, that is, observation of an entity at a given location and time, the STB plugin module creates a set of STBs, typically one for each assignment in the assignment list.
• the STB assignment list entries designate the set of STB types to be associated with a qualifying event.
• the STB plugin module returns a set of assigned STBs according to the assignment list.
• the plugin module creates an STB for each assignment where the input XML has both DSRC_CODE and ETYPE_CODE values that match the values in an assignment list entry and where XPATH_FILTER either is empty or designates an applicable condition that is met.
• DSRC_CODE Data source code: An identifier that corresponds to an entry in a “CFG_DSRC” table and that indicates the data source for which an STB may be created. Given an input geospatial event, the plugin module generates only those STBs for which an assignment's DSRC_CODE value matches a corresponding value in the input XML document representing the event.
• ETYPE_CODE Entity type code: An identifier that corresponds to an entry in a “CFG_ETYPE” table and that indicates an entity type for which an STB may be created. Given an input geospatial event, the plugin module generates only those STBs for which an assignment's ETYPE_CODE value matches a corresponding value in the input XML document representing the event.
• STB_NAME SpaceTimeBox name: An identifier for an STB type defined in the master list. Given an input geospatial event, the plugin module can generate a set of STBs that each has unique STB types, each describing an STB at a different spacetime granularity. All of the STBs that are returned will include the given event.
• OUT_FTYPE_CODE Output feature type code: A feature type code that corresponds to an entry in a “CFG_FTYPE” table. This field designates the type of expressed (programmatically generated) feature associated with any STB assignment that is based on the assignment list entry. Its default value is STB_KEY.
• OUT_UTYPE_CODE Output usage type code: A usage type code that corresponds to an entry in a “CFG_UTYPE” table. This field designates a usage type associated with any STB assignment that is based on the assignment list entry.
• XPATH_FILTER Flexibleing string with XPath syntax: A character string describing a filter.
• the plugin module applies the filtering logic to the input XML document and accepts any filter whose syntax is in accordance with the XPath (XML Path Language) specification. In some embodiments, if this field is left empty, then no filtering is applied. Otherwise, if this field contains a valid XPath expression that evaluates to “True” for a given event, then the event is assigned to an STB of the type designated in the STB_NAME field. That assignment is then included in the resulting set of STBs generated for the event. If the XPath expression evaluates to “False” for a given event, then the designated assignment is not included in that resulting set of STBs.
• the analytics engine's standard STB construct can represent a geospatial event e.g., latitude, longitude, and time.
• a user familiar with programming can add support for other STB types by creating custom plugin modules for the analytics engine.
• a plugin module exports certain predefined functions callable by the analytics engine at runtime, including a function used to generate expressed features, such as STBs.
• an analytics engine can generate STB data for a set of spacetime coordinates.
• a user can opt to generate this data using an executable module that can be provided as part of an installed analytics engine file set or separately.
• executable module refers to a typical software application, or applet, e.g. for Windows, Linux, or Solaris, implementable in native, Java, or managed code, or as a script, which can run entirely on its own and produce STB data for any purpose whatsoever.
• This executable module can be invoked with command-line-style options indicating an input file, an output file, and a path to text files containing STB master list and assignment list entries.
• each datetime value can be represented as an array of unsigned integers (rather than as milliseconds from an arbitrary datetime coordinate) for use in STBs.
• unsigned integers rather than as milliseconds from an arbitrary datetime coordinate
• incoming data about events consists of records in an XML format describing spacetime coordinates e.g., latitude, longitude, and datetime values.
• additional input data can include feature elements describing the precision of the input spacetime coordinates.
• An inbound record for the analytics engine can include both geospatial and temporal precision values and can take a form such as:
• the GEO_PRECISION value can be specified in unsigned integer values representing meters. For example, in some embodiments this number may represent 20 meters, 60 meters, 240 meters, etc. If this field is blank, or not specified in the incoming XML, it will be treated as 0 which would indicate 0 meters of error.
• the TIME_PRECISION value can represent the precision, in seconds, of a datetime stamp. Typically this will be zero as provided by most data source systems. In some embodiments, it can be routinely set to, for example, 0.1 (i.e., 100 milliseconds) to accommodate for possible errors.
• the GEO_PRECISION and TIME_PRECISION feature elements can be used for various purposes.
• One purpose involves using one or more of the GEO_PRECISION and TIME_PRECISION values as qualification criteria to filter input data of insufficient precision. For example, if the geohash length is 6 bytes (i.e., a 610 m precision) then a filter can be set to include only those geolocation records having a precision less than or equal to 100 m. On the other hand, if the geohash length is 8 bytes (i.e., a 91 m precision), then a filter can be set to include only those geolocation records having a precision less than 20 meters. This limits the generated STBs to those that are of reasonable granularity for the precision and prevents a +/ ⁇ 2000-meter latitude/longitude precision from being assigned to a 19-meter box, for example.
• a second purpose for precision feature elements is to implement a concept referred to herein as “sliders”. That is, a configuration setting can be set either system-wide or by entity type or data source, as a threshold percentage beyond which additional STBs are generated to represent an event.
• the STB calculator can be configured to include those adjacent STBs (of the same space or time granularity) among the set of STBs returned by the STB calculator.
• a user can set values known as slider thresholds.
• spacetime coordinates can be filtered based on configurable geospatial areas. If coordinates fall into specified geohashes, or into roughly elliptical areas around configurable latitudes and longitudes, the STB calculator can include or exclude them based on these settings (and thus either produce or not produce the resulting STBs). In order to achieve this functionality, in some embodiments the following configuration settings are provided for STB generation:
• INCLUDE_IF_GEO_PRECISION Qualifying geospatial precision, in meters: A numeric value representing a geospatial precision, in meters, beyond which no STBs qualify for assignment. Incoming geospatial data may be associated with precisions specified either by data source or by observation. If an event's precision value is greater than or equal to the GEO_PRECISION value, then the event is not assigned to an STB of the type identified in the STB_NAME field. But if the observed precision value is less than the GEO_PRECISION value, the designated assignment may be included in the resulting set of STBs. For example, if GEO_PRECISION is set to 200 and the event has a precision of 2000, an STB is not generated.
• INCLUDE_IF_GEOHASH_LIST List of geohash strings that qualify for assignment: A comma-separated list of strings representing geospatial regions qualifying for STB assignment. If the list is populated and the geohash string associated with an event matches a string in the list, then the event may be assigned to an STB of the type identified in the STB_NAME field. Otherwise, the designated assignment is not included in the resulting set of STBs.
• INCLUDE_IF_NEAR_LAT Longtitude of eligibility zone center point: A decimal number representing a latitude value. This value can be set to define the latitude of the center of a roughly elliptical zone of eligibility. If an event is observed in the zone, then the event may be assigned to an STB of the type designated in the STB_NAME field. Otherwise, the designated assignment is not included in the resulting set of STBs.
• INCLUDE_IF_WITHIN_METERS Radius of eligibility zone, in meters: A numeric value representing the radius of the zone of eligibility centered at the coordinates configured via the INCLUDE_IF_NEAR_LAT and INCLUDE_IF_NEAR_LONG fields. All three of these fields must be set, in order for an eligibility zone to be effectively configured. If an event is observed in the zone, then it may be assigned to an STB of the type designated in the STB_NAME field. Otherwise, the designated assignment is not included in the resulting set of STBs.
• GEO_SLIDER_THRESHOLD_PERCENT Percentage of geographical error for inclusion of adjacent STBs: A numeric value representing a percentage of error beyond which, based on the input GEO_PRECISION value, the STB calculator can generate adjacent STBs that may contain the event. If this field is empty, or if no GEO_PRECISION value is associated with the event, then no surrounding STBs are included in the result set. Otherwise, the STB calculator multiplies the GEO_PRECISION value associated with the event by this percentage value to determine an area over which STBs that are adjacent in space, and that within the percentage of error may contain the event, can be included.
• FIG. 4 shows a schematic example of a situation where an observation's GEO_PRECISION is 120 meters and the GEO_SLIDER_THRESHOLD_PERCENT value has been set to 50.
• the STB calculator multiplies these values (taking 50% of 120 meters, or 60 meters, in this example) and determines whether any adjacent STBs intersect an area of a 60-meter radius around the event. Any STBs intersecting that area are eligible for equal inclusion. More specifically, the STB calculator checks for STBs that might contain the event, based on the observation's precision, by covering a roughly circular area that has a 60-meter radius, centered at the observation's latitude and longitude. The STB calculator includes in the result set any STBs totally or partially situated in that area.
• the STB calculator can generate STBs adjacent to, and of the same granularity as, the STB that contains the event nominally, based on the event's given coordinates and their given precision, subject to any configured GEO_PRECISION, GEOHASH_LIST, and XPATH_FILTER settings that can eliminate some or all of these results.
• FIG. 5 shows a schematic example of another embodiment of the situation described above with respect to FIG. 4 .
• the GEO_PRECISION is 120 meters and the GEO_SLIDER_THRESHOLD_PERCENT value has been set to 50, but instead of creating a circle of inclusion, as described above, the STB calculator chooses four sample points located north, east, south, and west of the event's nominal location. Each of these four points is located at a distance from that nominal location of GEO_PRECISION multiplied by GEO_SLIDER_THRESHOLD_PERCENT, in the same units of measure as the GEO_PRECISION (i.e. meters).
• the STB calculator includes in the result set any STBs that include a sample point.
• the STB calculator can generate STBs adjacent to, and of the same granularity as, the STB that contains the event nominally, based on the event's given coordinates and their given precision, subject to any configured GEO_PRECISION, GEOHASH_LIST, and XPATH_FILTER settings that can eliminate some or all of these results.
• the GEO_SLIDER_THRESHOLD_PERCENT value can allow for a reduced accounting of the potential precision (error), such as 25%.
• the STB calculator checks for adjacent STBs whose borders nearest to the event come within (or have sample points within) an area of a 30-meter radius (i.e., 25% of 120 m) around the event's coordinates. The STB calculator can then include those STBs in the result set.
• the GEO_SLIDER_THRESHOLD_PERCENT value also can be greater than 100%. In the above example, if the GEO_SLIDER_THRESHOLD_PERCENT value is 105, then the STB calculator checks for adjacent STBs whose nearest borders are (or that include sample points) out to 126 meters around the event's coordinates. The STB calculator can then include those STBs in the result set.
• TIME_SLIDER_THRESHOLD_PERCENT Percentage of temporal error for inclusion of adjacent STBs: A numeric value representing a percentage of error beyond which, based on the input TIME_PRECISION value, the STB calculator can generate adjacent STBs that may contain the event. If this field is empty, or if no TIME_PRECISION value is set, then no surrounding STBs are included in the result set. Otherwise, the STB calculator multiplies the TIME_PRECISION value associated with the event by this percentage value to determine a time interval over which STBs that are adjacent in time, and that within the percentage of error may contain the event, can be included.
• Time can be treated similarly to space.
• the STB calculator checks the time 1 second before and 1 second after the event. It can generate adjacent (in time) STBs, if they are totally or partially included in the resulting time interval, subject to any configured GEO_PRECISION, GEOHASH_LIST, and XPATH_FILTER values. If the TIME_SLIDER_THRESHOLD_PERCENT value is 50, in this example, then the STB calculator checks only the time interval out to half second before and after the event, for adjacent (in time) STBs that it can generate.
• a routine can determine whether a given datetime value is sufficiently “close to” a time interval boundary for a neighboring time interval to qualify for inclusion in the resulting set of STBs.
• a routine can be used in sliders computation to generalize the base of the time range used for “lower bound” sliders computation by representing that time as a set of numeric values that can represent one or more of: a year, a month, a day, an hour, a minute, a second, and a millisecond. Performing this computation without converting datetime values to offsets (in milliseconds or otherwise) from an arbitrary datetime, allows for higher performance than could otherwise have been achieved.
• the analytics engine can resolve inbound entities with existing entities through a process that starts with candidate selection by identifying spacetime co-occurrence (i.e., whether two entities are associated with the same STB) between candidate entities using their anonymized STB keys.
• spacetime co-occurrence i.e., whether two entities are associated with the same STB
• other entities can be compared with it and be exactly matched (or not) to that entity's geospatial location at a certain time, at the granularity defined by the STB. If an observed entity is found to be sufficiently similar to a candidate entity—i.e. a candidate vessel shares sufficient features with the observed ship—then the analytics engine can resolve the observed entity and the candidate entity by considering them to be one and the same entity.
• Space and time can be generalized and anonymized by breaking it down into STBs represented as features with specific anonymized STB keys.
• the analytics engine can compare among other features anonymized STB keys to determine whether two entities are the same (because they have corresponding keys) or different (because they do not have corresponding keys). That is, any entities that are associated with STB features can be differentiated by their STB keys. Entities that share STB keys can be resolved into a single entity, based on STB co-location and other features of those entities. Entities that have disagreeing anonymized STB keys (e.g., cannot be in two places as the same time) can be automatically prevented from resolving into a single entity.
• Entities can be associated with different STB granularities, and accordingly STB keys of varying length can be computed, stored and compared, based on data source precision and user-configurable settings.
• FIG. 6 shows a schematic view of how two entities, Entity A and Entity B, respectively, are associated with different STB granularities.
• both Entity A and Entity B reside in the same lower-granularity STB (i.e., if they are geospatial entities that are assigned respective non-anonymized geohash keys, these keys may be identical up to a point), but they reside in different higher-granularity STBs (i.e., the last portion of their respective geohash keys differ).
• Sets of entities e.g. swaths of space and time selectable by coordinates and radii, or by XPath filtering, or by other means of geospatial inclusion and/or exclusion
• Entities that are candidates for resolution can be selected according to the overall number of entities that are generally observed in the vicinity. For example, an STB that covers a twenty-kilometer area may cover a metropolitan setting, or it may cover a setting in the open ocean. On the one hand, thousands of entities may be distinguished in the metropolitan setting, where an attempt to consider so many candidate entities would not scale for candidate selection purposes. On the other hand, only a few entities (e.g. vessels) may be distinguished in the ocean setting, where the relatively small number of entities sharing the same STB would qualify them all as candidates for prospective resolution—at scale.
• the analytics engine counts entities' features once per discrete entity. Entities that are observed on multiple occasions in an STB are counted, as having been observed in that STB, just once. This optimization allows for large numbers of similar observations to be reduced to a relatively few representations of single occurrences that each reflect a specific tracked entity. Further, this optimization is applicable to any entity feature, including the STB feature, providing for significant entity resolution scalability.
• the foregoing set of space and time capabilities can be applied to both anonymized keys and to keys which are not anonymized, and can lead to scalable, privacy-protective, highly practical resolution of entities based on geospatial data coming in from a range of data sources.
• motion processing functionality can be used to detect and report “hangouts,” that is, conditions where an entity is observed in a certain set of STBs on at least a certain number of occasions over a certain time interval.
• hangout detection can be available through a standalone executable that provides data for processing by an analytics engine, or for any other purpose.
• hangout detection can be available through a component of the analytics engine itself.
• the hangout detector executable or component monitors the movement of entities, flagging conditions where an entity is observed “hanging out” in one or more STBs.
• the data sources, entity types, and spatial areas covered by hangout detection are all configurable.
• the hangout detector uses in-memory event tracking to detect hangouts with optimum efficiency.
• the hangout detector's in-memory event data is not shared across processes. Therefore, incoming motion data for a particular entity is consistently passed to a particular hangout detector node tracking that entity.
• a simple scheme involves always passing the same Observation Source Key (OBS_SRC_KEY) value to the same motion-processing node. In deploying the hangout detector, a user can implement this through a simple modulo function.
• the hangout detector's in-memory event data is volatile. That is, whenever the hangout detector is exited and restarted, any work-in-progress hangouts are lost. This means stopping and re-starting the process may cause the system to miss reporting real hangouts. To remedy this, some of the motion data history can be replayed, e.g., going back in time 48 hours and replaying those motion records applicable to any node that was restarted.
• Hangouts can be detected based on configurable time windows, or time horizons, whose durations have practical limits based on the number of entities and events that are tracked. Events expire as time moves on past those time horizons, and the memory used for tracking expired events is reclaimed. If a user needs to set up horizons of very different durations, a user can assign tasks to multiple hangout detector processes for scalability. One process might work on minute-based motion data to produce daily hangout records. These records could then be treated as events streamed to another process that might compute hangouts on hangouts, i.e., daily hangouts treated as motion data to roll up to weekly or monthly hangouts.
• a configuration table or file (for example, in the form of comma-separated values, .csv) can be used to configure what is defined as a “hangout”.
• the configurable parameters can include a qualifying time interval and minimum number of events for any given data source, entity type, and STB. When these thresholds are met, the hangout detector produces a hangout record (an XML structure) for the entity.
• a hangout detector executable module can be configured by a file containing the following comma-separated fields:
• STB hangout configuration associates data sources, entity types and STBs with time and event thresholds as follows:
• DSRC_CODE Data source code: An identifier that corresponds to an entry in a “CFG_DSRC” table and that indicates the data source for motion data. The value in this field can represent any code designating the data source, e.g., “AIS”.
• ETYPE_CODE Entity type code: An identifier that corresponds to an entry in a “CFG_ETYPE” table and that indicates an entity type. The value in this field can represent any code designating the entity type, e.g., “VESSEL”.
• STB_KEY SpaceTimeBox key: An identifier for an STB type representing a value in the PLU_STB_MASTER configuration table or in some other source of STB configuration settings, e.g., “GR1_GH6 — 1HOUR”.
• QUAL_DUR Qualifying duration: A numeric value representing a time horizon, the maximum qualifying time interval in which a hangout becomes time-qualified; a hangout must also qualify based on the number of events specified in the MIN_EVENTS field.
• QUAL_DUR_UOM Qualifying duration units of measure: An identifier for the units of measure applicable to the QUAL_DUR value. Acceptable identifiers can include, for example, YEAR, MONTH, DAY, HOUR, MIN, SEC, and MS.
• MIN_EVENTS Minimum qualifying events: A numeric value representing the minimum qualifying number of events that must be observed before the hangout becomes qualified; a hangout must also qualify based on the time horizon specified in the QUAL_DUR and QUAL_DUR_UOM fields.
• the XML message format that was shown above with reference to the STBs can also be used by the hangout detector to generalize a geospatial event.
• hangout STB's can be anonymized in just the manner a stationary spacetime coordinates STB can be standardized.
• the hangout detector tracks events associated with STB keys in the hangout configuration table or file.
• the hangout detector considers any event accumulation (not qualified as a hangout) that has exceeded the configured time horizon to be expired.
• the hangout detector will generate no hangout record once the relevant events have expired. Instead, it deallocates the memory for those accumulated events.
• the hangout detector can alternatively track events associated with complete STB information. It can then consider any event older than either the configured time horizon or the limit of the STB time interval to be expired. It also can deallocate event records that have expired based on either the configured time horizon or the STB interval, if the -EXPIRE_EVENTS_BY_STB_INTERVAL option is set.
• FIG. 7 shows a schematic view of how events expire at hangout interval boundaries. All three events shown in FIG. 7 qualify as meeting threshold requirements, and a hangout is flagged if MIN_EVENTS is set to 3.
• hangout detector In an embodiment where events expire at STB time interval boundaries, those events that are not in a common STB do not contribute to hangout reporting for that STB, and a hangout is flagged in the above scenario only if MIN_EVENTS is set to 1 or 0. It is envisioned that the hangout detector's scalability and performance will be somewhat reduced in such an embodiment.
• FIG. 8 shows one embodiment in which a user can set a Qualifying Timebox Percentage (QUAL_TIMEBOX_PERCENT) to define when a hangout should be detected.
• QUAL_TIMEBOX_PERCENT Qualifying Timebox Percentage
• an entity spends 30% of its time in STB1 and 70% of its time in STB2. If a user has set QUAL_TIMEBOX_PERCENT to 50%, a hangout is flagged in STB2. If the user instead had set QUAL_TIMEBOX_PERCENT to 30% or less, a hangout would be flagged both in STB1 and STB2.
• a hangout is immediately flagged when a qualifying number of events occurs within a qualifying timeframe. Further events occurring within the same STB do not result in further hangout reports. That is, hangout reports are limited to no more than one per entity per STB, thus making the hangout detection much more efficient than otherwise would be the case.
• the hangout detector tracks entities in a skiplist sorted by numeric entity keys.
• the events associated with each tracked entity are recorded in FIFO queues, one queue per tracked entity.
• a queue cleanup thread routinely walks the entity list and event queues, deallocating the tracking structures associated with any events older than the qualifying duration.
• the queue cleanup thread also deallocates the tracking structures associated with any entities whose event queues have become entirely empty. This is schematically shown in FIG. 9 .
• FIGS. 10 and 11 show two flowcharts representing the processing steps for the threads of the multithread hangout detector, in accordance with one embodiment.
• FIG. 10 shows the operation of a first thread and FIG. 11 shows the operation of a second thread.
• the thread starts by observing an entity (step 1002 ). The thread then checks if the entity is recognized (that is, found in the entity skiplist) (step 1004 ). If the entity is not found in the entity skiplist, the thread continues to step 1006 where the entity is tracked the skiplist. When the entity is tracked in the entity skiplist, either as a result of a positive determination in step 1004 , or as a result of starting to track the entity in the entity skiplist in step 1006 , the thread goes on to determine the STB containing the entity (step 1008 ).
• the STB is recorded as a bit vector and date time construct in the entity's event queue (step 1010 ).
• the thread then examines whether there are any events that are associated with entity and that are older than the configured time horizon (step 1012 ). If there are such events, these expired events are deleted (step 1014 ). If there are no such events, or when the older events have been deleted, the thread continues to step 1016 , in which it checks whether a minimum number of events are recorded to qualify for reporting a hangout. If no such minimum number of events has been recorded, the hangout detector continues running (step 1022 ) so as to enable the thread to process any further observations.
• the thread goes on to determine whether a hangout has been reported for the entity and STB (step 1018 ). If a hangout has been reported, the hangout detector keeps running (step 1022 ) in expectation of further observations. If a hangout has not been reported for the entity and STB, the thread continues to step 1020 in which it reports the entity as hanging out in the STB (step 1020 ), and the hangout detector continues running (step 1022 ), which concludes the description of the first thread.
• a second thread is run, as shown in FIG. 11 .
• this second thread determines whether the entity skiplist is empty (step 1102 ). If the entity skiplist is empty, the thread waits for an entity to be observed (step 1104 ). If it is determined that the skiplist is not empty in step 1102 , the thread goes to the beginning of the entity skiplist (step 1106 ) and determines whether there are any events that are associated with the entity and that are older than the configured time horizon (step 1108 ). If there are such events, then these expired events are deleted (step 1110 ) and the thread proceeds to the next entry in the skiplist (step 1112 ).
• step 1108 If there are no events in step 1108 that are associated with the entity and that are older than the configured time horizon, the thread proceeds to the next entry in the skiplist (step 1112 ), which concludes the description of the second thread.
• the next skiplist entry can include the first entry, which becomes the next entry when the thread has reached the end of the skiplist.
• the hangout detector when it flags a detected condition to the analytics engine, it does so by passing data about the anonymized hangout into the analytics engine.
• the XML data describes an observed feature, with a feature type code of STB_KEY and a usage type code of HANGOUT.
• the XML data includes a feature element whose code is EXPRESSION and whose value is the STB key corresponding to the region in which the detected hangout has occurred.
• a user can arrange for observed entities to be associated with 0-n anonymized STB keys, and for the methods described herein to be performed, by any of several processing nodes. For example, one computer can process all incoming records, then farm out individual tasks to one of N other computers (that is, N processing nodes). Based on a numeric entity or observation identifier, a decision can be made as to which node among the N nodes will process a given task. In some embodiments, this decision can be as simple as taking the input identifier modulo N.
• tagless storage such as in-memory data structures that are agreed on between applications or components and shared through means such as named pipes, shared memory, queues, on-disk files, and so on.
• Another alternative involves writing data to a database (using SQL encodings, for example) and reading the data back into other applications or components.
• Yet another alternative involves writing a custom data transfer protocol. As can be seen, many variations of data exchange mechanisms can be envisioned by those having ordinary skill in the art.
• geospatial regions such as longitude and latitude coordinates
• non-spatial dimensions that describe the geospatial region, such as geographical areas that are covered by a specific cell phone tower, for example, or geographical areas that are covered by a specific wireless network, etc.
• These techniques also can be applied to spatial regions that are not geospatial, e.g. regions of a bounded substrate, of a closed system, or of an astronomical object regarded from a non-Earthly perspective.
• each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
• the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Abstract

Description

Claims (20)

Priority Applications (4)

Applications Claiming Priority (1)

Related Child Applications (1)

Publications (2)

Family

ID=52776960

Family Applications (2)

Family Applications After (1)

Country Status (3)

Cited By (5)

Families Citing this family (10)

Citations (58)

• 2013
  • 2013-10-03 US US14/045,718 patent/US9270451B2/en not_active Expired - Fee Related
• 2014
  • 2014-06-23 US US14/312,085 patent/US9338001B2/en not_active Expired - Fee Related
  • 2014-09-04 WO PCT/JP2014/004558 patent/WO2015049831A1/en active Application Filing
  • 2014-09-04 JP JP2016517571A patent/JP2016540274A/en active Pending

Patent Citations (62)

Non-Patent Citations (56)

Also Published As

Similar Documents

Legal Events