Vehicle recognition for access control in secured yards

Abstract

Systems and methods herein provide automated vehicle recognition and identification within secured yard environments. In an embodiment, a lane monitor detects, based on image data from multiple cameras, a vehicle entering a lane to a secured yard. The lane monitor tracks the vehicle across the cameras as the vehicle moves through the lane, executes one or more machine learning models to detect one or more vehicle identifiers and one or more vehicle features associated with the vehicle, and applies optical character recognition to the one or more vehicle identifiers to convert them into text-based representations. The lane monitor further analyzes the text-based representations of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result and outputs the vehicle identification result for use in making an access decision for the vehicle.

Description

VEHICLE RECOGNITION FOR ACCESS CONTROL IN SECURED YARDSPRIORITY CLAIM

[0001] This application claims the benefit and priority to U.S. Provisional Application entitled “ACCESS CONTROL ENGINE(S) FOR EQUIPMENT TRACKING AND MANAGEMENT,” filed September 13, 2024 under Patent Application No. 63 / 694,485, the contents of which are incorporated by reference in their entirety for all purposes.TECHNICAL FIELD

[0002] Aspects of the disclosure are related to the field of computer software applications and services and, in particular, to vehicle recognition and access control for tracking and managing transportation in distribution and logistics applications.BACKGROUND

[0003] Modem transportation yards play a critical role in today’s logistics networks by providing secure environments for managing multi-piece equipment, such as tractors and trailers. As distribution systems expand to meet increasing market demands, these yards must efficiently coordinate vehicle movements and safeguard valuable assets. Traditional methods for vehicle recognition and lane monitoring often rely on human supervision or isolated sensor systems, such as single-camera setups or manual data entry, which can result in inconsistent or incomplete data collection and slower response times in dynamic operational settings.

[0004] Effectively identifying and tracking vehicles in real time presents significant technical challenges, particularly when relying on fragmented or partial information from limited viewpoints. Conventional approaches, such as manual inspection, single-camera image capture, or basic keycode entry, frequently fail to provide a comprehensive or reliable picture of a vehicle’s identity, configuration, and condition. These limitations can lead to errors in equipment tracking, missed security events, and operational inefficiencies, especially in environments with high vehicle throughput or complex equipment pairings.

[0005] There is a growing need for advanced, automated vision systems capable of integrating and analyzing image data from multiple cameras, extracting and correlating vehicle identifiers and features, and reconstructing complete vehicle profiles even from partial or ambiguous inputs. The present technology addresses these challenges by introducing a robust vehicle recognition system that leverages multi-camera computer vision, machine learning, andintelligent data fusion to deliver accurate, real-time identification and tracking of vehicles and equipment within secured yard environments. This approach enhances security, streamlines operations, and provides reliable, auditable records for all vehicle movements and yard activities.

[0006] It is with respect to this general technical environment that aspects of the present technology disclosed herein have been contemplated. Furthermore, although a general environment has been discussed, it should be understood that the examples described herein should not be limited to the general environment identified in the background.SUMMARY

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify significant features or primary aspects of the claimed subject matter, nor is the Summary intended to be used as an aid in determining the scope of the claimed subject matter.

[0008] The present technology relates to automated vehicle recognition and identification within secured yard environments. More specifically, the technology disclosed herein includes systems and methods for receiving and processing image data from multiple cameras, detecting and tracking vehicles as they approach and move through a lane, extracting and analyzing vehicle identifiers and features using machine learning and computer vision techniques, and generating accurate, real-time vehicle identification results for use in downstream yard management and access control operations.

[0009] In a first embodiment, a computer-implemented method for vehicle recognition for access to a secured yard includes detecting, based on image data received from a plurality of cameras positioned to capture different views of a lane into the secured yard, a vehicle entering the lane and tracking the vehicle across the plurality of cameras as the vehicle moves through the lane. The method further includes executing one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle and applying optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers. The method further includes analyzing the text-based representation of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result and outputting the vehicle identification result for use in making an access decision for the vehicle.

[0010] In some embodiments, the method further includes initiating, by an Al-based voice agent, an interaction with a driver of the vehicle in response to determining that additional information is needed to authenticate the vehicle, capturing the additional information provided by the driver, combining the vehicle identification result with at least the additional information provided by the driver to generate a vehicle access record, and providing the vehicle access record to an access control system. The additional information, in some embodiments, includes a trip number, a load type, a seal number, and / or a reservation code. The method may further include combining partial identifier information from the plurality of cameras to resolve a complete vehicle identifier of the one or more vehicle identifiers in response to determining that at least one vehicle identifier is incomplete. Executing the one or more machine learning models to detect the one or more vehicle identifiers and the one or more vehicle features may include applying one or more models to detect a presence and location of the one or more vehicle identifiers and classify a type of the vehicle.

[0011] In some embodiments, the method further includes selecting one or more frames from the image data for the optical character recognition based one at least one of a detection confidence, a bounding box area, and a relative velocity of the one or more vehicle identifiers in the image data. The one or more vehicle features, in some examples, include a make, a model, a color, a trailer type, and / or physical damage of the vehicle. The method may further include detecting tailgating by analyzing axle counts and / or sensor data to determine that more than one vehicle entered the secured yard. The method may further include buffering the image data and adjusting frame processing rates based on vehicle presence in the lane.

[0012] In another embodiment, a vehicle recognition system includes one or more computer readable storage media, one or more processors operatively coupled with the one or more computer readable storage media, and program instructions stored on the one or more computer readable storage media. The program instructions, when executed by the one or more processors, direct the system to detect, based on image data received from a plurality of cameras positioned to capture different views of a lane into a secured yard, a vehicle entering the lane and track the vehicle across the plurality of cameras as the vehicle moves through the lane. The program instructions further direct the system to execute one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle and apply optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers. The program instructions further direct the system to analyze the text-based representation of the one or morevehicle identifiers and the one or more vehicle features to generate a vehicle identification result and output the vehicle identification result for use in making an access decision for the vehicle.

[0013] In yet another embodiment, one or more computer-readable storage media have program instructions stored thereon that, when executed by a computing apparatus, direct the apparatus to detect, based on image data received from a plurality of cameras positioned to capture different views of a lane into a secured yard, a vehicle entering the lane and track the vehicle across the plurality of cameras as the vehicle moves through the lane. The program instructions further direct the computing apparatus to execute one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle and apply optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers. The program instructions further direct the computing apparatus to analyze the text-based representation of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result and output the vehicle identification result for use in making an access decision for the vehicle.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Many aspects of the disclosure may be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views. While several embodiments are described in connection with these drawings, the disclosure is not limited to the embodiments disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.

[0015] Figure 1 illustrates an operational environment in accordance with some embodiments of the present technology.

[0016] Figure 2 illustrates an architecture overview in accordance with some embodiments of the present technology.

[0017] Figure 3 illustrates a flowchart for a vehicle recognition process in accordance with some embodiments of the present technology.

[0018] Figure 4 illustrates a flowchart for vehicle access control in accordance with some embodiments of the present technology.

[0019] Figure 5 illustrates a vehicle identification process in accordance with some embodiments of the present technology.

[0020] Figures 6A-5C illustrate sequence diagrams for vehicle recognition and access control in accordance with some embodiments of the present technology.

[0021] Figure 7 illustrates a flowchart for timeline generation in accordance with some embodiments of the present technology.

[0022] Figure 8 illustrates an access control event record in accordance with some embodiments of the present technology.

[0023] Figure 9 illustrates a dashboard provided by an access control engine in accordance with some embodiments of the present technology.

[0024] Figure 10 illustrates a table with example equipment states in accordance with some embodiments of the present technology.

[0025] Figure 11 illustrates a dashboard provided by an access control engine in accordance with some embodiments of the present technology.

[0026] Figure 12 illustrates a dashboard provided by an access control engine in accordance with some embodiments of the present technology.

[0027] Figure 13 illustrates a dashboard provided by an access control engine in accordance with some embodiments of the present technology.

[0028] Figure 14 illustrates a computing system suitable for implementing the various operational environments, architectures, processes, scenarios, and sequences discussed below with respect to the other Figures.DETAILED DESCRIPTION

[0029] The present technology relates to systems and methods for automated vehicle recognition and identification in transportation yards. More specifically, disclosed herein is an advanced vision system that leverages multi-camera computer vision and machine learning to detect, track, and identify transport equipment (e.g., tractors, trailers, intermodal containers, and personal vehicles) as they enter, exit, and move within secured yard environments. By processing and analyzing image data from multiple viewpoints, the vision system addresses longstanding challenges in accurately recognizing vehicles, extracting identifiers, and providing reliable, real-time information to support yard security and operational efficiency.

[0030] Transportation yards are a critical component of the modern supply chain, serving as secure hubs for the staging, transfer, and temporary storage of transport equipment. These facilities manage a high volume of vehicle movements, often under tight scheduling constraintsand with a need for real-time visibility into yard inventory. The operational complexity is further heightened by the prevalence of multi -piece equipment, such as tractors and trailers that may arrive or depart separately, requiring precise recognition and tracking of each component and their associations over time.

[0031] Historically, vehicle recognition and equipment tracking in yards have relied on manual processes or isolated sensor technologies. Guards may be stationed at entry points to visually inspect vehicles, check driver credentials, and record equipment identifiers. Alternatively, some facilities employ basic sensor systems, such as single cameras or keypad entry pads, to automate portions of the process. However, both of these approaches are prone to errors, delays, and inconsistencies, particularly in busy or dynamic yard environments. Manual data entry can be slow and subject to oversight, while isolated sensors often fail to capture the full context of a vehicle’ s identity, especially when identifiers are partially obscured or distributed across multiple vehicle components.

[0032] A further challenge is the integration and synchronization of diverse visual data streams (such as images from multiple cameras) to create a unified and accurate record of each vehicle event. Existing systems often produce fragmented or incomplete information, making it difficult to reliably identify equipment, resolve ambiguities, and maintain an accurate chain of custody for assets moving through the yard. Smaller operators, in particular, may lack the resources or expertise to implement sophisticated vision-based tracking solutions, resulting in increased vulnerability to theft, miscommunication, and operational inefficiencies.

[0033] The vehicle recognition system disclosed herein is designed to address these shortcomings by providing a comprehensive, automated solution for accurate vehicle identification and tracking within secured yard environments. In accordance with some embodiments, the vehicle recognition system receives video data from multiple cameras positioned to capture different views of a lane, and processes this data using computer vision and machine learning models to detect vehicles, extract identifiers (e.g., license plate numbers, truck numbers, trailer numbers, Department of Transportation (DOT) numbers), and analyze physical features (e.g., make, model, color, trailer type, visible damage). By integrating and analyzing these diverse visual data streams, the vision system generates reliable, real-time vehicle identification results, even in cases where identifiers may be partially obscured or distributed across multiple vehicle components.

[0034] The vehicle recognition system disclosed herein may operate as a core component within a broader access control architecture for yard management. The primary function of the vision system is to deliver accurate, real-time vehicle recognition results — including detectedidentifiers, features, and associated imagery — which may then be provided to other components of the access control system. These downstream components, such as the access control engine, yard management modules, and the like, may use the vehicle recognition data to generate and maintain persistent equipment profiles, associate recognition events with historical records, and support comprehensive chain-of-custody tracking for each piece of equipment.

[0035] To enhance both security and efficiency, the vehicle recognition system, as well as other components of the broader access control system, may integrate with multimodal driver interaction workflows. These may include, but are not limited to, an Al-driven voice agent that interacts with drivers at the gate, collects additional information, and provides instructions in multiple languages. The system can also support QR code workflows, enabling drivers to upload documents or identification via their mobile devices, further reducing friction and minimizing the need for physical contact or manual data entry. Such multimodal integration not only streamlines the check-in and check-out process but also ensures that all required information is collected and validated in real time. In some embodiments, the system may further support biometric authentication workflows, such as capturing facial images for face matching against government-issued identification, or performing cross-checks between ID document OCR results and live biometric data. These biometric tie-ins can enhance security by verifying that the individual presenting the credentials matches the authorized driver profile, and by providing an additional layer of identity validation during yard access events.

[0036] The vehicle recognition system, in some examples, operates in a fully automated mode, continuously processing video data and updating vehicle records without human intervention. The system may also be configured to support human-in-the-loop workflows, allowing operators to monitor live camera feeds, review recognition results, annotate events, and override automated decisions as needed. This is particularly valuable in scenarios where exceptions or anomalies are detected, or where regulatory compliance requires human validation.

