Patent Description:
Content based retrieval systems are designed to store and recall information based on content as the retrieval cue (see Literature Reference No. <NUM> of the List of References). However, prior content based retrieval systems have mainly focused on multimedia content, such as audio and video.

In query based retrieval, a sample is directly provided to the system as a cue to be used for retrieval, and different matching algorithms are applied to the content. The prior art in content based retrieval systems uses features derived from the cue and information in the database to perform matching, as seen in the domains of image, video, and audio search. <NPL>, discloses an episodic memory system.

Episodic memory has been investigated as a component in many cognitive architectures (see Literature Reference Nos. <NUM>-<NUM>). Among them, Soar is a well-established architecture that includes models of working memory, procedural memory, and episodic memory. Soar stores the working memory elements (WMEs) into a tree structure in the working memory and stores the event sequence as a list of pointers to the corresponding WMEs in each episode. To retrieve matching episodes with a given cue, Soar searches the working memory tree for each element in the cue, collects all episodes that have at least one element in the cue, and finds the best matching episode. Searching an element in a tree takes O(n) time, where n is the number of elements in the tree. When a balanced binary tree is used, it is reduced to O(log n) time, but Soar does not use a balanced binary tree and tree-search is not efficient. Each episode maintains its own element list. To find the best matching episode, the cue is compared with every candidate episode even if there are many similar episodes in the candidate list. Soar does not take any advantages when there are many similar episodes.

Thus, a continuing need exists for a system that reduces the amount of required storage to store episodes and the access time to retrieve matching episodes with a requested cue for a scalable and efficient episodic memory.

The present invention relates to a system according to claim <NUM>.

In another aspect, when a new episode stored in the episodic memory is similar enough to an existing episode in the episodic memory, then the new episode is discarded to save storage, the similarity being determined by a similarity rating and a similarity rating threshold.

In another aspect, when episodes have common events, the episodes share nodes in the event-sequence graph.

In another aspect, each event in the stored episodes has a corresponding node in the event-sequence graph, and each node has a pointer pointing to a corresponding event in the event database.

In another aspect, the corresponding event in the event database is directly accessible from each node in the event-sequence graph, and from an event in the event database, it is determined which nodes in the event-sequence graph share the event.

In another aspect, the data that is retrieved comprises observations which are a match to a currently observed spatiotemporal sequence of objects in the current environment.

In another aspect, for each event in a new episode that comes into the episodic memory, if there is an existing event in the event database that is the same or similar to the event in the new episode, then the existing event is used, otherwise, the event in the new episode is stored in the event database.

In another aspect, the hash function is used to store episodes in the event database.

In another aspect, the behavior of the automated platform is guided to correspond with the sequence of events in the retrieved episode.

In another aspect, the behavior of the automated platform is guided to avoid the sequence of events in the retrieved episode.

In another aspect, guiding the automated platform includes at least one of steering, accelerating, and braking.

In another aspect, acquiring data further comprises generating a list of events from the episode that corresponds to the closest node, and the data includes the list of events.

Finally, the present invention also includes a computer program product according to claim <NUM> and a computer implemented method according to claim <NUM>.

The present invention relates to a system for scalable and efficient episodic memory for an automated system and, more particularly, to a system for scalable and efficient episodic memory for automated systems that reduces the amount of required storage and access time to retrieve matching episodes.

Before describing the invention in detail, first a list of cited references is provided. Next, a description of the various principal aspects of the present invention is provided. Finally, specific details of various embodiment of the present invention are provided to give an understanding of the specific aspects.

The following references are cited. For clarity and convenience, the references are listed herein as a central resource for the reader. The references are cited in the application by referring to the corresponding literature reference number, as follows:.