[0037] Additionally, the vehicle recognition system may be deployed in both cloud-based and on-premises (“edge”) deployments, as well as hybrid configurations. These flexible deployment options allow yard operators to select the configuration that best fits their operational requirements, security policies, and connectivity constraints. The vehicle recognition system may cache operational data and continue processing locally in the event of network outages, thereby ensuring continuous operation and reliability.

[0038] The access control system disclosed herein, including the vehicle recognition system, may also provide robust analytics and reporting capabilities. By aggregating and analyzing vehicle recognition event data, the broader system can deliver insights into yard utilization, equipment dwell times, vehicle flow, and operational bottlenecks. Dashboards and reports can be customized for different user roles, from yard managers to security personnel to corporate logistics teams, supporting data-driven decision-making and continuous improvement.

[0039] The vehicle recognition system described herein provides significant technical effects by automating and optimizing the process of vehicle identification and tracking within secured yard environments. By leveraging multi-camera computer vision, advanced machine learning models, and data correlation, the system enables accurate detection, tracking, and extraction of vehicle identifiers and features — even in challenging scenarios where identifiers are partially obscured, distributed across multiple vehicle components, or captured from suboptimal angles. This technical capability allows for reliable, real-time recognition of a wide variety of transport equipment, including complex multi-piece configurations such as tractors and trailers.The vehicle recognition system’s ability to process and correlate video data from multiple viewpoints reduces the need for manual inspection and data entry, minimizing human error and increasing throughput at yard entry and exit points. By providing high-confidence, machine- readable vehicle identification results, the system supports downstream automation for access control, equipment tracking, and security auditing.

[0040] In addition, the vehicle recognition system enhances operational efficiency by streamlining the vehicle check-in and check-out process, enabling faster and more consistent yard throughput. The automated generation of detailed recognition records — including images, extracted identifiers, and detected features — supports robust analytics, auditing, and compliance reporting. Collectively, these technical effects result in a more secure, efficient, and transparent yard management environment, with improved accuracy, reduced operational costs, and greater scalability.

[0041] As used herein, “image data” refers to any visual data captured by a camera, including but not limited to still images, sequences of images, or video streams. Image data may be obtained as a single frame, a burst of frames, or as a continuous video stream. The terms “image,” “frame,” and “video” may be used interchangeably unless otherwise specified. Moreover, while many examples described herein refer to the use of video data or video streams, it should be understood that the same processes, systems, and methods are equallyapplicable to still images or sequences of still images. The technology disclosed is not limited to continuous video streams; rather, any form of image data, whether obtained as a single still image, a burst of images, or a video stream, may be used interchangeably within the context of the present invention. Accordingly, references to “video,” “video data,” or “video streams” throughout this disclosure are intended to encompass still images and other forms of image data unless otherwise specified.

[0042] Figure 1 depicts operational environment 100, which is representative of a flexible, modular system capable of supporting a wide range of deployment scenarios, equipment types, and operational requirements, including multi-piece equipment, multimodal driver interaction, and real-time access control for secured yards. Operational environment 100 includes transport vehicle 101, yard 103, transport vehicles 105A-C, yard access system 107, and gate 111. Yard access system 107 includes cameras 107A-C and lane monitor 109. Transport vehicle 101, including a tractor and a trailer, is shown approaching yard 103. Yard 103 contains multiple transport vehicles, transport vehicles 105A-C, which may each represent a tractor, a trailer, a combination thereof, or another vehicle type.

[0043] Yard access system 107 is positioned near the entrance to yard 103 and may be embodied as a kiosk, pedestal, or a distributed set of sensors and devices. Yard access system 107 includes cameras 107A-C but may include additional or fewer cameras in other embodiments. Camera 107A is mounted on the kiosk of yard access system 107. Camera 107B is located off the kiosk with a different view of the lane. Camera 107C is also located off the kiosk with another alternative view of the lane. Yard access system 107 may include any number of additional cameras, which may be mounted on the kiosk, on nearby poles, or at other locations to capture images of the front, sides, rear, and top of transport vehicle 101. The cameras are configured to extract identification information such as license plate (LP) numbers, state of registration, United States Department of Transportation (USDOT) numbers, truck numbers, trailer numbers, motor carrier numbers, vehicle identification numbers (VINs) and other unique identifiers. In some embodiments, the cameras may include infrared, lidar, or other sensing modalities for enhanced detection in low-light or adverse weather conditions. The cameras may also be configured to help detect physical properties of the equipment, such as make, model, color, trailer type, visible damage (e.g., dents, scrapes, missing mudflaps), compliance with equipment standards, presence of required safety features, the condition or presence of trailer seals or placards, and the like.

[0044] Yard access system 107 further includes at least one microphone and speaker for two-way audio communication with the driver. The microphone and speaker enable workflowssuch as Al-based voice agent interactions to request additional information (e.g., trip number, load type, or seal number), provide instructions in multiple languages, or guide the driver through authentication without requiring physical contact. The screen and keypad of yard access system 107 allow for input of access codes, reservation numbers, responses to visual prompts, and the like. The keypad may be a physical device or a touchscreen and may be supplemented by contactless input options that enable the driver to enter or upload information using a mobile device or other device. Such information may be transmitted to yard access system 107 via Near Field Communication (NFC), Bluetooth, Wi-Fi, cellular networks, or similar wireless technologies. In some embodiments, the screen may display closed captions, QR codes for mobile workflows, or real-time feedback on the authentication process.

[0045] Yard access system 107 may also include additional sensors, such as radiofrequency identification (RFID) readers, barcode scanners, or environmental sensors to detect hazardous materials or monitor weather conditions. As transport vehicle 101 approaches, yard access system 107 detects its presence and begins capturing event data, including time-stamped images, sensor readings (such as axle counts for tailgate detection), and information provided by the driver via voice, keypad, or mobile device. In some embodiments, tailgating detection may also be performed using video analytics from the cameras, such as by analyzing the number and sequence of vehicles detected in the image data to determine if more than one vehicle enters the secured yard during a single access event. Detection of the presence of transport vehicle 101 may be accomplished using motion sensors, video analytics, induction loops embedded in the roadway, RFID readers, or other proximity detection technologies integrated with yard access system 107.

[0046] Lane monitor 109, as illustrated in Figure 1, is a vehicle recognition component of yard access system 107 and is responsible for orchestrating the collection, processing, and management of event data at the entry point of yard 103. Lane monitor 109 is operatively coupled with cameras 107A-C and other sensors within yard access system 107 and serves as the primary computing and control unit for executing vehicle recognition and monitoring workflows. In various embodiments, lane monitor 109 may be implemented as an edge computing device, an embedded processor within a kiosk or pedestal, or a dedicated server located on-site.

[0047] Lane monitor 109 receives video streams and sensor data from the cameras and other input devices and coordinates the execution of computer vision and machine learning models to detect, track, and identify vehicles as they approach and move through the lane. This includes extracting vehicle identifiers such as license plate numbers, truck numbers, trailernumbers, and DOT numbers, as well as analyzing physical features like make, model, color, trailer type, and visible damage. Lane monitor 109 may also synchronize and buffer data from multiple cameras to ensure accurate multi-view analysis and correlation of vehicle information.

[0048] In addition to processing visual data, lane monitor 109 interfaces with other components of yard access system 107, such as microphones, speakers, keypads, and screens, to facilitate multimodal driver interactions. For example, lane monitor 109 may trigger AI- based voice agent workflows to request additional information from the driver, display prompts or QR codes on the screen, or receive input from the keypad or mobile devices. Lane monitor 109 may further aggregate sensor readings, such as axle counts or RFID scans, to enhance vehicle detection and support advanced features like tailgate detection or hazardous material monitoring.Lane monitor 109 is designed for robust, real-time operation and may function autonomously or in coordination with remote access control engines or cloud-based services.

[0049] In various embodiments, lane monitor 109 and its associated computer vision and machine learning models may be deployed in different computing environments to suit operational requirements and infrastructure constraints. In some implementations, all models and processing logic are executed locally on the edge, such as within an embedded processor in the kiosk, a dedicated on-site server, or an industrial edge computing device. This edgebased deployment enables low-latency, real-time vehicle recognition and decision-making, and allows the system to continue operating even during network outages or periods of limited connectivity. In other embodiments, some or all of the vehicle recognition models may be hosted remotely in the cloud, with lane monitor 109 acting as a gateway that streams video data or selected image frames to cloud-based services for processing. This approach can leverage scalable cloud resources for more computationally intensive tasks, facilitate centralized model updates, and support advanced analytics or integration with enterprise systems. Hybrid configurations are also possible, where certain models or preprocessing steps are performed at the edge for immediate responsiveness, while more complex inference or data aggregation is handled in the cloud.

[0050] Captured event data from the yard access system — such as images, video streams, sensor readings, and driver-provided information — may be processed locally by the lane monitor or transmitted in real time to other components of the overall access control system. In some embodiments, the lane monitor and its associated models perform vehicle detection, identifier extraction, and initial analysis entirely on the edge, within the yard access system itself. In other embodiments, some or all of these tasks may be distributed to off-sitecomponents, such as a cloud-based access control engine, which can aggregate, analyze, and supplement the recognition data with additional context, such as operational plans, reservation systems, and historical records. Depending on deployment, the system may support a range of workflows for vehicle identification and authorization. For example, if identification information is missing or incomplete (e.g., partially obscured license plate or ambiguous trailer number) the vehicle recognition system or a connected access control engine may synthesize partial information from multiple sources, including prior access events, driver input, and backend operational data. The system may prompt the driver for additional details or request document uploads via QR code workflows, with these interactions handled locally or remotely.

[0051] Access decisions, such as whether to open a gate or allow entry, may be made by the lane monitor on the edge, by a remote access control engine, or through a combination of both, depending on system configuration and connectivity. The system may also monitor for tailgating or unauthorized entry by analyzing axle counts, motion events, or video feeds from multiple cameras and sensors, with these analytics performed locally or in the cloud. After a vehicle is authorized for entry, the system may inform the driver of their assigned dock, bay, or parking location via the kiosk screen, voice agent, or mobile device. Ongoing guidance and interaction with the driver throughout the yard can be provided by the Al voice agent or mobile workflows, with instructions dynamically updated based on yard conditions, operational plans, or customer requirements.

[0052] All event data — including images, audio recordings, sensor readings, and metadata — may be logged and associated with persistent equipment and driver profiles, supporting longitudinal tracking, chain of custody requirements, and comprehensive audit trails for security and operational analysis. The access control system maintains associations between tractors and trailers over time, even as equipment is decoupled and reassigned within the yard. In alternative embodiments, the vehicle recognition system and other components of the access control architecture may support additional features such as automated damage detection, integration with third-party systems (e.g., TMS, YMS, ERP platforms), and escalation workflows for human-in-the-loop intervention. The system is designed to operate reliably in environments with intermittent connectivity, caching operational data locally and synchronizing with cloud services when available.

[0053] Many of the same processes and system interactions may apply for both vehicle entry and exit to provide comprehensive tracking, auditing, and operational analysis for all yard movements. Upon departure, yard access system 107 may again detect the presence of a vehicle, capture relevant event data, and authenticate the exiting equipment and driver. Thesystem may verify that the departing tractor and trailer match the expected configuration, check for any changes in equipment status or physical condition, and update inventory and chain-of- custody records accordingly. Event data including images, sensor readings, and driver- provided information may be logged for the egress event, supporting comprehensive tracking, auditing, and operational analysis for both ingress and egress scenarios.

[0054] Figure 2 illustrates operational architecture 200, an example operational architecture that includes yard access system 107, gate 111, access control engine 201, database 235, video and image store 237, client devices 239, and third-party systems 241. Yard access system 107 includes cameras 107 A-C, lane monitor 109, microphone 203, speaker 205, keypad 207, screen 209, voice agent 211, and gate actuation 213. Lane monitor 109 includes video streamers 215, time manager 217, frame buffer 219, inference pipeline 221, state manager 223, vehicle updater 225, vehicle tracker 227, OCR manager 229, uploader 231, and debug visualizer 233.

[0055] As shown in Figure 1, yard access system 107 may be positioned at the entry or exit point of a secured yard and serves as the primary interface for transport vehicles and drivers. Yard access system 107 may be embodied as a kiosk, pedestal, and / or a distributed set of sensors and devices, and may be installed on-site at the yard entrance, at multiple gates, or in other strategic locations. Cameras 107 A-C are configured to capture images and video of transport vehicles from multiple viewpoints, including the front, sides, rear, and top, to extract identification information such as license plate numbers, state of registration, department of transportation (e.g., USDOT) numbers, truck numbers, trailer numbers, motor carrier numbers, VINs, and other unique identifiers. The cameras, in coordination with lane monitor 109, are configured to detect physical properties of the equipment, such as make, model, color, trailer type, visible damage, compliance with equipment standards, and the presence or condition of trailer seals or placards. In some embodiments, cameras 107A-C may include infrared, lidar, or other advanced sensing modalities for enhanced detection in low-light or adverse weather conditions.

[0056] Lane monitor 109 serves as the central processing and control unit within yard access system 107, orchestrating the collection, analysis, and management of video and sensor data from multiple cameras and input devices positioned at the yard entrance. The lane monitor is responsible for executing the vehicle recognition workflows, including detecting, tracking, and identifying vehicles and their associated identifiers as they move through the lane. In various embodiments, lane monitor 109 may operate as an edge computing device embeddedwithin the yard access system or as part of a distributed architecture in coordination with cloudbased or remote components.10057] In operation, lane monitor 109 orchestrates a continuous workflow in which video streams from multiple cameras are received and synchronized, frames are buffered and assembled into scenes, and machine learning models are executed to detect vehicles, extract identifiers, and analyze physical features. Detected vehicles are tracked across frames and camera views, with the best image regions selected for optical character recognition to convert visual identifiers into machine-readable text. Lane monitor 109 maintains and updates vehicle state and metadata throughout the recognition process, ultimately generating a comprehensive vehicle recognition result that includes images, identifiers, features, and associated data. This result is then transmitted to downstream systems for use in access control, auditing, or operational management, while optional visualization and debugging tools support real-time monitoring and system maintenance.

[0058] Video streamers 215 are responsible for receiving and decoding real-time video streams from at least cameras 107A-C positioned to capture different views of the lane. Each video streamer 215 operates on a dedicated thread, ensuring that frame acquisition from each camera is not blocked or delayed by downstream processing. This design helps maintain temporal alignment and minimize frame loss, supporting a variety of video protocols such as real time streaming protocol (RTSP) and accommodating different camera resolutions and frame rates as required by the deployment.

[0059] Time manager 217 manages synchronization of the video streams and controls frame skip rates for each camera. Time manager 217 maintains a schedule for when frames should be processed from each camera, dynamically adjusting the frame processing rate based on the current operational state — such as whether a vehicle is approaching, idle, or crossing the lane. This adaptive frame management allows conservation of computational resources during periods of inactivity while increasing processing fidelity when vehicle activity is detected. Time manager 217 also ensures that frames from different cameras are temporally aligned, enabling the construction of synchronized scenes for multi-view analysis.

[0060] Frame buffer 219 is a thread-safe data structure that stores frames from all cameras, organizing them into scenes based on their timestamps or arrival times. Each scene represents a set of frames from the different cameras that correspond to the same moment in time. Frame buffer 219 supports efficient retrieval and management of scenes for downstream processing and may include mechanisms for discarding stale frames or scenes that are no longer relevant.Frame buffer 219 is also responsible for passing scenes to inference pipeline 221 for batch processing.10061] Inference pipeline 221 is a component responsible for executing machine learning models on the buffered scenes. Inference pipeline 221 may run on a graphics processing unit (GPU) or other hardware accelerator to maximize throughput. Inference pipeline 221 may apply a series of models to each scene, including object detection models to identify vehicles and localize vehicle identifiers (e.g., license plate, truck number, trailer number, DOT number), as well as classification models to determine vehicle type, trailer type, and other physical features. The inference results include bounding boxes, class labels, and confidence scores for each detected object or identifier. Inference pipeline 221 may also include models for detecting visible damage or missing components on the vehicles, and may support ensemble or sequential model execution to improve detection accuracy. Examples of models that may be used within inference pipeline 221 include but are not limited to convolutional neural networks (CNNs) for object detection, transformer-based models for advanced image understanding, and specialized classification or segmentation models for identifying vehicle make, model, color, trailer type, and detecting physical damage. The output of inference pipeline 221 is passed to state manager 223 for further processing and integration with vehicle tracking logic.

[0062] In some embodiments, the inference pipeline leverages advanced model architectures tailored to the unique challenges of yard environments. For example, vision transformers may be specifically trained to recognize stacked or vertically oriented text commonly found on trailers and containers. OCR ensembles may be fine-tuned on yardspecific fonts, non-standard identifier placements, and weathered or damaged markings to improve recognition accuracy. The system may also utilize multi-head attention mechanisms to correlate identifiers across multiple views, and employ domain-adapted models for detecting regulatory placards, seal numbers, or custom carrier logos. These specialized models are selected and trained to address the high variability and complexity of real-world yard operations, providing robust and reliable vehicle and identifier recognition.

[0063] State manager 223 is responsible for orchestrating the vehicle recognition workflow. State manager 223 maintains a representation of each vehicle as it moves through the lane, updating its state (e.g., approaching, capturing, crossing, or crossed) based on detection results and scene analysis. State manager 223 coordinates with vehicle tracker 227, which associates detections across frames and cameras to maintain consistent vehicle tracks and resolve ambiguities when multiple vehicles are present. State manager 223 also manages the selection of the best image crops for each identifier, using criteria such as bounding boxarea, detection confidence, and image quality, and passes these selections to vehicle updater 225.

[0064] Vehicle updater 225 is responsible for updating the persistent state of each vehicle, including storing the best available images, recognized identifiers, and associated metadata. Vehicle updater 225 ensures that the most accurate and complete information is maintained for each vehicle as it progresses through the recognition workflow. Vehicle tracker 227 works in conjunction with state manager 223 to maintain unique vehicle tracks, handle vehicle reidentification across camera views, and manage the association of identifiers and features with the correct vehicle instance.

[0065] OCR manager 229 is responsible for applying optical character recognition (OCR) algorithms to the selected image regions containing vehicle identifiers. OCR manager 229 loads and manages one or more OCR models, which may be executed on a dedicated thread or hardware accelerator. The OCR process converts the visual representation of each identifier into machine-readable text, which is then associated with the corresponding vehicle track. OCR manager 229 may also perform post-processing, such as filtering or validation of the recognized text, to improve accuracy and reliability of the extracted identifiers.

[0066] Uploader 231 is responsible for transmitting the final vehicle recognition results, including images, identifiers, features, and metadata, to downstream systems such as access control engine 201, operator dashboards, or cloud storage. Uploader 231 may operate asynchronously to avoid blocking real-time processing and can be configured to support various data formats and communication protocols. Debug visualizer 233 provides real-time visualization of scenes, detections, tracks, and recognition results for development, monitoring, or troubleshooting purposes. Debug visualizer 233 can display bounding boxes, confidence scores, and other annotations overlaid on the video streams, and may support interactive review of historical scenes or events. By providing developers with clear, real-time insight into model outputs and decision processes, the debug visualizer improves transparency and model accountability, enabling more effective validation, auditing, and continuous improvement of the system’s Al components.

[0067] The arrangement, naming, and interconnection of modules 215-233 described above are provided as illustrative examples of how the functionalities of lane monitor 109 may be organized and implemented. In practice, these modules may be combined, subdivided, or structured differently depending on system architecture, deployment requirements, or customer preferences. For instance, all functionalities could be implemented within a single monolithic software component, or further divided into additional specialized modules to address uniqueoperational needs or to support future scalability. The boundaries between modules are not fixed, and certain features or processes may span multiple modules or be handled by shared services. The specific arrangement, naming, or presence of these modules is not intended to be limiting, exhaustive, or required; rather, they are presented to convey the breadth and depth of capabilities that lane monitor 109 can provide. Alternative implementations may employ different combinations, groupings, or layers of functionality, and the system may evolve over time to incorporate new technologies, workflows, or integration points as operational requirements change.

[0068] Microphone 203 and speaker 205 enable two-way audio communication between the system and the driver, supporting workflows such as Al-based voice agent interactions, real-time instructions, and multi-language support. The voice agent 211, implemented as an Al-driven module, can interact with drivers in natural language, request additional information (such as trip number, load type, or seal number), and provide guidance throughout the authentication process.

[0069] Screen 209 may display visual prompts, closed captions, quick response (QR) codes for mobile workflows, real-time feedback on the authentication process, and the like. Keypad 207 allows drivers to input access codes, reservation numbers, or respond to prompts, and may be implemented as a physical device or a touchscreen. The keypad and screen may be supplemented by contactless input options, enabling drivers to enter or upload information using a mobile device or other device via NFC, Bluetooth, Wi-Fi, cellular networks, or similar technologies. Gate actuation 213 interfaces with gate 111 to physically enforce access decisions by opening or closing the gate in response to commands from access control engine 201 or yard access system 107.

[0070] As described, the system may support mobile device workflows that enable drivers to interact with the yard access system using their smartphones, tablets, or other personal devices. For example, the system may display a QR code on the kiosk screen, which the driver scans to access a secure web form for uploading documents such as a driver’s license or bill of lading. Information submitted via the mobile device is securely linked to the current access event and, where applicable, to the driver’s persistent profile.

[0071] Voice agent 211 operates as an Al-based conversational interface, enabling handsfree, real-time communication between the system and the driver. Voice agent 211 may be implemented using advanced speech recognition and natural language understanding models, such as deep neural networks, transformer-based architectures, or large language models, which are trained to interpret spoken driver responses and generate contextually appropriateprompts or instructions. Processing for voice agent 211 may be performed locally on yard access system 107 for low-latency, edge-based deployments, or in the cloud as part of access control engine 201, depending on system configuration and connectivity. The voice agent is capable of multi-language support, dynamic dialogue management, and context-aware questioning, allowing it to adapt its prompts based on previously collected data or operational requirements. In some embodiments, voice agent 211 can escalate to a human operator or switch to text-based interaction on screen 209 if speech recognition confidence is low or if the driver prefers. The underlying artificial intelligence (Al) models may be continuously updated and retrained using anonymized interaction data to improve accuracy, support new languages, and expand the range of supported workflows.

[0072] Voice agent 211 may interact with lane monitor 109 to obtain additional information needed for vehicle identification or access control. For example, if lane monitor 109 determines that certain vehicle identifiers are missing, ambiguous, or require further verification, it can trigger voice agent 211 to prompt the driver for supplementary details such as a trip number, load type, seal number, or reservation code. The information collected by voice agent 211 can then be combined with the visual recognition results generated by lane monitor 109 to create a more complete and reliable vehicle access record. This collaborative interaction between lane monitor 109 and voice agent 211 enables the system to resolve uncertainties, fill in data gaps, and ensure that all necessary information is gathered for accurate and efficient yard operations.

[0073] Access control engine 201 serves as the core decision-making and orchestration component within operational architecture 200, responsible for integrating, analyzing, and acting on data from across the yard access system, vision system, client devices, and third- party systems. Access control engine 201 collects and synthesizes data from all available sources, including images, sensor readings, driver inputs, and backend operational data, to reconstruct the full context for each access event. It is designed to handle partial or incomplete information by leveraging historical records, prior access events, and contextual clues to fill in missing data and ensure robust event reconstruction, even when some identifiers may be obscured or unavailable.

[0074] Access control engine 201 performs authentication and validation of drivers and associated equipment by cross-referencing extracted identifiers with persistent profiles, operational plans, and reservation systems to verify that the equipment and driver are authorized for the specific access event. It may also perform document and ID verification, integrate with external databases or compliance systems, and apply configurable business rules,access policies, and operational constraints to each access attempt. Based on the results of these analyses, access control engine 201 determines whether to grant, deny, or escalate the access request, and can support complex policy enforcement, exception handling, and dynamic adaptation to operational requirements.

[0075] In addition to access deci si on -making, access control engine 201 is responsible for recording access events, maintaining persistent profiles for equipment and drivers, and supporting audit trails, regulatory compliance, and operational analytics. It enables real-time monitoring, manual review, annotation, and override of automated decisions, and provides tools for operators to interact with drivers, review event data, and resolve issues efficiently. Access control engine 201 also supports context-aware, multi-channel interactions with drivers and users, including voice-based workflows, screen-based prompts, and mobile device interactions, and can manage document uploads, QR code workflows, and real-time feedback.

[0076] Access control engine 201 may be implemented as a cloud-based service, an onpremises server, or a hybrid deployment, and can be distributed across multiple locations for redundancy, scalability, and resilience. Its flexible architecture allows for high availability, real-time decision-making, and continuous operation even in the event of network disruptions or hardware failures, and supports integration with analytics, reporting, customer-facing portals, billing systems, and external APIs as needed. By supporting both centralized and edgebased processing, access control engine 201 can offload resource-intensive tasks, maintain system responsiveness, and ensure that critical access control and event management functions remain available under varying network and infrastructure conditions.