Various embodiments of the invention include three "principal" aspects. The first is a system for scalable and efficient episodic memory according to claim <NUM>. The system is typically in the form of a computer system operating software or in the form of a "hard-coded" instruction set. This system may be incorporated into a wide variety of devices that provide different functionalities. The second principal aspect is a method according to claim <NUM>. The third principal aspect is a computer program product according to claim <NUM>. The computer program product generally represents computer-readable instructions stored on a non-transitory computer-readable medium such as an optical storage device, e.g., a compact disc (CD) or digital versatile disc (DVD), or a magnetic storage device such as a floppy disk or magnetic tape. Other, non-limiting examples of computer-readable media include hard disks, read-only memory (ROM), and flash-type memories. These aspects will be described in more detail below.

A block diagram depicting an example of a system (i.e., computer system <NUM>) of the present invention is provided in <FIG>. The computer system <NUM> is configured to perform calculations, processes, operations, and/or functions associated with a program or algorithm. In one aspect, certain processes and steps discussed herein are realized as a series of instructions (e.g., software program) that reside within computer readable memory units and are executed by one or more processors of the computer system <NUM>. When executed, the instructions cause the computer system <NUM> to perform specific actions and exhibit specific behavior, such as described herein.

The computer system <NUM> may include an address/data bus <NUM> that is configured to communicate information. Additionally, one or more data processing units, such as a processor <NUM> (or processors), are coupled with the address/data bus <NUM>. The processor <NUM> is configured to process information and instructions. In an aspect, the processor <NUM> is a microprocessor. Alternatively, the processor <NUM> may be a different type of processor such as a parallel processor, application-specific integrated circuit (ASIC), programmable logic array (PLA), complex programmable logic device (CPLD), or a field programmable gate array (FPGA).

The computer system <NUM> is configured to utilize one or more data storage units. The computer system <NUM> may include a volatile memory unit <NUM> (e.g., random access memory ("RAM"), static RAM, dynamic RAM, etc.) coupled with the address/data bus <NUM>, wherein a volatile memory unit <NUM> is configured to store information and instructions for the processor <NUM>. The computer system <NUM> further may include a non-volatile memory unit <NUM> (e.g., read-only memory ("ROM"), programmable ROM ("PROM"), erasable programmable ROM ("EPROM"), electrically erasable programmable ROM "EEPROM"), flash memory, etc.) coupled with the address/data bus <NUM>, wherein the non-volatile memory unit <NUM> is configured to store static information and instructions for the processor <NUM>. Alternatively, the computer system <NUM> may execute instructions retrieved from an online data storage unit such as in "Cloud" computing. In an aspect, the computer system <NUM> also may include one or more interfaces, such as an interface <NUM>, coupled with the address/data bus <NUM>. The one or more interfaces are configured to enable the computer system <NUM> to interface with other electronic devices and computer systems. The communication interfaces implemented by the one or more interfaces may include wireline (e.g., serial cables, modems, network adaptors, etc.) and/or wireless (e.g., wireless modems, wireless network adaptors, etc.) communication technology.

In one aspect, the computer system <NUM> may include an input device <NUM> coupled with the address/data bus <NUM>, wherein the input device <NUM> is configured to communicate information and command selections to the processor <NUM>. In accordance with one aspect, the input device <NUM> is an alphanumeric input device, such as a keyboard, that may include alphanumeric and/or function keys. Alternatively, the input device <NUM> may be an input device other than an alphanumeric input device. In an aspect, the computer system <NUM> may include a cursor control device <NUM> coupled with the address/data bus <NUM>, wherein the cursor control device <NUM> is configured to communicate user input information and/or command selections to the processor <NUM>. In an aspect, the cursor control device <NUM> is implemented using a device such as a mouse, a track-ball, a track-pad, an optical tracking device, or a touch screen. The foregoing notwithstanding, in an aspect, the cursor control device <NUM> is directed and/or activated via input from the input device <NUM>, such as in response to the use of special keys and key sequence commands associated with the input device <NUM>. In an alternative aspect, the cursor control device <NUM> is configured to be directed or guided by voice commands.