[0077] Access control engine 201 may leverage machine learning models in various processes to enhance decision-making, data analysis, and user interaction. For example, clustering or anomaly detection models may be used to identify patterns or inconsistencies in event data. Deep neural networks or ensemble models may be used for document verification and fraud detection. Reinforcement learning or rule-based Al may be used for adaptive policy enforcement. Moreover, natural language processing models, such as transformer-based architectures, may be used to interpret and respond to driver input. The use of machine learning may enable the system to continuously improve its performance, adapt to new operational scenarios, and provide robust, context-aware access control.

[0078] Database 235 serves as the central repository for structured data, including but not limited to event logs, equipment and driver profiles, operational plans, and historical records. Database 235 may be implemented as a single database instance or distributed across multiple nodes to provide scalability, redundancy, and high availability. In some embodiments,database 235 supports real-time queries from access control engine 201 and can synchronize with cloud-based or on-premises systems, ensuring that all access events and profile updates are persistently stored and retrievable for auditing, analytics, and compliance purposes.

[0079] Video and image store 237 is responsible for storing and archiving high-resolution video footage and still images captured by cameras 107A-C. Video and image store 237 may utilize cloud-based storage solutions, on-premises storage appliances, or a hybrid approach, depending on operational requirements and data retention policies. This component enables the system to maintain a comprehensive visual record of all access events, supporting later review for damage detection, incident investigation, timeline generation, and regulatory compliance. Video and image store 237 may also be integrated with analytics tools to facilitate automated searches, tagging, and retrieval of relevant footage.

[0080] Client devices 239 may encompass a wide range of user-facing hardware and interfaces that enable various stakeholders to interact with the access control system. A client may refer to any user or entity (e.g., yard operators, security personnel, administrative staff, or customers) who needs to access, monitor, or manage yard operations. Client devices 239 may include operator workstations located in a central office or security booth, clerk terminals at entry or exit points, mobile devices such as smartphones or tablets used by on-site staff, and interactive kiosks positioned at the yard for driver self-service. These devices may run dedicated applications, web-based dashboards, mobile apps, or the like, that provide real-time monitoring, manual review, annotation, and override of automated decisions. For example, an operator may use a workstation to view live camera feeds, review access event timelines, respond to escalations, or communicate directly with drivers via integrated audio or messaging features. In some scenarios, client devices 239 may be used by remote support teams or third- party service providers to manage multiple yards from a centralized location, enabling remote access, centralized oversight, and distributed facility management. Client devices 239 may also include specialized hardware for document scanning, badge reading, or biometric authentication, depending on the operational requirements of the yard or facility.

[0081] Third-party systems 241 represents a broad category of external platforms, databases, and services that interface with operational architecture 200 to provide supplemental data, validation, and integration with customer or partner ecosystems. These systems may include, but are not limited to, Transportation Management Systems (TMS) for managing freight and carrier assignments, Yard Management Systems (YMS) for tracking yard inventory and scheduling, and Enterprise Resource Planning (ERP) systems for handling business operations, resource allocation, and compliance. Third-party systems 241 may also encompassreservation and billing platforms that manage parking reservations, access codes, and customer invoicing, as well as external license plate recognition (LPR) vendors, compliance databases, and regulatory reporting services.

[0082] Access control engine 201 communicates with third-party systems 241 via secure application programming interfaces (APIs), webhooks, or other integration protocols. These integrations enable the system to validate appointments and reservations in real time, synchronize operational plans and schedules, and enrich equipment and driver profiles with external data sources. For example, when a transport vehicle arrives at the yard, access control engine 201 may query a customer’s TMS or YMS to confirm that the vehicle and driver are expected, verify load or seal numbers, or check for special handling requirements. Similarly, integration with billing platforms allows for automated invoicing based on equipment stays and access events, while compliance databases may be used to verify driver credentials, equipment status, or regulatory requirements.

[0083] In some embodiments, third-party systems 241 may also include external authentication providers, document verification services, or security and risk management platforms. These integrations can support advanced workflows such as real-time driver’s license verification, detection of fraudulent documents, or cross-checking against watchlists and compliance registries. The architecture is designed to be flexible and extensible, allowing for the addition of new third-party integrations as customer needs evolve or as new industry standards emerge.

[0084] Gate I l l is the physical mechanism that enforces access decisions at the yard entrance or exit. Gate 111 may be implemented as a barrier arm, sliding gate, rolling door, or other physical barrier, and is actuated by commands from yard access system 107 or directly from access control engine 201. Gate 111 may include embedded sensors to detect vehicle passage, confirm that only the authorized vehicle enters or exits, and monitor for tailgating or unauthorized access attempts. In some configurations, gate 111 can provide real-time status feedback to access control engine 201, supporting closed-loop control and enhanced security.

[0085] As described above, operational architecture 200 is designed for flexibility and resilience, supporting a variety of deployment models including fully cloud-based, fully onpremises (edge), or hybrid configurations. Components such as access control engine 201, yard access system 107, lane monitor 109, database 235, and video and image store 237 may be distributed or co-located depending on customer requirements, security policies, and network connectivity. The system supports continuous operation even during network outages by enabling local decision-making and data caching at the edge. Each component is modularand can be adapted or extended to accommodate new technologies, additional sensors, or evolving operational needs. Moreover, the components illustrated in operational architecture 200 are provided as one example configuration and are not intended to be limiting or exhaustive; in other embodiments, there may be fewer, additional, or different components and functionalities depending on specific deployment requirements and system evolution.

[0086] Figure 3 illustrates process 300. Process 300 represents an exemplary operation of vehicle recognition for managing ingress of transport vehicles into a secured yard in the context of operational environment 100 and / or operational architecture 200. The operations may vary in other examples. The operations of process 300, in some examples, are performed within one or more instances of yard access system and / or lane monitor 109. Process 300 may be implemented in program instructions in the context of the software and / or firmware elements. The program instructions, when executed by one or more processing devices of one or more suitable computing devices, direct the vehicle recognition system to operate as follows.

[0087] In operation, the vehicle recognition system detects a vehicle entering the lane by analyzing video data received from a plurality of cameras configured to capture different views of the lane (step 301). Detection may be accomplished using object detection models within inference pipeline 221, which process buffered frames to identify the presence of a vehicle based on features such as shape, size, and motion patterns. The system may also utilize motion detection algorithms, background subtraction, or changes in pixel intensity to identify new objects entering the field of view. The video streams from these cameras are received and synchronized by video streamers 215 and time manager 217, which buffer frames and assemble them into temporally aligned scenes, ensuring that frames from different cameras correspond to the same moment in time for accurate multi-view analysis.

[0088] As the vehicle moves through the lane, the vehicle recognition system tracks the vehicle across the plurality of cameras (step 303). This tracking, in some examples, is performed by state manager 223 and vehicle tracker 227, which associate detections across frames and camera views to maintain consistent vehicle tracks and resolve ambiguities when multiple vehicles are present. The vehicle recognition system may further utilize object detection models within inference pipeline 221 to identify the presence and location of vehicles in each scene, and to assign unique track identifiers to each detected vehicle.

[0089] The vehicle recognition system then executes one or more machine learning models to detect, from the video data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle (step 305). These identifiers may include, for example, a license plate number, truck number, trailer number, or Department of Transportation (DOT)number, while vehicle features may include make, model, color, trailer type, and visible damage. Inference pipeline 221 may apply a first model to detect the presence and location of vehicle identifiers and a second model to classify the type of vehicle or trailer, in some examples. In other examples, inference pipeline 221 may apply a single model to detect the presence and location of the vehicle identifiers and classify the type of vehicle or trailer. The system may also include models for detecting physical damage or missing components. For each detected vehicle identifier, the vehicle recognition system may select one or more frames or image regions in which the identifier is visible, based on detection confidence, bounding box area, or relative velocity of the identifier in the frame sequence.

[0090] In some embodiments, the vehicle recognition system is configured to select one or more frames from the image data for optical character recognition (OCR) based on a combination of factors that optimize the likelihood of accurate identifier extraction. When multiple frames of the same vehicle are available, the system may obtain different recognition results for a given identifier across those frames. To resolve discrepancies and select the most reliable result, the system employs an algorithm that evaluates each candidate frame or recognition result according to criteria such as image quality, camera angle, distance from the camera, speed of the vehicle, and the expected format or grammar of the identifier being recognized. For example, the system may prioritize frames where the identifier is in sharp focus, well-lit, and occupies a larger area of the image, or where the vehicle is moving slowly to minimize motion blur. Additionally, the system may apply domain-specific rules, such as recognizing that certain license plates or trailer numbers follow predictable patterns (e.g., a particular carrier’s license plates always begin with a specific letter, or trailer identifiers have a fixed number of digits).

[0091] The selected image regions are then processed by OCR manager 229, which applies one or more optical character recognition algorithms to convert the visual representation of each vehicle identifier into machine-readable text (step 307). OCR manager 229 may utilize one or more OCR models, which can be executed on a dedicated thread or hardware accelerator, and may include post-processing steps such as filtering, validation, or confidence scoring to improve the reliability of the extracted identifiers. If the system determines that the confidence score for a particular identifier is below a threshold, it may trigger an escalation workflow for human review or request additional information from the driver, supporting quality control and exception handling as described in dependent claims.

[0092] After extracting the text-based representations of the vehicle identifiers, the vehicle recognition system analyzes these identifiers in combination with the detected vehicle featuresto generate a unified vehicle identification result (step 309). This analysis may involve correlating partial or ambiguous identifier information from multiple camera views, combining data from different perspectives to resolve incomplete or conflicting readings, and associating the detected identifiers and features with the correct vehicle track. In some embodiments, the vehicle recognition system may also incorporate supplementary information provided by the driver through voice agent 211 or other input channels, if available. Additionally, the system may detect and annotate visible damage or missing components on the vehicle or trailer, and include such annotations in the vehicle identification result.

[0093] Once the unified vehicle identification result is generated, the vehicle recognition system outputs this result for use in downstream operations (step 311). The vehicle identification result may include machine-readable identifiers, detected vehicle features, associated images, damage annotations, and relevant metadata. This result is provided to other components of the access control system, such as access control engine 201, which may use the information to make an access decision for the vehicle. The vehicle identification result can also be transmitted to operator dashboards, client devices, or third-party systems for further processing, auditing, or compliance reporting. All relevant event data, including images, sensor readings, and driver-provided information, may be logged and stored for later retrieval, analysis, and compliance purposes.

[0094] Figure 4 illustrates process 400, which represents an exemplary operation performed by one or more components of yard access system 107, including lane monitor 109, for managing the ingress of transport vehicles into a secured yard. The operations of process 400 may be implemented in program instructions executed by one or more processing devices of yard access system 107, which may include a kiosk, a pedestal, and / or a distributed set of sensors, cameras, and devices positioned at the yard entrance.

[0095] In operation, yard access system 107 detects a vehicle approaching the entry point (step 401). Detection may be accomplished using motion sensors, video analytics from cameras 107A-C, induction loops embedded in the roadway, RFID readers, and / or other proximity detection technologies integrated with the system. Upon detecting the presence of a transport vehicle, yard access system 107 initiates the access event workflow.

[0096] Yard access system 107 then captures images of the vehicle (step 403). Cameras 107A-C, which may be mounted on the kiosk, on nearby poles, or at other strategic locations, capture images from multiple viewpoints — including the front, sides, rear, and top of the vehicle. These images are used to document the vehicle’s approach and provide the visual data necessary for subsequent identification and authentication steps.

[0097] Next, yard access system 107 extracts identification information from the captured images (step 405). This may involve lane monitor 109 running embedded computer vision and optical character recognition (OCR) models locally to identify license plate numbers, state of registration, USDOT numbers, truck numbers, trailer numbers, and other unique identifiers. In some embodiments, the system may also detect physical properties such as make, model, color, trailer type, or visible damage, and may utilize advanced sensing modalities like infrared or lidar for enhanced detection.

[0098] If the extracted identification information is incomplete, ambiguous, or does not meet the criteria required for authentication, yard access system 107 requests additional information from the driver (step 407). This request may be delivered through multiple interaction channels, including but not limited to voice-based prompts via voice agent 211, onscreen instructions on screen 209, or input requests via keypad 207. The system may prompt the driver for specific details such as a trip number, load type, seal number, reservation code, or other operational data relevant to the access event.