In an aspect, the computer system <NUM> further may include one or more optional computer usable data storage devices, such as a storage device <NUM>, coupled with the address/data bus <NUM>. The storage device <NUM> is configured to store information and/or computer executable instructions. In one aspect, the storage device <NUM> is a storage device such as a magnetic or optical disk drive (e.g., hard disk drive ("HDD"), floppy diskette, compact disk read only memory ("CD-ROM"), digital versatile disk ("DVD")). Pursuant to one aspect, a display device <NUM> is coupled with the address/data bus <NUM>, wherein the display device <NUM> is configured to display video and/or graphics. In an aspect, the display device <NUM> may include a cathode ray tube ("CRT"), liquid crystal display ("LCD"), field emission display ("FED"), plasma display, or any other display device suitable for displaying video and/or graphic images and alphanumeric characters recognizable to a user.

The computer system <NUM> presented herein is an example computing environment in accordance with an aspect. However, the non-limiting example of the computer system <NUM> is not strictly limited to being a computer system. For example, an aspect provides that the computer system <NUM> represents a type of data processing analysis that may be used in accordance with various aspects described herein. Moreover, other computing systems may also be implemented. Indeed, the spirit and scope of the present technology is not limited to any single data processing environment. Thus, in an aspect, one or more operations of various aspects of the present technology are controlled or implemented using computer-executable instructions, such as program modules, being executed by a computer. In one implementation, such program modules include routines, programs, objects, components and/or data structures that are configured to perform particular tasks or implement particular abstract data types. In addition, an aspect provides that one or more aspects of the present technology are implemented by utilizing one or more distributed computing environments, such as where tasks are performed by remote processing devices that are linked through a communications network, or such as where various program modules are located in both local and remote computer-storage media including memory-storage devices.

An illustrative diagram of a computer program product (i.e., storage device) embodying the present invention is depicted in <FIG>. The computer program product is depicted as floppy disk <NUM> or an optical disk <NUM> such as a CD or DVD. However, as mentioned previously, the computer program product generally represents computer-readable instructions stored on any compatible non-transitory computer-readable medium. The term "instructions" as used with respect to this invention generally indicates a set of operations to be performed on a computer, and may represent pieces of a whole program or individual, separable, software modules. Non-limiting examples of "instruction" include computer program code (source or object code) and "hard-coded" electronics (i.e. computer operations coded into a computer chip). The "instruction" is stored on any non-transitory computer-readable medium, such as in the memory of a computer or on a floppy disk, a CD-ROM, and a flash drive. In either event, the instructions are encoded on a non-transitory computer-readable medium.

Described are a scalable episodic memory architecture and efficient access methods to store and retrieve episodes in an episodic memory. An episode is a sequence of events that describe situations in an application domain. The actual content of each event depends on what needs to be dealt with and the application domain as well. For example, in the automated driving domain, each event might be an arrangement of perceived objects around the self-vehicle at a specific time. The objects might include vehicles, motorcycles, pedestrians, road signs, traffic lights, and traffic islands. Furthermore, in the intelligence, surveillance, and reconnaissance (ISR) domain, events may include information from multiple sources as geospatial locations and times of objects, people, activities, signals intelligence. The system described herein reduces the amount of required storage to store episodes and the access time to retrieve matching episodes with a requested cue for a scalable and efficient episodic memory, thereby dramatically improving the computer system itself. In order to achieve this, the invention may comprise one or more of multiple unique components.

First, a collective event database may be maintained in the episodic memory. All events of the stored episodes are separated from their episodes and put into the common event database. Each episode keeps a list of pointers pointing to its events in the database. When multiple episodes have a common event in their event sequences, only one event is stored in the database, and it is shared by the episodes instead of keeping their own instances of the event in themselves. Additionally, if an event occurs several times in an episode, only one event is stored in the database and the episode keeps multiple pointers to the event instead of keeping multiple instances of the same event in itself.