[0099] Yard access system 107 then receives the additional information from the driver (step 409). The driver may provide the requested data verbally, by entering it on the keypad or touchscreen, or by uploading documents or images using a mobile device via NFC, Bluetooth, Wi-Fi, or cellular networks. The yard access system, alone or in coordination with the access control engine, aggregates this supplementary information with the previously captured event data to build a more complete authentication package for the transport vehicle and its associated equipment.

[0100] Once all necessary information has been collected, yard access system 107 determines whether the vehicle is authorized to enter the yard (step 411). This determination may be made locally if the system is configured for edge-based decision-making, or the collected data may be transmitted to access control engine 201 for centralized analysis and authorization. The system evaluates the identification and supplementary information against operational plans, reservation systems, and business rules to decide whether to grant or deny access. If the vehicle is not authorized, the process may loop back to request further information, escalate the event for human review, or deny access to the secured yard.

[0101] If authorization is granted, yard access system 107 actuates the gate (step 413). Gate actuation 213 sends a command to gate 111, which may be a barrier arm, sliding gate, or other physical mechanism, to open and allow the authorized vehicle to enter the secured yard. The system may also monitor for tailgating or unauthorized entry by analyzing axle counts, motion events, or video feeds from multiple cameras and sensors.

[0102] Throughout process 400, yard access system 107 logs some or all of the relevant event data — including images, audio recordings, sensor readings, and driver-provided information — and communicates with access control engine 201 to ensure that a comprehensive record of the access event is generated and stored. This logged data may be transmitted in real time to access control engine 201 for aggregation, analysis, and long-term storage, or may be temporarily cached locally in scenarios where network connectivity is intermittent or unavailable. The persistent logging of event data supports later auditing, incident investigation, and operational analysis, and enables the system to maintain a robust chain of custody for all equipment and drivers entering or exiting the yard.

[0103] In some embodiments, yard access system 107 may also support additional features such as real-time feedback to drivers, escalation workflows for human-in-the-loop intervention, and integration with third-party systems for appointment validation or compliance checks. The system may be configured to operate autonomously, making access decisions and updating records without human intervention, or may support hybrid workflows where operators can monitor, review, and override automated decisions as needed.

[0104] Figure 5 illustrates vehicle identification process 500 that may be utilized by lane monitor 109 in accordance with some embodiments of the present technology. Vehicle identification process 500 leverages identifier detection module 501, OCR module 503, and unified reasoning module 505. The example shown in Figure 5 demonstrates how lane monitor 109 can leverage multiple camera views and advanced processing techniques to overcome common challenges in vehicle identifier extraction, such as partial occlusion, poor lighting, or non-standard identifier placement. By aggregating and reasoning over the outputs from different perspectives, the system increases the likelihood of accurately identifying the trailer number or other vehicle identifiers, even when individual views are incomplete or ambiguous. The final output of vehicle identification process 500 includes not only the deduced trailer number (in this case, AVK981), but also supporting data such as the original image crops, bounding box coordinates, confidence scores, and any relevant annotations or error flags.

[0105] In the example shown in Figure 5, identifier detection module 501 receives frames including frame 507, frame 509, and frame 511 captured by multiple cameras (e.g., cameras 107A-C) positioned to provide different viewpoints of a trailer as it moves through the lane. Identifier detection module 501 processes each frame to detect and localize potential vehicle identifiers, such as a trailer number, using computer vision techniques and machine learning models. The specific frames shown in Figure 5 may be selected because they represent the best available views for identifier extraction based on criteria such as image quality, boundingbox area, or detection confidence. Alternatively, the system may process a larger set of frames from each camera to maximize the likelihood of accurately capturing the vehicle identifier.10106] In the example of Figure 5, the lane monitor is extracting a trailer number from the side of a trailer. Identifier detection module 501 applies object detection algorithms to identify regions of interest within the frames such as bounding boxes around alphanumeric characters or number sequences that may correspond to the trailer identifier.

[0107] Once candidate regions are identified, identifier detection module 501 extracts the image crops corresponding to these bounding boxes from each camera view. These image crops are then passed to OCR module 503, which is responsible for converting the visual representations of the identifiers into machine-readable text. OCR module 503 utilizes one or more optical character recognition models, which can be executed on dedicated hardware or software threads, to process each image crop and output a text-based representation of the detected characters. The OCR process may include pre-processing steps such as image normalization, binarization, or noise reduction to improve recognition accuracy, as well as post-processing steps such as filtering or confidence scoring.

[0108] The text-based outputs from OCR module 503, which may include partial or ambiguous readings from different camera views, are then provided to unified reasoning module 505. Unified reasoning module 505 is responsible for analyzing and synthesizing the OCR results, along with any available contextual information, to deduce the most likely trailer number. This may involve correlating partial identifier information from multiple camera views, weighting the results based on detection confidence, bounding box area, or image quality, and applying logic to resolve conflicts or fill in missing characters. Unified reasoning module 505 may also incorporate supplementary information, such as driver-provided data or historical recognition results, if available, to further improve the accuracy of the identification.

[0109] In the illustrated example, unified reasoning module 505 successfully deduces the trailer number as AVK981, despite the partial and inconsistent readings from individual camera views. Various sub-components or logic blocks of unified reasoning module 505 may include but are not limited to modules for confidence scoring, data fusion, error correction, and bestguess selection, among others. Unified reasoning module 505 may utilize a wide range of data sources to improve the accuracy and reliability of the vehicle identification result. For example, the module may incorporate reservations and operational data, such as expected vehicle arrivals, scheduled equipment pairings, or customer assignments, to help resolve ambiguities or validate detected identifiers. Historical records, including prior access events, persistent equipment profiles, and previous identifier readings, may be referenced to providecontext or fill in missing information. Driver-provided information, such as data collected through voice agent 211, keypad entries, or mobile device uploads, can also be integrated into the reasoning process to supplement or confirm visual recognition results. Sensor and environmental data, including RFID scans, axle counts, or environmental sensor readings, may be used to further corroborate the identity or status of the vehicle. Contextual data, such as time of day, lane assignment, or the sequence of vehicles entering the yard, can provide additional clues for accurate identification. Unified reasoning module 505 may also generate system-level inferences by synthesizing partial or ambiguous data from multiple sources, applying logic to resolve conflicts, and weighting results based on detection confidence, image quality, or historical consistency.

[0110] It should be understood that the division of functionality among identifier detection module 501, OCR module 503, and unified reasoning module 505 is provided for illustrative purposes only. In practice, these modules may be combined into a single processing pipeline, further subdivided into additional specialized components, or implemented using alternative architectures depending on the specific requirements of the deployment, available hardware, or software design choices. The connections and data flow between these modules may also vary, and certain steps may be performed in parallel, asynchronously, or in a different sequence.

[0111] Figure 6A illustrates sequence diagram 600A depicting an exemplary operational scenario for access control at a secured yard, involving interactions among driver 601, gate 111, yard access system 107, lane monitor 109, and access control engine 201. This sequence diagram demonstrates the flow of information and control signals as a transport vehicle approaches the yard, is authenticated, and is either granted or denied access.

[0112] The process begins as driver 601 approaches gate 111 with a transport vehicle. Yard access system 107 detects the presence of the vehicle using one or more detection mechanisms, such as motion sensors, video analytics, induction loops, or RFID readers. Upon detection, yard access system 107 initiates the access event workflow by capturing images and / or video of the approaching vehicle using cameras 107A-C. These images and video are transmitted to lane monitor 109 for further analysis.

[0113] Lane monitor 109 receives the images and video from yard access system 107 and processes the visual data using computer vision and machine learning models. Lane monitor 109 extracts identification information — such as license plate numbers, state of registration, USDOT numbers, truck numbers, and trailer numbers — and selects the most relevant imagesfor authentication. The extracted identification information, along with selected images, is compiled as event data and transmitted to access control engine 201.

[0114] Access control engine 201 receives the event data and begins analyzing it to determine whether the identification information is complete and sufficient for authentication. This analysis may involve multiple layers of processing and validation. Initially, the system may parse the event data to extract structured identifiers — such as license plate numbers, USDOT numbers, truck numbers, and trailer numbers — using machine learning models and / or rule-based logic. Advanced machine learning techniques, including convolutional neural networks (CNNs) for image analysis and optical character recognition (OCR) engines for text extraction, may be employed in some implementations to interpret images and / or video streams received from lane monitor 109.

[0115] The extracted identifiers may then be cross-referenced against operational plans, reservation systems, and historical records using database queries and / or matching algorithms. Natural language processing (NLP) models may be used to interpret driver-provided information, such as spoken responses or text entries, in some embodiments. The system may also apply confidence scoring and anomaly detection models to assess the reliability and consistency of the identification data, flagging any ambiguities or discrepancies for further review. If the information is incomplete, ambiguous, or falls below predefined confidence thresholds, the system may trigger additional workflows — such as prompting the driver for more details or synthesizing partial information from prior events and contextual data.

[0116] Thus, if access control engine 201 determines that additional information is required (for example, if a license plate is partially obscured or a trailer number is ambiguous), it issues a request for additional information back to yard access system 107. Yard access system 107, in turn, prompts driver 601 for the requested supplementary data. This may be accomplished through voice-based prompts via voice agent 211, on-screen instructions, keypad input, mobile device workflows, or the like.

[0117] Driver 601 provides the requested additional information, which may include a trip number, load type, seal number, reservation code, or other operational data. Yard access system 107 captures this additional information and transmits it to lane monitor 109 if further processing or validation is needed (such as document or image analysis), or directly to access control engine 201 for inclusion in the authentication package.

[0118] Access control engine 201 again analyzes the additional information in conjunction with the previously received event data, which may include evaluating all available information against business rules, operational plans, and reservation systems to determinewhether the transport vehicle is authorized to enter the secured yard. If all authorization criteria are satisfied, access control engine 201 sends an access decision to yard access system 107. The access decision may include an explicit indication that the transport vehicle is authorized to enter the yard, and may further specify relevant details, such as identities of the tractor and trailer, the driver, the time of authorization, and any operational parameters or conditions for entry. In some embodiments, the access decision includes an instruction or flag for yard access system 107 to proceed with granting entry, such as by opening the gate. In response to receiving the access decision, yard access system 107 sends an open command to gate 111.

[0119] Gate 111 receives the open command and actuates the physical barrier (such as a barrier arm or sliding gate) to allow the authorized vehicle to enter the yard. Yard access system 107 also initiates tailgate monitoring by analyzing axle counts, motion events, or video feeds to detect and / or prevent unauthorized vehicles from entering behind the authorized vehicle. Tailgating monitoring may be performed in part by lane monitor 109.

[0120] Throughout the process, access control engine 201 generates and stores a comprehensive event record, including but not limited to the detected identification information, additional data provided by the driver, time-stamped images, and metadata. This event record is stored in database 235 and may be used for auditing, operational analysis, and compliance purposes. If tailgating or other anomalies are detected, the system updates the event record and timeline accordingly, supporting later review and incident investigation.

[0121] Figure 6B illustrates sequence diagram 600B, which depicts an alternative operational scenario for access control at a secured yard, involving interactions among driver 601, gate 111, yard access system 107, lane monitor 109, access control engine 201, and third- party systems 241. While many of the initial steps and component interactions are similar to those described in Figure 6A — including vehicle detection, image capture, identifier extraction, and the solicitation of additional information from the driver — Figure 6B includes the involvement of third-party systems 241 in the authentication and access decision process.

[0122] As in the previous scenario, the process begins with yard access system 107 detecting the presence of a transport vehicle and capturing images and video using cameras 107A-C. Lane monitor 109 processes the visual data to extract identification information and selects relevant images, which are then compiled as event data and transmitted to access control engine 201. Access control engine 201 aggregates the event data and constructs an authentication package, which may include identifiers for the tractor and trailer, driver- provided information, and any supplementary data collected during the interaction.

[0123] Unlike the scenario in Figure 6A, the authentication package is transmitted to third- party systems 241 for analysis and decision-making. Third-party systems 241 may represent one or more external platforms such as a customer’s Transportation Management System (TMS), Yard Management System (YMS), or other backend operational or compliance systems. In some cases, third-party systems 241 may also include human operators or security personnel employed by the yard owner, facility operator, or the like, who review the authentication package and make the final access decision based on their own business rules, operational requirements, or regulatory obligations.