Second, a hash function is adopted to access the event database in the episodic memory. A set of a hash key and hash function reduces search time of a requested event in the database to O(<NUM>) to store or retrieve the event.

Third, the event sequences of the episodes may be stored in a common graph structure. In some embodiments, a graph is a structure amounting to a set of objects in which some pairs of the objects are in some sense "related". The objects correspond to mathematical abstractions called nodes (also called vertices or points) and each of the related pairs of nodes is called an edge (also called an arc or line). Typically, a graph may be depicted in diagrammatic form as a set of dots for the vertices, joined by lines or curves for the edges. Graphs are one of the objects of study in discrete mathematics.

When a new episode is added into the episodic memory, the closest stored episode is retrieved. If they are close enough (e.g., a similarity measure or rating is less than or greater than a measure or rating threshold), a mechanism is used where the new episode shares the same nodes in the path of the existing episode and adds alternative routes to the path whenever its sub-sequence (i.e., small part or segment of a sequence) does not match with that of the existing episodes. This node sharing mechanism in the graph structure reduces the required storage and also facilitates the matching process, because comparing with the shared nodes has the same effect of comparing with the multiple episodes sharing the nodes. These three components make a scalable and efficient episodic memory possible.

The system according to embodiments of the present disclosure provides a capability to store and recall spatiotemporal sequences of information relevant to automated systems to guide their behavior. Instead of addressing memory directly, the cue to perform a recall is information content of the same domain as is stored. As can be appreciated by those skilled in the art, the process described herein dramatically improves the performance of the computer system itself and, as a result, improves the associated systems relying thereon. Further details are provided below.

A hippocampal-like episodic memory in an intelligent cognitive system needs to be able to store and recall spatio-temporal sequences of data fast and efficiently. In addition to basic store and recall, the episodic memory system needs to be able to make partial matches. Due to the potential complexity of spatio-temporal data streams, it is unlikely that different episodes will exactly match. There is, consequently, a need to do approximate matching returning a distance or similarity measure so various episodes can be ranked according to degree of match or applicability. In addition, as the system will be used to generate expectations, it will also need to perform partial prefix matches where the episodic suffix will represent an expectation. Finally, as one wants to store as many episodes as possible, some form of compression or common subsequence recognition is necessary to reduce or eliminate duplicated stores of common subsequences, which may appear in different episodes. The system described herein is designed to be domain agnostic. Some of the possible instances of this spatio-temporal sequence data are the data sensed by an automated vehicle and ISR (intelligence, surveillance, reconnaissance) data sensed by a UAV (unmanned aerial vehicle) or some geo-spatial analysist system.

The episodic memory system has four layers (or levels) of data structures. These are called an element layer, an event layer, an episode layer, and an episodic memory layer.

The lowest level is the element. Elements are indivisible things, or facts, describing the environments or the situation at a specific time, and they are different depending on the application domain. In the automated driving domain, elements could be things affecting driving, such as vehicles, bicycles, persons, obstacles, traffic signs, traffic lights, traffic officers, lane markers, and road structures. Elements could have descriptions (attributes and values) about themselves at a specific time. While stationary elements may have static descriptions, such as speed limit sign and lane markers, dynamic elements may have temporally changing descriptions, such as moving objects and traffic lights.

The primary method for the element layer is the comparison of two elements. The comparison returns distance (or similarity) between two elements - a measure of how far (or similar) two elements are to each other. When the elements are in different types, they are different, such as a vehicle versus a person, a bicycle versus a traffic sign, and so on. The comparison should apply different appropriate measures for different element types. If the elements have multiple levels of abstraction, the comparison may consider the level of details as well, if necessary. For example, "vehicle" could be a top level abstraction of a trailer, truck, bus, sedan, van, or motorcycle. "Person" might be divided into adult and child in the detailed level.