[0124] The one or more third party systems receive the authentication package and may perform additional validation steps, such as cross-referencing the provided identifiers and driver information with appointment schedules, reservation databases, or compliance registries. The authentication package may be shared with third-party systems 241 through a variety of mechanisms, including secure application programming interfaces (APIs), web portals, direct database integrations, or even via automated or manual phone calls initiated by access control engine 201 or an operator thereof. For example, in some deployments, access control engine 201 may trigger an automated phone call or prompt a human operator to call the third-party contact, verbally relay the relevant information, and receive a verbal or keypad-based access decision in return. This flexibility allows the system to accommodate a wide range of customer workflows, from fully automated integrations to human-in-the-loop validation processes.

[0125] Third-party systems 241 may also request further information if the initial package is incomplete or ambiguous, prompting access control engine 201 and yard access system 107 to collect and transmit additional data from the driver as needed. This iterative, multi-channel approach ensures that all necessary information is gathered and validated, whether the decision is made by automated backend systems, human operators, or a combination of both.

[0126] Thus, once third-party systems 241 has completed its analysis, it returns an access decision to access control engine 201. This decision may be a grant or denial of access, or may include instructions for further escalation or manual review. Access control engine 201 then relays the decision to yard access system 107, which actuates gate 111 accordingly. As in the previous scenario, tailgate monitoring and event logging are performed to ensure security and maintain a comprehensive audit trail. Tailgating information, if any, may further be shared with third-party systems 241.

[0127] Throughout this process, event data including images, audio, sensor readings, and decision records are stored and associated with persistent equipment and driver profiles, supporting longitudinal tracking, compliance, and operational analysis. The involvement ofthird-party systems 241 enables integration with customer-specific business rules, external compliance requirements, and dynamic operational plans, allowing for highly customizable and extensible access control workflows.

[0128] Figure 6C illustrates sequence diagram 600C, which depicts another operational scenario for access control at a secured yard, involving interactions among driver 601, gate 111, yard access system 107, and lane monitor 109. While several steps and component interactions are similar to those described in Figures 6A-6B, Figure 6C illustrates an edgebased access decision, which may be deployed in edge-based scenarios, such as when the yard access system lacks network connection to the access control engine and / or third-party systems.

[0129] In this scenario, the process begins as driver 601 approaches gate 111 with a transport vehicle. Yard access system 107 detects the presence of the vehicle using one or more detection mechanisms, such as motion sensors, video analytics, or induction loops. Upon detection, yard access system 107 initiates the access event workflow by capturing images and / or video of the approaching vehicle using cameras 107A-C. These images and / or video are transmitted to lane monitor 109 for further analysis.

[0130] Lane monitor 109 processes the visual data using its onboard computer vision and machine learning models to extract identification information — such as license plate numbers, truck numbers, trailer numbers, and DOT numbers — and to select the most relevant images for authentication. The extracted identification information, along with selected images and any detected vehicle features, is compiled as event data. In this edge-based scenario, yard access system 107 and lane monitor 109 perform all necessary analysis and decision-making locally, without reliance on remote access control engines or cloud-based services.

[0131] If the identification information is incomplete or ambiguous, yard access system 107 may prompt the driver for additional information through the yard access system interface, such as via an Al-based voice agent, on-screen instructions, or keypad input. The driver provides the requested supplementary data, which is then incorporated into the authentication package. Yard access system 107 evaluates all available information — visual identifiers, driver-provided data, and sensor readings — to determine whether the transport vehicle is authorized to enter the secured yard.

[0132] Upon making an access decision, yard access system 107 sends a command to yard access system 107 to actuate gate 111, allowing the authorized vehicle to enter. The system may also monitor for tailgating or unauthorized entry by analyzing axle counts, motion events, or video feeds from multiple cameras and sensors, with these analytics performed locally on the edge device. Throughout the process, yard access system 107 and lane monitor 109generate and store a comprehensive event record, including detected identification information, additional data provided by the driver, time-stamped images, and metadata, supporting auditing, operational analysis, and compliance.

[0133] The sequences illustrated in Figures 6A-6C are provided as just three examples of operational scenarios and are not intended to be limiting or exhaustive. In practice, the specific steps, sequence, and order of operations may vary depending on system configuration, deployment requirements, and site-specific workflows. Components may perform actions synchronously or asynchronously, and certain processes may occur in parallel or be distributed across multiple devices or modules. Additional steps may be included, or some steps may be omitted or combined, depending on the needs of the yard, the capabilities of the deployed hardware and software, and integration with third-party systems. The roles and responsibilities of each component may also shift, and the system may be adapted to support alternative architectures, additional sensors, or new operational requirements as technology and customer needs evolve.

[0134] Figure 7 illustrates process 700, which represents an exemplary operation performed by access control engine 201 for generating a timeline of an access event at a secured yard. The timeline generation process provides a structured, visual record of the sequence of events associated with a transport vehicle’s ingress or egress, supporting auditing, operational review, and dispute resolution. Process 700 may be implemented in program instructions executed by one or more processing devices of access control engine 201, and may operate in conjunction with yard access system 107, lane monitor 109, video and image store 237, and database 235. Access control engine 201 may utilize tools provided by yard access system 107 and / or lane monitor 109 in the execution of process 700.

[0135] The process begins when access control engine 201 receives a trigger to generate a timeline for an access event (step 701). This trigger may be initiated automatically upon completion of an access event, such as a vehicle crossing or access control event, or may be requested by an operator for review or investigation purposes. The trigger includes a key event timestamp that serves as the anchor point for the timeline.

[0136] Next, access control engine 201 loads camera configurations for the relevant lane or gate associated with the access event (step 703). Each camera configuration defines search windows (e.g., time intervals before and after the key event) and desired snapshot times (shot offsets) for each camera. These configurations are used to guide the selection of images and video segments that will be included in the timeline, ensuring comprehensive coverage of the event from multiple viewpoints.

[0137] Access control engine 201 then queries the database for vehicle recognition events, license plate read (LPR) events, and / or other detection events within the configured time window (step 705). This may include searching for high-quality images captured by lane monitor 109, LPR events with high confidence scores, and motion or object detection events that are temporally aligned with the access event. The system prioritizes images and events that are most likely to be associated with the current access event, filtering out data that may belong to adjacent or unrelated events.

[0138] If vehicle recognition images are available for the access event (step 707), access control engine 201 determines their relevance and quality. When suitable images are identified, they are added to the timeline (step 709). These images may include clear license plate reads, vehicle detection frames, or other key visual evidence that supports identification and authentication.

[0139] For cameras or time windows where no suitable vehicle recognition or LPR images are found, access control engine 201 selects the best available events within the time window or selects the closest motion or object detection events (step 711). This ensures that the timeline is populated with the most relevant and informative images, even in cases where ideal data is not available.

[0140] Access control engine 201 then creates and stores references to the selected camera events and images (step 713). These references are used to assemble the timeline and facilitate efficient retrieval and review of the underlying visual data.

[0141] The selected images and events are arranged chronologically, with timestamps and camera identifiers, to provide a coherent and easily navigable visual record of the access event (step 715). This chronological arrangement allows operators, auditors, or investigators to quickly understand the sequence of actions and conditions at the gate during the event.

[0142] The completed timeline is persisted to a database and linked to the corresponding access event (step 717). This storage allows the timeline to be retrieved for later review, whether for routine auditing, incident investigation, or customer inquiries. The timeline record may include metadata such as event identifiers, timestamps, camera sources, operator annotations, and any relevant contextual information, providing a comprehensive and searchable archive of yard activity.

[0143] In some embodiments, the timeline may be further enriched with operator notes, automated damage detection results, or integration data from third-party systems, supporting advanced analytics and continuous improvement of yard operations. The timeline can be presented through operator dashboards, customer portals, or reporting tools, allowingauthorized users to visually step through the sequence of images and events associated with each access event. This visual record supports rapid resolution of disputes, verification of compliance with operational protocols, and identification of process bottlenecks or security vulnerabilities.

[0144] Figure 8 illustrates access control event record 800, an example of an event record that provides a structured summary of a transport vehicle’s attempt to access a secured yard. Access control event record 800 includes event details such as the event date and time, the entry yard, the customer associated with the event, and equipment state information 801. This record may be generated and stored by access control engine 201, yard access system 107, and / or lane monitor 109 as part of the event logging and profile management process, and may be used for operational analysis, auditing, compliance, dispute resolution, and the like.

[0145] The event date and time field captures the precise timestamp of the access event, providing a reference for when the access event associated with the transport vehicle began. For example, the timestamp may represent the time that the vehicle was first detected as it approached the yard access system. The entry yard field identifies the specific yard or facility where the event occurred, supporting multi-site operations and inventory management. The customer field associates the event with a particular customer, carrier, or fleet operator, enabling customer-specific reporting, billing, and chain-of-custody tracking.

[0146] Equipment state information 801 provides a description of the transport vehicle and its condition at the time of entry. This may include the vehicle type (e.g., combo, tractor, trailer), color, make, model, trailer type, and any visible damage or missing components (such as mudflaps). The equipment state may be determined by lane monitor 109 through automated image analysis, by operator input, or by a combination of both. In some embodiments, additional fields may be included to capture identifiers such as license plate numbers, USDOT numbers, truck numbers, trailer numbers, or seal numbers, as well as operational data such as load type or trip number.

[0147] Access control event record 800 may be stored in database 235 for long-term retention and retrieval. The record can be displayed in real time on operator dashboards, within customer portals, or on the screen of yard access system 107 to provide immediate feedback to drivers and yard personnel. In some scenarios, the record may be annotated by operators or enriched with additional metadata, such as operator notes, inspection results, or links to associated images and video footage.

[0148] Figure 9 illustrates dashboard 900, an example dashboard for an access event, as generated by one or more of access control engine 201, yard access system 107, and / or lanemonitor 109. Dashboard 900 provides a comprehensive, real-time visual summary of a transport vehicle’s entry into a secured yard, aggregating key event details, equipment information, and supporting images for operator review, auditing, and operational management.

[0149] Access event details 901 are prominently displayed at the top of the dashboard, including the source of the event (such as yard entry system 1) and a timestamp for the access event. Equipment information 905 is presented in a structured format, summarizing the customer associated with the event (e.g., Alpha Trucking) and the equipment type (e.g., tractor plus trailer). Dashboard 900 further breaks down equipment information into tractor information 907 and trailer information 909. Tractor information 907 includes fields such as license plate state and number, truck number, and USDOT number, along with an indicator of whether the equipment has been verified. Trailer information 909 similarly includes license plate state and number, trailer number, and a verification status. General comments 911 provide a narrative description of the equipment’s condition, such as make, model, trailer type, and any visible damage or issues.

[0150] The dashboard features multiple images — image 903, image 913, image 915, and image 917 — captured by one or more cameras (e.g., cameras 107A-C) at various positions and / or angles as the vehicle approaches and passes through the access point. These images may include close-ups of the tractor’s license plate (license plate 921), the trailer’s identifier (trailer ID 923), and other relevant views, such as the side or rear of the equipment. Key identifiers, such as USDOT number 919, may be visually highlighted within the images to facilitate rapid verification and inspection.

[0151] Dashboard 900 may be displayed in a variety of contexts, including operator workstations in a yard command center, clerk terminals at entry or exit points, customer portals for fleet managers, or directly on the screen of yard access system 107 for driver feedback, as just a few examples. Operators can use the dashboard to review and confirm access events in real time, annotate or flag issues, and initiate escalation workflows if anomalies or discrepancies are detected. In customer-facing scenarios, the dashboard provides transparency and accountability, allowing customers to monitor their equipment’s movements, verify compliance, and resolve disputes.

[0152] In some embodiments, dashboard 900 is interactive, enabling users to zoom in on images, access additional metadata, or link to related records such as previous access events, equipment profiles, or inspection histories. The dashboard may also support integration withreporting tools, analytics modules, or third-party systems, allowing for automated notifications, compliance checks, or billing triggers based on the recorded event data.10153] The design and layout of dashboard 900 can be customized to suit different user roles, operational requirements, or yard configurations, ensuring that all relevant information is accessible and actionable for efficient yard management and security oversight. The example shown in Figure 8 is merely one possible implementation; in practice, dashboards may be configured to display more, fewer, or entirely different data fields, images, or interactive elements depending on the needs of the operator, customer, or facility. For instance, additional panels could be added to show historical access events, real-time alerts, or integration with third-party compliance systems, while certain fields or images could be omitted for a simplified view. The arrangement, visual emphasis, and available actions within the dashboard may be tailored for specific workflows, such as rapid check-in, detailed auditing, or exception handling. Furthermore, the dashboard may be adapted for use on different device types, including desktop monitors, tablets, or mobile devices, and may support role-based access controls to ensure that sensitive information is only visible to authorized users. As such, dashboard 900 is intended to illustrate the breadth of information and functionality that can be provided, but is not limiting or exhaustive; alternative embodiments may employ a wide range of layouts, data sources, and user interface features to best support the operational and business objectives of the yard or organization.

[0154] Figure 10 illustrates table 1000, which details different equipment states that may be determined by one or more of access control engine 201, yard access system 107, and / or lane monitor 109 for a piece of equipment during an access event. Table 1000 provides a structured overview of the possible states, their definitions, and representative examples, supporting consistent classification and operational decision-making for transport equipment entering or exiting a secured yard.

[0155] The “State” column enumerates four possible equipment states, which include unidentified, identified, complete, and verified. The “Definition” column provides a brief explanation of the criteria for each state, while the “Example” column offers a practical scenario illustrating how a piece of equipment may be classified in that state.

[0156] Equipment may be classified as “unidentified” when it lacks any unique identifiers, such as a license plate and state, equipment number, or container number. For example, images may show a black Lexus SUV entering the yard, but if no license plate is identifiable, the relevant access control system cannot uniquely identify this equipment. The “identified” state may be used when equipment has at least one unique identifier (such as a license plate andstate, equipment number, or container number), but not enough information to be verified. For instance, images may show a tractor entering with a Washington state license plate number BVM0600, but the system is unable to determine the truck number or USDOT number for this tractor.

[0157] The “complete” state may be assigned when equipment has all expected information, no duplicate information across fields, and is mapped to a known customer. An example of this is a tractor with the following details: License Plate State: WA, License Plate: BVM0600, Truck Number: 123, USDOT Number: 44455566, and Customer: Tracy Johnson. The “verified” state is used when equipment information is both complete and independently verified, which may require at least two check-ins and / or verifications with complete and matching information for a given piece of equipment.

[0158] In some implementations, table 1000 or a similar structure, may be referenced by access control engine 201, yard access system 107, and / or lane monitor 109 during the authentication and validation process to determine the current state of each piece of equipment. The equipment state may influence access decisions, trigger additional verification steps, or determine the level of scrutiny applied during an access event. Table 1000 or a similarly informative structure may be displayed in operator dashboards, used in reporting and analytics, or integrated into automated workflows for yard management and compliance.

[0159] The specific states, definitions, and examples shown in Figure 9 are illustrative and may be adapted or extended to accommodate different operational requirements, customer policies, or regulatory standards. Additional states may be defined, or the criteria for each state may be adjusted, to reflect the evolving needs of the yard access control system and its users.

[0160] Figure 11 illustrates dashboard 1100, an example dashboard for displaying equipment information within a command center interface, generated by an access control engine as disclosed herein. Dashboard 1100 is designed to provide operators, administrators, or other authorized users with a consolidated view of equipment currently tracked by the access control system across one or more yards. This dashboard is just one example of a user interface that may be presented to users, and may be used in conjunction with other dashboards or UIs, such as dashboard 900 shown in Figure 9. The system may support multiple dashboard types within the same application or platform, allowing users to navigate between different operational views and data summaries as needed.

[0161] Command center 1101 is shown as a navigation panel on the left side of the dashboard, providing access to various system modules such as Dashboard, Gate Events, Reservations, Customers, Users, Yards, and Equipment. This navigation structure is just oneexample of how a user might move between different dashboards or views to access information relevant to their role or task. For instance, an operator may switch from reviewing real-time gate events to managing equipment inventory, or an administrator may access customer records or reservation details.

[0162] Window 1103 occupies the main area of the dashboard and displays equipment information 1107. At the top of window 1103, users can filter the displayed equipment by equipment type and status using dropdown menus, and can search for specific equipment using a search bar.

[0163] Equipment information 1107 is organized in a tabular format, with columns for equipment type 1105, license plate, identifier, customer, and status 1109. Equipment type 1105 distinguishes between different categories of equipment, such as Tractor, Dry Van, Chassis, and POV (personally owned vehicle). Each row in the table represents a specific piece of equipment, displaying its license plate number, unique identifier (such as a truck or trailer number), the associated customer or fleet operator, and the current status of the equipment.

[0164] Status 1109 indicates the verification or operational state of each piece of equipment, with possible values such as created, verified, or identified. These statuses may be determined by access control engine 201 based on the completeness and reliability of the identification information collected during access events, as described in Figure 10. For example, a status of verified may indicate that the equipment’s identifiers have been independently confirmed through multiple check-ins or validation steps, while created or identified may reflect earlier stages in the verification process.

[0165] Dashboard 1100 may be displayed on operator workstations in a yard command center, on administrative terminals, or within customer-facing portals, depending on the needs of the organization. The dashboard supports real-time monitoring of yard inventory, rapid identification of equipment, and streamlined management of operational workflows. In some embodiments, dashboard 1100 may be interactive, allowing users to click on equipment entries to view detailed histories, associated access events, or inspection records. The dashboard may also support exporting data, generating reports, or integrating with third-party systems for further analysis, compliance, or operational planning. Depending on deployment, dashboard 1100 may be accessed locally on dedicated operator workstations within a yard command center, remotely via secure web portals for centralized fleet management, or even on mobile devices for on-the-go yard staff.

[0166] As with other dashboards in the system, such as dashboard 900, dashboard 1100 may be part of a unified software platform where users can seamlessly navigate betweendifferent operational views using navigation elements like command center 1101. This modular approach enables organizations to adapt the user interface to their specific workflows, operational requirements, and security policies, ensuring that all relevant information is accessible, actionable, and presented in a manner that best supports efficient yard management and decision-making.

[0167] Figure 12 illustrates dashboard 1200, another example dashboard that may be generated by an access control engine as described herein. Dashboard 1200 is focused on presenting a timeline-centric view of an access control event. Dashboard 1200 is designed to provide operators, administrators, or other authorized users with a clear, chronological visual record of a transport vehicle’s entry into a secured yard, supporting auditing, incident investigation, and operational review.

[0168] Access control event details 1201 are displayed at the top of the dashboard, including the event date and time, the entry yard, and the customer associated with the event. This contextual information anchors the timeline and allows users to quickly identify the specific access event being reviewed.

[0169] Timeline window 1203 occupies the main area of the dashboard and presents a structured, time-ordered sequence of images and events associated with the access event. Timeline 1205 is arranged vertically, with each node corresponding to a specific timestamp and camera perspective. For example, the timeline may include images from the front camera (image 1207), side camera (image 1209), fisheye camera (image 1211), and a close-up license plate image (image 1213), each captured at key moments as the vehicle approaches and / or passes through the entry point.

[0170] Each image in the timeline is annotated with its corresponding timestamp, allowing users to step through the sequence of events and observe the vehicle’s movement and condition from multiple angles. This multi-view approach enables detailed inspection of the transport vehicle, verification of identifiers, and detection of any visible damage or anomalies. The timeline may also include additional metadata, such as camera identifiers, operator notes, or automated detection results, to further enrich the visual record.

[0171] Dashboard 1200 may be displayed on operator workstations, within command center interfaces, or in customer-facing portals, depending on the needs of the organization. The timeline-centric view is particularly useful for resolving disputes, verifying compliance with yard protocols, and supporting investigations into incidents such as tailgating, unauthorized entry, or equipment damage. Operators can use the dashboard to quickly reviewthe sequence of images, zoom in on specific frames, or cross-reference the timeline with other event records and equipment profiles.10172] The design and layout of dashboard 1200 can be customized to accommodate different camera configurations, event types, or user preferences. Additional timeline nodes may be added to include more camera angles, sensor data, or operator annotations, while the interface may be streamlined for rapid review or detailed analysis. Dashboard 1200 may be integrated with other dashboards and navigation elements within the platform, allowing users to switch between timeline views, equipment summaries, and real-time monitoring as needed.

[0173] As with other dashboards in the system, dashboard 1200 is intended as one example of how access event data can be organized and presented to support efficient and effective yard management. The timeline-centric approach allows users to reconstruct the precise sequence of actions and conditions at the gate, making it easier to identify process bottlenecks, verify the integrity of ingress and egress events, and resolve questions about the timing or nature of specific incidents.

[0174] Dashboard 1200 may also support interactive features, such as allowing users to click on individual timeline nodes to view higher-resolution images, access additional metadata, or add operator annotations. Integration with reporting tools and analytics modules enables the export of timeline data for compliance documentation, insurance claims, or performance analysis. The dashboard can be configured to display timelines for both ingress and egress events, and may be linked to related records such as equipment profiles, driver histories, or previous access events for comprehensive review.

[0175] Depending on deployment, dashboard 1200 may be accessed from fixed operator stations in a yard command center, remotely by security or management personnel, or through secure web portals by customers seeking to audit their own equipment’s movements. The modular and extensible design of the dashboard ensures that it can be adapted to a wide range of operational requirements, camera setups, and user roles.

[0176] Figure 13 illustrates dashboard 1300, which provides an example of a yard event details dashboard that may be generated by an access control engine as disclosed herein. Dashboard 1300 is designed to present a consolidated, real-time overview of yard activity, including inventory status and a chronological listing of recent gate events. This dashboard supports operators, administrators, and other authorized users in monitoring yard utilization, tracking equipment movements, and maintaining situational awareness across the facility.

[0177] At the top of dashboard 1300, the yard name (Eastern York Yard) is displayed, establishing the context for the information presented. Below the yard name, inventoryinformation 1301 summarizes the current real-time inventory of equipment within the yard. This section displays counts for different categories of equipment, such as trailers, tractors, combos (tractor-trailer combinations), and personals (personally owned vehicles). These inventory counts provide a snapshot of yard occupancy and equipment mix, supporting operational planning and resource allocation.

[0178] Gate events 1303 are presented in a tabular format, listing recent access events in chronological order. Each row in the table corresponds to a specific gate event, such as an arrival or departure, and includes an image of the equipment involved, the event timestamp, the event type (e.g., arrival or departure), and equipment identification information. For example, gate event 1305 shows a departure event at 09:26:23 for equipment with license plate NC ABC123 and identifier 1250. Gate event 1307 shows an arrival event at 10:02: 15 for equipment with license plate MN 321654 and identifier 2516, while gate event 1309 shows another arrival at 11 :22:08 for equipment with license plate IN 987321 and identifier SWFZ1500.

[0179] The images associated with each gate event are captured by one or more cameras (e.g., cameras 107A-C) at the entry or exit point and provide visual confirmation of the equipment’s identity and condition at the time of the event. The inclusion of both visual and textual data enables rapid verification, supports auditing, and facilitates incident investigation or dispute resolution.

[0180] Dashboard 1300 may be displayed on operator workstations in a yard command center, on administrative terminals, or within customer-facing portals, depending on the needs of the organization. The dashboard can be used for real-time monitoring of yard activity, historical review of equipment movements, and generation of operational or compliance reports. In some embodiments, dashboard 1300 is interactive, allowing users to filter events by type, search for specific equipment, or access additional details and images for each event.

[0181] The layout, data fields, and available actions within dashboard 1300 can be customized to suit different operational requirements, user roles, or yard configurations. Additional columns or filters may be added to display more granular information, or the interface may be streamlined for specific use cases. Dashboard 1300 is intended as one example of how yard event and inventory data may be organized and presented, and may be used in conjunction with other dashboards or user interfaces within the access control platform to provide comprehensive visibility and control over yard operations. Depending on deployment, dashboard 1300 may be accessed locally on operator workstations within a yard command center, remotely via secure web portals for centralized management, or on mobiledevices for field personnel. The dashboard may also support export and reporting functions, integration with third-party systems, and role-based access controls to ensure that sensitive information is only available to authorized users.

[0182] Dashboard 1300 may be adapted to display additional event types, such as inspections, maintenance activities, or security incidents, and may be linked to related records such as equipment profiles, driver histories, or compliance documentation. The modular design allows for seamless navigation between inventory views, event logs, and other operational dashboards, supporting efficient workflow and rapid response to changing yard conditions. As with other dashboards in the system, the configuration, content, and presentation of dashboard 1300 are flexible and can be tailored to meet the evolving needs of the organization, the specific requirements of the yard, or the preferences of different user groups.

[0183] Figure 14 illustrates computing system 1401, which is representative of any computing apparatus or collection of devices on which the various processes, programs, services, and scenarios disclosed herein may be implemented. Examples of computing system 1401 include, but are not limited to, server computers, desktop computers, rack-mounted or edge servers deployed on-site at a yard, industrial computers, microcontroller units (MCUs) embedded in access control hardware, and Internet of Things (loT) devices integrated with sensors or cameras. Computing system 1401 may be implemented as a single centralized server, as a distributed set of networked devices across multiple locations (such as cloud infrastructure combined with on-premises edge devices), or as a hybrid architecture supporting both local and remote processing for access control, equipment tracking, and yard management operations.