An event is a collection of the elements that describe the situation at a specific time. An event may have information about the spatial arrangements of the elements as well. An event in the automated driving domain will include a representation of the spatial arrangement of the elements that the automated system senses at a specific time. The elements are described using an egocentric perspective. However, a geo-centric perspective is also used where a multi-way observation is required, such as an intersection.

The primary method for the event layer is also the comparison of two events. The comparison returns distance (or similarity) - a measure of how far (or similar) two events are to each other. The comparison collects the element-wise comparison results of the event components and analyzes them. If an event has multiple levels of abstraction, the comparison may consider the level of details as well. When event A and event B are compared in this embodiment, simple set metrics are: <MAT> <MAT> where A ∩ B is an intersection (the same or similar elements) of A and B, A U B is a union (all different elements) of A and B, and |A| is the number of elements in A. If the importance of each element type is different, a weighted metric would be preferable. Other embodiments may include weighting functions on specific element types for the metric, and other metrics.

An episode is a sequence of events chained together in a temporal ordering. One of the difficulties with respect to episodes is deciding where they begin and where they end. Depending on the application domain, different criteria or methods might be applied. In the automated driving domain, the entire driving sequence from the starting location to the destination could be thought of as one episode. An alternative method is using each item in the turn list generated by a navigation system as an episode, and the whole trip is a collection of short-term episodes.

The primary method for episodes is the comparison of two episodes, as with events. An episode is a temporally ordered event sequence. If the comparison is to check if the two episodes are the same or not, it is simple; check if the numbers of the events are the same and check if the corresponding events are the same in the event sequences. If the comparison is to measure distance (or similarity) between two episodes, the event sequences in the episodes should be properly aligned to each other and the correspondences between events should be determined first. Then, distances between the corresponding event pairs are collected and summarized to the final result. If there are any noncorresponding (missing or extra) events in the episodes, penalties might be applied for noncorresponding events. This is central to recall matching episodes with a partial cue. The system described herein adopts spatial-temporal generalizations of bioinformatics sequence alignment algorithms.

Episodic memory represents the complete knowledge set of 'remembered' episodes. The episodic memory should have the following functionalities: storing episodes, deleting obsolete episodes, recalling existing episodes, and completing a partial cue to existing episodes. Just listing all the episodes will be inefficient from both of a memory storage point of view and from an algorithmic point of view. The episodes should be stored efficiently in the view of memory size and memory search as well. Episodic memory keeps events and episodes separately. Episodic memory also creates an event-sequence graph to capture the similarities between the stored episodes.

As depicted in <FIG>, episodic memory is composed of three major parts: an event database <NUM>, an event-sequence graph <NUM>, and an episode list <NUM>.

All events (e.g., <NUM>) of the episodes <NUM> in the episodic memory are collected and stored in the event database <NUM> using a hash function. The hash function should use key elements in the event structure and should distribute the events <NUM> as evenly in the buckets in the event database <NUM> as possible for efficient event search. A good hash function and hash key depend on the content of events <NUM> and application domains as well. As a new episode <NUM> comes into the episodic memory, for each event <NUM> in the episode, the event database <NUM> is searched to check if the same or similar event <NUM> is already in there. If the same or similar event <NUM> is found in the event database <NUM>, the existing event <NUM> will be used; otherwise, the new event <NUM> will be stored into the event database <NUM>. Instead of storing all events, reusing the existing events <NUM> could save the memory space and speed up the searching process. This will also help the scalability of the episodic memory. The criteria of the same or similar event depend on the application domain and the levels of abstraction in the event structure.

An event-sequence graph <NUM> is a directed graph whose nodes (e.g., <NUM>) represent the events in the stored episodes. Each path (represented by a series of nodes connected by arrows) in the event-sequence graph <NUM> may show the event sequence of some stored episode(s). Multiple episodes <NUM> might be similar to each other; for example, when multiple episodes have most of their event sequences the same and small number of events different. The multiple similar episodes could share the same main path in the event-sequence graph <NUM>. Each episode forks a short alternative route at the starting of each noncorresponding subsequence and joins to the main path at the end of the noncorresponding subsequence. Therefore, the event-sequence graph <NUM> captures these similarities between episodes <NUM> and facilitates searching episodes with a cue <NUM>, because comparing the cue <NUM> with a shared path has the same effect of comparing the cue <NUM> with the multiple episodes <NUM> sharing the path.

Each event <NUM> in the stored episodes in the event-sequence graph <NUM> has a corresponding node (e.g., <NUM>) in the event-sequence graph <NUM>, and each node (e.g., <NUM>) has a pointer pointing to the corresponding event <NUM> in the event database <NUM>. The event <NUM> in the event database <NUM> also keeps a pointer pointing back to the corresponding node (e.g., <NUM>), allowing for accessing each other directly. The two-sided pointing between nodes (e.g., <NUM>) and events (e.g., <NUM>) is indicated in <FIG> as double-sided arrows. When multiple nodes share the same event in the event database <NUM>, the all nodes point to the same event, and the event keeps a list of pointers pointing back to the multiple nodes. "All nodes" refers to multiple nodes sharing the same event. Therefore, from a node (e.g., <NUM>), the corresponding event (e.g., <NUM>) in the event database <NUM> can be directly accessed and, similarly, from an event (e.g., <NUM>) in the event database <NUM>, one can tell which nodes (e.g., <NUM>) in the event-sequence graph <NUM> share the event. The node (e.g., <NUM>) representing the last event of each stored episode has a pointer to the corresponding episode (e.g., <NUM>). When the event sequences of multiple episodes end at the same node, the node keeps a list of pointers pointing to the multiple episodes. At an end node of a path (e.g., <NUM>), these pointers can tell which episodes might be matching with the path.

An episode list <NUM> stores all episodes in the episodic memory. The event sequence in each stored episode is replaced with a list of pointers pointing to the corresponding nodes in the event-sequence graph. The all events (e.g., <NUM>) in an episode (e.g., <NUM>) can be accessed indirectly through the pointers to the corresponding nodes (e.g., <NUM>). The "all events" refers to all events in the even sequence in an episode. When a new episode is stored into the episode list <NUM>, the episode list <NUM> is checked if there is the same episode (e.g., <NUM>). If the same episode is found, the counter in the existing episode is increased, and the new episode is discarded to save the storage. Each episode in the episode list has a counter of occurrence in the training episode data set. If all episodes are unique in the data set, the counters are all <NUM>. If an episode is repeated twice in the data set, the counter of the episode will be <NUM> instead of storing the same episode twice.

The event sequence in an episode (e.g., <NUM>) has a temporal order. The input cue <NUM> for searching the episodes (e.g., <NUM>) in the episodic memory could be a complete episode or an incomplete partial subsequence, as depicted in <FIG>. A complete episode cue could be used for inserting a new episode and deleting an obsolete episode. With a cue (e.g., <NUM>, a segment of a whole event sequence) from a live input stream, a system could predict future based on the suffix(es) of the matching episodes. With a partial suffix cue, the system could collect all pre-conditions ended up to the resulting partial cue based on the prefixes of the matching episodes. The invention described herein uses a version of the sequence alignment algorithm from bioinformatics. This algorithm as used in bioinformatics takes a DNA or protein sequence and finds the best match in a large database of sequences. In a similar way, it will find the best matches within episodic memory using the event-sequence graph <NUM> and align the cue <NUM> with it if they are not the same.

A brief description of recalling the best matching episodes (e.g., <NUM>) with a cue <NUM> is the following.

The following is an example of the three expansions. <IMG>
<IMG>.