[0184] Computing system 1401 includes, but is not limited to, processing system 1402, storage system 1403, software 1405, access control process 1406, communication interface system 1407, and user interface system 1409. Processing system 1402 is operatively coupled with storage system 1403, communication interface system 1407, and user interface system 1409. Processing system 1402 loads and executes software 1405 from storage system 1403. Software 1405 includes and implements access control process 1406, which is representative of the various access control methods, processes, and operational scenarios described above, including but not limited to the processes illustrated in Figures 3, 4, 5, 6A-6C, and 7. When executed by processing system 1402, software 1405 directs processing system 1402 to operate as described herein for at least the various processes, operational scenarios, and sequences discussed in the foregoing implementations. Computing system 1401 may optionally include additional devices, features, or functionality not discussed for purposes of brevity.

[0185] Processing system 1402 may include a microprocessor and other circuitry that retrieves and executes software 1405 from storage system 1403. Processing system 1402 may be implemented within a single processing device or distributed across multiple processing devices or sub-systems that cooperate in executing program instructions. Examples of processing system 1402 include general purpose central processing units (CPUs), graphical processing units (GPUs), neural processing units (NPUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), and logic devices, as well as any other type of processing device, circuitry, or combinations and variations thereof.

[0186] Storage system 1403 may include any computer readable storage media readable by processing system 1402 and capable of storing software 1405. Storage system 1403 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of storage media include random access memory (RAM), read only memory (ROM), magnetic disks, optical disks, flash memory, virtual memory and non-virtual memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other suitable storage media. In no case is the computer readable storage media a propagated signal.

[0187] In some implementations, storage system 1403 may also include computer readable communication media over which at least some of software 1405 may be communicated internally or externally. Storage system 1403 may be implemented as a single storage device or across multiple storage devices or sub-systems, co-located or distributed relative to each other. Storage system 1403 may include additional elements, such as a controller, capable of communicating with processing system 1402 or possibly other systems.

[0188] Software 1405, including access control process 1406, may be implemented in program instructions and, among other functions, may, when executed by processing system 1402, direct processing system 1402 to operate as described with respect to the various operational scenarios, sequences, and processes illustrated herein. For example, software 1405 may include program instructions for implementing computer vision, machine learning, optical character recognition, access control, equipment tracking, event logging, timeline generation, and other methods described in this disclosure.

[0189] The program instructions may include various components or modules that cooperate or otherwise interact to carry out the various processes and operational scenarios described herein. These components or modules may be embodied in compiled or interpreted instructions, or in some other variation or combination of instructions. The components ormodules may be executed in a synchronous or asynchronous manner, serially or in parallel, in a single-threaded environment or multi -threaded, or in accordance with any other suitable execution paradigm, variation, or combination thereof. Software 1405 may include additional processes, programs, or components, such as operating system software, virtualization software (including virtual machine software and container software), or other application software. Software 1405 may also include firmware or some other form of machine-readable processing instructions executable by processing system 1402.

[0190] When loaded into processing system 1402 and executed, software 1405 may transform a suitable apparatus, system, or device (of which computing system 1401 is representative) from a general -purpose computing system into a special-purpose computing system customized to perform the computer vision, machine learning, OCR, access control, equipment management, and event processing described herein. Encoding software 1405 on storage system 1403 may transform the physical structure of storage system 1403. The specific transformation of the physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the storage media of storage system 1403 and whether the computer- storage media are characterized as primary or secondary storage, as well as other factors.

[0191] For example, if the computer readable storage media are implemented as semiconductor-based memory, software 1405 may transform the physical state of the semiconductor memory when the program instructions are encoded therein, such as by transforming the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. A similar transformation may occur with respect to magnetic or optical media. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate the present discussion.

[0192] Communication interface system 1407 may include communication connections and devices that allow for communication with other computing systems (not shown) over communication networks (not shown). Examples of connections and devices that together allow for inter-system communication may include network interface cards, antennas, power amplifiers, RF circuitry, transceivers, and other communication circuitry. The connections and devices may communicate over communication media to exchange communications with other computing systems or networks of systems, such as metal, glass, air, or any other suitablecommunication media. The aforementioned media, connections, and devices are well known and need not be discussed at length here.10193] Communication between computing system 1401 and other computing systems (not shown) may occur over a communication network or networks and in accordance with various communication protocols, combinations of protocols, or variations thereof. Examples include intranets, internets, the Internet, local area networks, wide area networks, wireless networks, wired networks, virtual networks, software defined networks, data center buses and backplanes, or any other type of network, combination of network, or variation thereof. The aforementioned communication networks and protocols are well known and need not be discussed at length here.

[0194] User interface system 1409 may include various components and devices that enable interaction between the user and computing system 1401. Examples of these components and devices may include display screens, touchscreens, keyboards, mice, trackpads, styluses, voice recognition microphones, and other input / output devices. User interface system 1409 facilitates user commands and feedback through graphical user interfaces (GUIs), command-line interfaces (CLIs), or other interaction models. These interfaces may display information, receive user inputs, and provide visual, auditory, or tactile responses. User interface system 1409 may include operator workstations, clerk terminals, dashboard displays, and other systems that enable interaction between users and the access control system. The components and devices within user interface system 1409 are designed to ensure seamless and intuitive user interaction, leveraging well-established technologies and practices that need not be elaborated upon here.

[0195] As will be appreciated by those skilled in the art, aspects of the disclosed technology may be embodied as a system, method, or computer program product, and may take the form of hardware, software, or a combination thereof. Furthermore, aspects of the technology disclosed herein 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. These embodiments may include entirely hardware implementations, entirely software implementations (including firmware, resident software, micro-code, etc.), or combinations of hardware and software aspects that may all generally be referred to herein as a “circuit,” “module,” or “system.” The program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, or other communication media.

[0196] Accordingly, computing system 1401 as depicted in Figure 14 is intended to be broadly representative of the various types of computing infrastructure that may be used to implement the access control engine, its related processes, and the operational scenarios described throughout this disclosure. The specific arrangement, number, and type of components shown in Figure 14 are merely illustrative and may vary depending on the requirements of a particular deployment, system architecture, or operational environment.

[0197] Indeed, the included descriptions and figures depict specific embodiments to teach those skilled in the art how to make and use the best mode. For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these embodiments that fall within the scope of the disclosure. Those skilled in the art will also appreciate that the features described above may be combined in various ways to form multiple embodiments. As a result, the invention is not limited to the specific embodiments described above, but only by the claims and their equivalents.

Claims

CLAIMSWhat is claimed is:

1. A computer-implemented method for vehicle recognition for access to a secured yard, the method comprising: detecting, based on image data received from a plurality of cameras positioned to capture different views of a lane into the secured yard, a vehicle entering the lane; tracking the vehicle across the plurality of cameras as the vehicle moves through the lane; executing one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle; applying optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers; analyzing the text-based representation of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result; and outputting the vehicle identification result for use in making an access decision for the vehicle.

2. The computer-implemented method of claim 1, further comprising: initiating, by an Al-based voice agent, an interaction with a driver of the vehicle in response to determining that additional information is needed to authenticate the vehicle; capturing the additional information provided by the driver, wherein the additional information comprises at least one of a trip number, a load type, a seal number, and a reservation code; combining the vehicle identification result with at least the additional information provided by the driver to generate a vehicle access record; and providing the vehicle access record to an access control system.

3. The computer-implemented method of claim 1, further comprising, in response to determining that at least one vehicle identifier of the one or more vehicle identifiers is incomplete, combining partial identifier information from the plurality of cameras to resolve a complete vehicle identifier of the one or more vehicle identifiers.

4. The computer-implemented method of claim 1, wherein executing the one or more machine learning models to detect the one or more vehicle identifiers and the one or more vehicle features associated with the vehicle comprises applying one or more models to detect a presence and a location of the one or more vehicle identifiers classify a type of the vehicle.

5. The computer-implemented method of claim 1, further comprising selecting one or more frames from the image data for the optical character recognition based one at least one of a detection confidence, a bounding box area, and a relative velocity of the one or more vehicle identifiers in the image data.

6. The computer-implemented method of claim 1, wherein the one or more vehicle features comprise at least one of a make, a model, a color, a trailer type, and physical damage.

7. The computer-implemented method of claim 1, further comprising detecting tailgating by analyzing at least one of axle counts and sensor data to determine that more than one vehicle entered the secured yard.

8. The computer-implemented method of claim 1, further comprising buffering the image data and adjusting frame processing rates based on vehicle presence in the lane.A system comprising: one or more computer readable storage media; one or more processors operatively coupled with the one or more computer readable storage media; and program instructions stored on the one or more computer readable storage media that, when executed by the one or more processors, direct the system to at least: detect, based on image data received from a plurality of cameras positioned to capture different views of a lane into a secured yard, a vehicle entering the lane; track the vehicle across the plurality of cameras as the vehicle moves through the lane; execute one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle; apply optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers; analyze the text-based representation of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result; and output the vehicle identification result for use in making an access decision for the vehicle.

10. The system of claim 9, where the program instructions further direct the system to: initiate, via an Al-based voice agent, an interaction with a driver of the vehicle in response to determining that additional information is needed to authenticate the vehicle; capture the additional information provided by the driver, wherein the additional information comprises at least one of a trip number, a load type, a seal number, and a reservation code; combine the vehicle identification result with at least the additional information provided by the driver to generate a vehicle access record; and provide the vehicle access record to an access control system.

11. The system of claim 9, where the program instructions further direct the system to, in response to determining that at least one vehicle identifier of the one or more vehicle identifiers is incomplete, combine partial identifier information from the plurality of cameras to resolve a complete vehicle identifier of the one or more vehicle identifiers.

12. The system of claim 9, wherein to execute the one or more machine learning models to detect the one or more vehicle identifiers and the one or more vehicle features associated with the vehicle, the program instructions direct the system to apply one or more models to detect a presence and a location of the one or more vehicle identifiers and classify a type of the vehicle.

13. The system of claim 9, where the program instructions further direct the system to select one or more frames from the image data for the optical character recognition based one at least one of a detection confidence, a bounding box area, and a relative velocity of the one or more vehicle identifiers in the image data.

14. The system of claim 9, wherein the one or more vehicle features comprise at least one of a make, a model, a color, a trailer type, and physical damage.

15. The system of claim 9, where the program instructions further direct the system to detect tailgating by analyzing at least one of axle counts and sensor data to determine that more than one vehicle entered the secured yard.

16. The system of claim 9, where the program instructions further direct the system to buffer the image data and adjust frame processing rates based on vehicle presence in the lane.

17. One or more computer-readable storage media having program instructions stored thereon that, when executed by one or more processors of a computing apparatus, direct the computing apparatus to at least: detect, based on image data received from a plurality of cameras positioned to capture different views of a lane into a secured yard, a vehicle entering the lane; track the vehicle across the plurality of cameras as the vehicle moves through the lane; execute one or more machine learning models to detect, from the image data, one or more vehicle identifiers and one or more vehicle features associated with the vehicle; apply optical character recognition to the one or more vehicle identifiers to convert a visual representation of the one or more vehicle identifiers into a text-based representation of the one or more vehicle identifiers; analyze the text-based representation of the one or more vehicle identifiers and the one or more vehicle features to generate a vehicle identification result; and output the vehicle identification result for use in making an access decision for the vehicle.

18. The one or more computer-readable storage media of claim 17, where the program instructions further direct the computing apparatus to: initiate, via an Al-based voice agent, an interaction with a driver of the vehicle in response to determining that additional information is needed to authenticate the vehicle; capture the additional information provided by the driver, wherein the additional information comprises at least one of a trip number, a load type, a seal number, and a reservation code; combine the vehicle identification result with at least the additional information provided by the driver to generate a vehicle access record; and provide the vehicle access record to an access control system.

19. The one or more computer-readable storage media of claim 17, where the program instructions further direct the computing apparatus to, in response to determining that at least one vehicle identifier of the one or more vehicle identifiers is incomplete, combine partial identifier information from the plurality of cameras to resolve a complete vehicle identifier of the one or more vehicle identifiers.

20. The one or more computer-readable storage media of claim 17, wherein to execute the one or more machine learning models to detect the one or more vehicle identifiers and the one or more vehicle features associated with the vehicle, the program instructions direct the computing apparatus to apply one or more models to detect a presence and a location of the one or more vehicle identifiers and classify a type of the vehicle.

Images