(<NUM>) If the priority queue is empty, there is no matching episode in the episodic memory with the cue. Because the top entry in the queue is one of the best matching aligned sequence, pop the top entry and put it into the candidate list. Until the queue is empty or the cost of the top entry is greater than the cost of the candidate, pop the top entry, and add it into the candidate list when the last event in the event-path is the last event in the cue or the last node in the node-path is a terminal node because the alignment is completed. candidates <- NULL
if not empty(priority_queue)
(e_path, n_path, cost) <- top (priority_queue)
min_cost <- cost
push n_path into candidates
pop(priority_queue)
while not empty(priority_queue)
(e_path, n_path, cost) <- top(priority_queue)
if min_cost < cost
break
if last_event(e_path) == last_event(CUE)
push n_path into candidates
if last_node(n_path) is a leaf
push n_path into candidates
pop(priority_queue).

(<NUM>) The node-paths in the candidate list are the aligned parts of the corresponding episodes. When the cue is an incomplete episode, the aligned parts are the subsequences of the whole event sequences of the matching episodes. Since the last node of each episode has a pointer to the episode, traverse forward through the event-sequence graph from the last node in each node-path in the candidate list and collect all episodes pointed by nodes during the traverse, as follows:
matching_episodes <- NULL
for each n_path in candidates
node <- last_node(n_path)
while node is valid
if episode( node ) is valid && n_path is
sub_sequence( episode( node ) )
push episode( node ) into matching_episodes
node <- next( node ).

Two other primary methods for episodic memory are insert and delete. Insert is used to store a new episode into the episodic memory. For each event in the episode, the event database is looked up first with a hash function. If the event is found, the existing event is reused. If it is not found, the new event is stored into the database. With recall method, the best matching episode in the episodic memory is retrieved. If the best matching episode is the same as the new episode, the counter in the existing episode is increased. If no matching episode is found, then the sequence of nodes pointing to the corresponding events in the database is added into the event-sequence graph. From the start of the graph, the algorithm follows the path whose nodes point to the same events as the new inserted nodes point to and makes a new branch when the new node sequence digress from the path. The last new node will point the new episode, and the episode is added to the episode list. If a similar episode is found, the algorithm follows the path of the found episode and branches an alternative route when the events are different from the found episode and joins the main path when the events are the same. A pointer to the new episode in added to the episode list in the last node of the new episode.

Delete removes an obsolete episode. It retrieves the best matching episode in the episodic memory with recall method. If the same one is found, it follows the path in the graph and deletes the nodes and the corresponding events in the event database if they are not shared with any other episodes and then deletes the episode from the episode list.

In summary, the system and method according to embodiments of the present disclosure has multiple unique aspects. The collective hash-based event database <NUM> in the episodic memory reduces the amount of required storage to store episodes by sharing the same events (e.g., <NUM>) between the episodes. All events (e.g., <NUM>) in the episodic memory are separated from their episodes and put into the common event database <NUM> when they do not exist in the database. When the same events (e.g., <NUM>) are found in the event database <NUM>, the events (e.g., <NUM>) are shared between episodes. Multiple episodes share the same events in the event database <NUM> instead of keeping their own instances in themselves. In addition, if an event (e.g., <NUM>) occurs several times in an episode, the episode shares the same event in the database instead of keeping the same multiple instances in itself. Therefore, all events in the event database <NUM> are distinct, and the amount of required storage to store the episodes can be reduced.

Further, a hash function facilitates accessing events in the hash-based event database <NUM>. The hash function maps a hash key directly to the corresponding event (e.g., <NUM>) to reduce the required number of comparisons until finding the matching event. For example, using the hash key as an index of an array of event buckets, each event bucket may have multiple events. Therefore, a good hash function could reduce the access time of the event database <NUM> to O(<NUM>) time.

Additionally, the common event-sequence graph <NUM> structure of the stored episodes (e.g., <NUM>) reduces the retrieving time for the matching episodes with a partial cue <NUM>. When multiple episodes (e.g., <NUM>) have many common events in their sequences, they share the same main path in the event-sequence graph <NUM> with some short alternative routes for their different event segments. These shared nodes represent events in multiple episodes. Comparing the events in the cue <NUM> (represented as various patterned rectangles) with the shared nodes has the same effect of comparing the cue with the multiple episodes sharing the nodes. This system described herein makes an episodic memory scalable and efficient by reducing storage requirement and processing time.

In the invention described herein (and as depicted in <FIG>), an episodic memory <NUM> was designed that performs content based retrieval (i.e., retrieve observations from episodic memory <NUM>) using higher level information provided by perceptual systems (commonly found in automated mobile platforms and robotic platforms that employ object recognition). As described above, each episode is a sequence of events. The events are efficiently stored or retrieved in the event database using a hash function. The repeated episodes are discarded but the number of occurrence is recorded in the stored episode.

The episodic memory <NUM> approach to content based retrieval according to embodiments of the present disclosure is tailored such that the retrieved observations <NUM> are used for application to automated systems to guide behavior (element <NUM>) by directly performing retrieval of observations (element <NUM>) from the episodic memory <NUM> which are a match to the currently observed spatiotemporal sequence of objects in a scene. Non-limiting examples of sensors that could be used to obtain observations of objects in a scene include cameras and/or distance measuring devices using, for instance, ultra-sound or laser. Matching is performed on this information directly instead of computed features. As described above, the episodic memory <NUM> according to embodiments of the present disclosure comprises an event database <NUM>, an event-sequence graph <NUM>, and episode list <NUM>, which interact for a scalable and efficient episodic memory <NUM> system.

An episodic memory <NUM> is a critical component of a cognitive architecture in a variety of applications. Information processing for automated systems, whether on mobile platforms or ground-based infrastructure platforms, can benefit from using an efficient episodic memory <NUM> as a content based retrieval system. Therefore, the system and method described herein is applicable to any area adapting an intelligent learning system. One example application is an intelligent autonomous control. By applying the method described herein to autonomous driving, the system can learn to respond to situations in an area/environment surrounding the automated vehicle, retrieve the appropriate stored knowledge quickly, and resolve any problems, if any, in a timely manner. For example, in the autonomous driving domain, each event might be an arrangement of perceived objects around the self-vehicle at a specific time. The objects might include vehicles, motorcycles, pedestrians, road signs, traffic lights, and traffic islands. Based on past data of these objects from an episodic memory, the system can
guide behavior of the automated vehicle. The automated platform may be fully autonomous, or it may be controlled fully or in part by a person. For example, the person may be present in the vehicle or remotely operating the vehicle. Non-limiting examples of guided behavior include stopping for pedestrians, stopping at stop signs or traffic lights, inducing acceleration of the vehicle when a traffic light indicates a "go" signal, and re-routing the path to avoid another vehicle, pedestrian, traffic cone, or other obstacle.

Furthermore, the system can also be used in intelligent control of manned or unmanned aircraft systems and analysis of acquired information. In the intelligence, surveillance, and reconnaissance (ISR) domain, events may include information from multiple sources as geospatial locations and times of objects, people, activities, signals intelligence. An unmanned aerial vehicle (UAV) can be caused to travel to a specific location/position based on past data of geospatial coordinates, or detect and classify a specific object of interest and travel towards the specific object in order to obtain visual recordings of the object.

Claim 1:
A system for episodic memory for an automated vehicle, the system comprising:
one or more processors and a non-transitory computer-readable medium having executable instructions encoded thereon such that when executed by the one or more processors, the one or more processors perform the following operations:
acquiring data from an episodic memory, wherein the episodic memory comprises an event database, an event-sequence graph, and an episode list, wherein acquiring the data comprises:
identifying in the event-sequence graph a closest node to a current environment for the automated vehicle;
based on the closest node and using a hash function, retrieving from the episodic memory an episode that corresponds to the closest node, the episode including a sequence of events,
wherein the hash function maps a hash key directly to the corresponding event to reduce a number of comparisons needed for finding the matching event; and
controlling the automated vehicle in the current environment based on the data from the episodic memory.