TW201535282A - Systems and methods of processing data involving terminal operations including tracking, appointment and/or other features - Google Patents

Abstract

Systems and methods are disclosed for processing information related to appointment systems as well as associated terminal operating systems and other related systems. According to one illustrative implementation, an exemplary method for processing information involving appointment systems herein may include receiving/handling/processing data in a TOS format associated with a TOS type, converting the data into a TOS agnostic format, and performing processing using the TOS agnostic data. In another exemplary implementation, there is provided computer-implemented methods for processing information for appointment systems in conjunction with associated systems and operations. Systems and computer-implemented methods herein may include or involve processing information related to an appointment system and interrelationships with associated terminal operating systems, gate systems, and/or various TOS-agnostic features and functionality.

Description

Processing systems involving information on the operations of the collection and distribution stations including tracking, appointment and/or other functions and method Cross-references to related applications

The present application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 61/965,458, filed Jan.

The present invention is directed to systems and methods for processing information relating to a collection station operation including tracking, appointment, and/or other functions.

Background of the invention

The process of importing and exporting containers and goods in Hong Kong involves multiple parties and requires significant communication and coordination. In addition, the parties involved must comply with many rules and guidelines.

A system known as the Terminal Station Operating System (TOS) has been developed to support this process at port terminals around the world. Many of the standard operating procedures associated with activities at the collection station, such as import functions and export functions, have become part of such TOS applications, however, such programs have been implemented differently.

However, areas such as resource (equipment utilization and labor) planning and management, exception management, instant exception management, TOS agnostic software/platform/components, and other interrelated functionalities are areas that are not adequately addressed by existing distribution station operating systems.

The shipping industry as briefly depicted in Figure 1 includes the actual transportation of goods from overseas and overseas, and also includes an interface with port facilities and third parties. As shown in Figure 1, there are multiple parties involved in the transportation of goods through port facilities, and the port interface can introduce delays throughout the shipping time.

For example, a trucking company can schedule picking up containers and make appointments that include specific counts and types of containers. For each container, attributes such as size are specified. When an entity associated with such a container (eg, a driver, etc.) arrives at a collection and delivery station to process or deliver a container, the system uses information previously entered by the entity at the time the appointment was made. The attributes of one or more containers may not match the specified attributes of the appointment. In this case, the entity will typically not be allowed to process or deliver the container until the information matches the container.

In the past, issues such as those described above required extensive communication and paperwork between parties to understand the nature of the problem and to update or correct the information so that the entity could continue to carry the desired handling of the container.

In accordance with an embodiment of the present invention, a computer-implemented method for processing information is disclosed, the information relating to a reservation system for a collection station operating system, the method comprising: providing information for use to a user Displaying an interface, the interface includes a reservation function and an input field for receiving a user input, the information includes the first information, the first capital The information includes reservation information; processing information related to the user input received through the interface to manage the reservation functionality; and processing to generate an output and/or a result, the output and/or the result and the following operations Correlation: processing and/or transmitting instructions within the reservation system, processing and/or transmitting instructions to a computing device external to the reservation system, or a combination of the two; performing the reservation functionality via the reservation system Equivalent to one of the results of the managed subscription functionality and/or one of the processed information outputs; and/or a combination of processing, transmitting and/or performing functions related to the output and/or results.

102‧‧‧Suppliers

104‧‧‧ Shipper

106‧‧‧ goods contractor

108‧‧‧public transporter

110‧‧‧Customs

114‧‧‧ broker

116‧‧‧Consignee

118‧‧‧ Distribution Center

120‧‧‧ Retailers

204‧‧‧User input/user

214‧‧‧ expression layer, expression/application layer

216‧‧‧WCF (Windows Communication Foundation) Service

220‧‧‧Business Logic/Commercial Layer

222‧‧‧Service/Service Layer/Service Limits

226, 806, 906, 1726A, 1820, 1820B, 1820C, 1820D, 2020, 2024, 2028‧‧‧Repository

250‧‧‧Data access/data access layer

301, 1802, 2410B‧‧‧ expression layer

302‧‧‧ model

303‧‧‧ domain layer

305, 1806, 1830B, 1830C, 1830D, 2430B‧‧‧ data access layer

306‧‧‧ Controller

308‧‧‧ expression model

310‧‧‧ view

312‧‧‧Respond

314‧‧‧Connected database

401, 407~413‧‧‧ devices

403‧‧‧Device/Export Container List

405‧‧‧Devices/entities

415, 447, 1801‧‧‧ network

417‧‧‧TOS Website Portal Instance A/Website Portal A/Website Portal Instance

421, 439‧ ‧ export services

425‧‧‧TOS A repository/repository

427‧‧‧TOS B repository

429‧‧‧Distribution Station Operating System/TOS A Database

431‧‧‧Distribution Station Operating System/Website Portal Service TOS B

433‧‧‧TOS Website Portal Instance B/Website Portal Instance B

437‧‧‧Importation services

443‧‧‧TOS C repository

445‧‧‧Distribution Station Operating System/TOS C API

457‧‧‧Another TOS system/interface

459‧‧‧Truck Freight/Reservation System

471~477‧‧‧Request

502‧‧‧Homework services

504, 714‧‧ Import

506‧‧‧Device Control

508, 522, 546‧‧ ‧ gate activities

510, 716‧‧ Export

514‧‧‧TOS website portal implementation plan/TOS website portal/TOS website portal

520, 710‧‧‧Notice Service

524, 4700O, 4700P‧‧‧ Reservation status

526, 2336‧‧‧

528, 562‧‧‧ lag

530‧‧‧ Container status

540, 712‧‧ Reporting services

542‧‧‧ Imported containers

544‧‧‧Ship schedule

548‧‧‧Exports

550‧‧‧ bill of lading

560‧‧‧ Payment service

564, 726‧‧ payments

566‧‧‧ rate table

580, 706‧‧‧ Reservation Service

582‧‧‧ Imports are full

584‧‧‧empty check-in

586‧‧‧Exports in/out

588‧‧‧Chassis in/out

590‧‧‧Infrastructure services

592‧‧‧User account

594‧‧‧ Venue Services

596‧‧‧SSCO Services

606‧‧‧export container

608‧‧‧Scheduled items

616‧‧‧Truck Freight Company

618‧‧‧ ship

620‧‧‧HK

622‧‧‧Partners

702‧‧‧TOS website entrance

704‧‧‧Homework services

705‧‧‧Infrastructure services

708‧‧‧ Payment service

718‧‧‧Device Control

720‧‧ ‧ gate

722‧‧‧Manager module

724‧‧‧ Appointment

728‧‧ Notice

730‧‧ Report

804, 812‧‧ ‧ commercial entities

810‧‧‧Data source layer

908‧‧‧Business Line (LOB) application

912‧‧‧ Cache memory

1004‧‧‧Service components

1008‧‧‧Repository Locator Assembly or Device/Repository Locator

1016~1020‧‧‧Distributed Terminal Station Database

1102‧‧‧Central Cloud Server

1104, 1108‧‧‧ Internet providers

1120, 1124‧‧‧Example/TOS website entrance

1128, 1132‧‧‧Server instance/TOS website portal

1136~1156‧‧‧TOS system

1202~1222, 1302~1342, 1431, 1433, 1435, 1437, 1440, 1441, 1443, 1450~1457, 1459, 1460, 1470~1499, 1508~1518, 1602~1610, 1702~1708, 1714, 1716, 1734, 1910, 2304~2328, 2402D~2410D, 2414D~2418D, 2422D~2426D, 2430D~2438D, 2442D~2448D, 2404E~2430E, 2414F~2434F, 2408G, 2412G~2422G, 2408I~2416I, 2408J~2416J, 2420J~2436J, 2481A~2481H, 2481J~2481N, 2481P~2481V, 2482A~2483H, 2482J~2483N, 2485A~2485H, 2485J~2485N, 2552D, 2556D, 2558D, 2562D, 2564D, 4203, 4209, 4307, 4317, 4319, 4321, 4323, 4401~4409, 4413~4417, 4621, 4622, 4631~4635, 4640, 4650‧‧

1401‧‧‧Repository Factory/Factory

1402‧‧‧Service/Expression Layer

1404‧‧‧Commercial object components/handling

1405‧‧‧Logic

1406‧‧‧TOS repository instance component/processing

1408‧‧‧TOS 1 database

1411‧‧‧Repository Type Cache Memory/Cache Memory

1412‧‧‧TOS database/container information/data

1413‧‧‧Initialization

1414‧‧‧TOS 2 data source

1415‧‧‧Repository implementation type

1416‧‧‧TOS 2 repository instance component/processing/TOS repository instance component/processing

1418‧‧‧ Appointment/Container Information/TOS Database

1420‧‧‧TOS database

1421‧‧‧IServiceResolver

1422‧‧‧TOS 3 repository instance component/processing/TOS repository instance component/processing

1425‧‧‧ Actual creation

1430‧‧‧Cache memory

1432‧‧‧TOS 1 type TOS

1434‧‧‧TOS 2 type TOS

1502, 1504, 1800, 1902~1906, 2401A~2406A‧‧‧ users

1720‧‧‧User/Mobile device or desktop/browser

1722‧‧‧Repository Factory/Repository Locator

1724‧‧‧Storage repository

1728, 1810, 1810B, 1810C, 1810D, 1811C, 1811D‧‧‧ data sources

1730‧‧‧Request/Appointment Request/Reservation Request

1740‧‧‧Get appointment information

1746‧‧‧Reservation of commercial objects

1748‧‧‧ Appointment details

1804, 1804B, 1804C, 1804D‧‧‧ service layer

1808, 1808B, 1808C, 1809C‧‧‧Distribution station operating system

1808D, 1809D‧‧‧Distribution Station Operating System/TOS Type

1809D‧‧‧Distribution Station Operating System/TOS Type/TOS

1822, 1822B, 1822C, 1822D, 1824, 1824C, 1824D, 2428B‧‧‧ repository examples

1826‧‧‧Repository instance/repository/website service

1826D‧‧‧Web Service/Repository Instance

1828D, 2297, 2299, 2446B‧‧‧TOS

1830, 1832, 1832B, 1832C, 1832D, 1834C, 1834D‧‧‧ database services

1912‧‧‧PA.Tos.Smart Website. Service

1914‧‧‧PA.Tos.Smart Website.Repository

1924‧‧‧PA.Tos.Smart Website.Repository.Database 2

1926‧‧‧PA.Tos.Smart Website.Repository.Website Service

2002‧‧‧Website interface

2010‧‧‧Service Layer

2032, 2034‧‧‧Information Services

2036‧‧‧Web services

2046‧‧‧Website source

2136‧‧‧Reserved items

2200‧‧‧ exemplary environment/network

2204‧‧‧ Reservation System

2208‧‧‧Reservation database/database

2212‧‧‧TOS 1 Data Repository/Repository/TOS Data Repository

2216‧‧‧TOS 2 Data Repository/Repository/TOS Data Repository

2220A‧‧‧TOS 1 user/TOS user/user

2220B‧‧‧TOS 2 user/TOS user/user

2224‧‧‧TOS 1/TOS

2228‧‧‧TOS 2/TOS

2296, 2298‧‧‧ Reservation System/President Reservation System

2232A‧‧‧TOS 1 user/TOS user

2232B‧‧‧TOS 2 users/TOS users

2240‧‧‧ Reservation System

2242‧‧‧Reservation database/reservation DB

2244, 2246‧‧‧TOS database/TOS DB

2250, 2252‧‧‧TOS/Distribution Station

2330‧‧‧Request evaluator

2331‧‧‧Availability/Availability Request Evaluator

2332‧‧‧Retain current status/retention status request evaluator

2333‧‧‧Deferred fee

2334‧‧‧ Entering the gate

2335‧‧‧ Exit gate

2337‧‧‧TMF release

2338‧‧‧TMF release reversal

2340‧‧‧Notice Transmitter

2342‧‧‧ Container Notice/Container Notice Transmitter

2344‧‧‧TMF Request Notification/TMF Request Notification Transmitter

2350‧‧‧ suspension notice

2352‧‧‧Fault Trading Evaluator/Transmitter/Fault Trading Evaluator/Transmitter Module

2360‧‧‧Reservation Notice/Reservation Notification Module

2362‧‧‧Reservation cancellation evaluator/transmitter/reservation cancellation evaluator/transmitter module

2364‧‧‧SSCO Authorization Request Transmitter/SCCO Authorization Request Transmitter Module

2366‧‧‧ Containers ready for appointment evaluator/transmitter/container ready for appointment evaluator/transmitter module

2368‧‧‧Truck Carrier Authorized Alarm Transmitter/Truck Carrier Authorized Alarm Transmitter Module

2370‧‧‧Batch process/batch process module

2371‧‧‧Import Reservation Status Updater/Reservation Status Updater-Import Module

2373‧‧‧Export Reservation Status Updater/Reservation Status Updater-Exit Module

2375‧‧‧Into the reservation status updater/reservation status updater-empty module

2377‧‧·Container Snapshot Creator/Container Snapshot Creator Module

2379‧‧‧Hidden Container Checker/Hidden Container Checker Module

2406B‧‧‧Distribution station C user

2407A‧‧ interface

2410A, 2411A‧‧‧ reservation system

2412B‧‧‧ website user interface entry

2420A‧‧‧Reservation Database

2420B‧‧‧Service Layer

2421A‧‧‧Reservation database

2422B‧‧‧TOS website entrance service

2424B‧‧‧TOS website portal repository

2426B‧‧‧Reservation repository

2432B‧‧‧ Reservation Database Service

2434B‧‧‧Database Service

2440B‧‧‧Reservation database

2442B, 2444B‧‧‧TOS/Distribution Station Operating System

2401B, 2402B‧‧‧ distribution station A user

2402E‧‧‧Full Appointment

2402G, 2404G, 2406G‧‧‧ trucks

2402F, 2402H, 2402I, 2402J, 2404F, 2404I, 2404J, 2406F, 2406I, 2406J‧‧‧ users

2403B, 2404B, 2405B‧‧‧ distribution station B users

2404H‧‧‧ Reservation Interface/Interface

2406H‧‧‧Gate operating system

2408F, 2410F, 2412F‧‧‧ website interface

2408H‧‧‧ Reservation System

2410H‧‧‧TOS database

2411B‧‧‧ expression layer

2412H‧‧ VT database

2413B‧‧‧User interface entry

2420D, 2554D, 2560D‧‧‧

2421B‧‧‧Service Layer

2431B‧‧‧ Data Access Layer

2433B‧‧‧Database Service

2441B, 2443B‧‧‧TOS/Distribution Station Operating System

2445B‧‧‧TOS/TOS website portal service

2501‧‧‧Select single/double appointment options

2502, 2516, 2557, 2592‧‧‧ slots

2503‧‧‧Specified mobile type

2504‧‧‧Hide

2506‧‧‧Container return status/empty container return status

2508‧‧‧Sterpy/empty containers

2509, 2515, 2519‧‧‧ mobile type

2514, 2590‧‧ Notice

2518, 2594‧‧‧ Double empty movement

2523‧‧‧Booking number

2525‧‧‧Post status

2527‧‧‧Scheduled summary results

2529, 2539, 2549‧‧‧ appointment details

2533‧‧‧Bill of lading number

2535, 2545‧‧‧ Status

2537, 2547‧‧‧ summary results

2543‧‧‧EDO number

2553‧‧‧Leasing voyage

2555‧‧‧One visitor/registered UTN

2559‧‧‧ Candidate Appointment

2563‧‧‧VT reservation verification

2565‧‧‧Error

2569‧‧‧Results message detail page

2571‧‧‧Remarks

2577‧‧‧ button

2579‧‧‧Modify appointment details

2583‧‧‧New single move

2585‧‧‧ Pairing button

2589‧‧‧Unpair button

2593‧‧‧Change order/bill/EDO button

2597‧‧‧Delete options

2602‧‧‧Location/Mobile Type Request for Appointment

2604‧‧‧Location/Mobile Type Import Container Unavailability Factor

2606‧‧‧Location/Mobile Type Import Container Reservation Delete Deadline Option

2608‧‧‧ Appointment time wind pressure difference

2610‧‧‧Set limit folding view

2611‧‧‧Set limit undefined position

2612‧‧‧Set limit view dock area statistics

2614‧‧‧Dock area for deck imports

2616‧‧‧Time slot for selected position/movement type

2618‧‧‧ Template

2620‧‧‧Set limit folding view

2702‧‧‧ Rate Table Information

Submitted by 2704‧‧

2801‧‧‧Managers associate

2802‧‧‧Additional user association

2804‧‧‧Big Mail

2808‧‧‧User Account Search

2906‧‧‧Notice configuration

3002‧‧ Calculation

3404‧‧‧New Custom Controls

4205‧‧‧TOS

4301‧‧‧ Truck

4305‧‧‧Reservation System API

4309‧‧‧ Reservation System Rules

4311‧‧‧TOS Verification API

4315‧‧‧TOS

4611‧‧‧Part I

4612‧‧‧Part II

4700A‧‧‧Input/Search/Selection

4700B‧‧‧ Individual Action Website URL Page

4700C‧‧‧ side menu

4700D‧‧‧ Login page

4700E, 4700I‧‧ Search

4700F, 4700H‧‧‧GUI

4700G‧‧‧Import Inquiry Search

4700J‧‧‧ Appointment Details Page

4700K, 4700L, 4700M‧‧‧ appointment action

4700N‧‧‧ Appointment details

4700Q‧‧‧Daily Information Announcement

Map of 4700R, 4700S‧‧

4710S‧‧‧ Writing direction

4700T‧‧‧Contact Information

4700U‧‧‧General Information

The various embodiments and functions of the present invention are set forth in the accompanying drawings, in which FIG. In the drawings: Figure 1 is a diagram of a shipping cycle consistent with one or more aspects of the technical innovations herein.

2 is a block diagram of a collection station operating system consistent with one or more aspects of the innovations herein.

3A is a block diagram of an illustrative model, view, and controller application, component, and/or interaction associated with an implementation of a distribution station operating system consistent with one or more aspects of the innovations herein.

3B-3C are exemplary models, views, and controller applications, components, and/or interactions associated with an implementation of a docking station operating system consistent with one or more aspects of the innovations herein. Block diagram.

4 is a block diagram showing various entities and interactions within or between such entities, as well as illustrative website or network based systems, consistent with one or more aspects of the innovations herein.

5 is a block diagram depicting various exemplary functions, services, or components relating to the present TOS website portal implementation, consistent with one or more aspects of the technical innovations herein.

6 is a block diagram depicting an exemplary carrier configuration and entity consistent with one or more aspects of the innovations herein.

7 is a chart showing an exemplary hierarchy and structure of an exemplary web-based module consistent with one or more aspects of the innovations herein.

8 is a block diagram showing an illustrative aspect of a repository mapping from a TOS to a business entity consistent with one or more aspects of the innovations herein.

9 is a chart showing an exemplary repository cache scheme consistent with one or more aspects of the innovations herein.

10 is an illustration of an exemplary TOS-independent or TOS-agnostic repository locator consistent with one or more aspects of the innovations herein.

11 is a block diagram illustrating an exemplary system topology consistent with one or more aspects of the innovations herein.

12 is an exemplary flow diagram of an exemplary user authentication and authorization process consistent with one or more aspects of the innovations herein.

13 is an exemplary flow diagram of an exemplary form identification and authorization process consistent with one or more aspects of the innovations herein.

14A-1, 14A-2, and 14A-3 show an exemplary flow diagram relating to an exemplary repository process consistent with one or more aspects of the innovations herein.

14B-1 and 14B-2 show exemplary flow diagrams relating to exemplary repository processing consistent with one or more aspects of the innovations herein.

14C shows an exemplary sequence diagram of an exemplary commercial article process in accordance with one or more aspects of the innovations herein.

14D shows another exemplary flow diagram of an exemplary commercial article process in accordance with one or more aspects of the innovations herein.

15 shows an exemplary flow of processing and associated processing via an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein.

16 shows an exemplary operational flow diagram of an exemplary TOS agnostic process consistent with one or more aspects of the innovations herein.

17A shows an exemplary flow diagram of an exemplary TOS agnostic repository locator process consistent with one or more aspects of the innovations herein.

17B shows an exemplary sequence diagram relating to an exemplary reservation process and TOS agnostic process consistent with one or more aspects of the innovations herein.

18A-18D are block diagrams depicting exemplary layer architectures for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein.

Figure 19 is a depiction of one or more aspects of the technical innovations herein An exemplary layer architecture for an exemplary TOS agnostic system and a block diagram of an associated processing module.

20 is a block diagram depicting an exemplary repository locator hierarchy/structure for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein.

21 shows an exemplary sequence diagram relating to an exemplary reservation process and TOS agnostic process consistent with one or more aspects of the innovations herein.

22A-22E illustrate block diagrams of exemplary reservation environments and systems consistent with one or more aspects of the innovations herein.

23A-23E are diagrams illustrating a reservation function or process consistent with one or more aspects of the innovations herein.

24A is a block diagram illustrating a truck company profile system or process consistent with one or more aspects of the innovations herein.

24B is a block diagram depicting an exemplary layer architecture of an exemplary TOS agnostic system for making a reservation consistent with one or more aspects of the innovations herein.

24C is a sequence diagram illustrating an exemplary TOS agnostic system for making a reservation consistent with one or more aspects of the innovations herein.

24D is an exemplary flow diagram of an illustrative workflow process consistent with one or more aspects of the innovations herein.

24E is an exemplary flow diagram of an exemplary workflow process for making a dual appointment consistent with one or more aspects of the innovations herein.

24F is an exemplary flow diagram of an illustrative workflow process for making a reservation for a plurality of collection stations consistent with one or more aspects of the innovations herein.

24G is an exemplary flow diagram of an exemplary workflow process for a reservation interface having a gate operating system consistent with one or more aspects of the innovations herein.

24H is an exemplary block diagram of an exemplary workflow process with a reservation interface for a gate operating system consistent with one or more aspects of the innovations herein.

24I is an exemplary flow diagram of an exemplary workflow process for RFID registration consistent with one or more aspects of the innovations herein.

24J is an exemplary flow diagram of an exemplary workflow process for truck company registration and appointment consistent with one or more aspects of the innovations herein.

25A-25I and 25K-25V are diagrams of exemplary subscription user interfaces consistent with one or more aspects of the innovations herein.

26A-26F are diagrams of exemplary subscription user interfaces consistent with one or more aspects of the innovations herein.

27A-27B are diagrams of exemplary subscription user interfaces with payment functionality and functionality consistent with one or more aspects of the innovations herein.

28A1 through 28A4 and 28B through 28E are diagrams of exemplary subscription user interfaces consistent with one or more aspects of the innovations herein.

29A-29C are diagrams of exemplary subscription user interfaces consistent with one or more aspects of the innovations herein.

30 is a chart of an exemplary delay fee calculator user interface consistent with one or more aspects of the innovations herein.

31 is a chart of an exemplary venue management user interface consistent with one or more aspects of the innovations herein.

32A-32B are diagrams of exemplary shipping company user interfaces consistent with one or more aspects of the innovations herein.

33 is a chart of an exemplary truck shipping company user interface consistent with one or more aspects of the innovations herein.

34A-34B are diagrams of exemplary administrator daily message user interfaces and functions consistent with one or more aspects of the innovations herein.

35A-35C are diagrams of exemplary report user interfaces consistent with one or more aspects of the innovations herein.

36 is a diagram of an exemplary broadcast email user interface consistent with one or more aspects of the innovations herein.

37A-37C are diagrams of exemplary EIR user interfaces consistent with one or more aspects of the innovations herein.

38 is a chart of an exemplary release user interface consistent with one or more aspects of the innovations herein.

39 is a chart of an exemplary reporting user interface consistent with one or more aspects of the innovations herein.

Figure 40 is consistent with one or more aspects of the technical innovations herein An exemplary multi-tracking user interface chart.

41 is a diagram of an exemplary device history user interface consistent with one or more aspects of the innovations herein.

Figure 42 illustrates an exemplary block diagram for the integration of a reservation system and a gate consistent with one or more aspects of the innovations herein.

Figure 43 illustrates an exemplary block diagram for truck arrival at a collection station consistent with one or more aspects of the technical innovations herein.

Figure 44 illustrates an exemplary block diagram for an OCR collection station and gate entry consistent with one or more aspects of the innovations herein.

Figure 45 illustrates an exemplary block diagram of a pre-notification for a container consistent with one or more aspects of the innovations herein.

Figure 46 illustrates an exemplary graph of a time slot situation consistent with one or more aspects of the innovations herein.

47A-47U are diagrams of exemplary action-reserving user interfaces consistent with one or more aspects of the innovations herein, including a landing page (FIG. 47A), a landing page landing page (FIG. 47A). 47B), menu (Fig. 47C), login (Fig. 47D), gate inquiry (Fig. 47E to Fig. 47F), import inquiry (Fig. 47G to Fig. 47H), reservation (Fig. 47I to Fig. 47P), daily message (Fig. 47Q) ), the location of the collection and distribution station (Fig. 47R to Fig. 47S), the contact person (Fig. 47T), and the related (Fig. 47U).

Detailed description of the preferred embodiment

Reference will now be made in detail to the various embodiments of the embodiments, In the following detailed description, many specific The details are provided to provide a thorough understanding of the subject matter presented herein. However, it will be apparent to those skilled in the art that the practice of the subject matter can be practiced without such specific details. In addition, the specific embodiments described herein are provided by way of example and are not intended to limit the scope of the invention to the particular embodiments. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure the invention.

Figure 1 illustrates the shipping environment, the parties involved, and the logistics framework. In a typical shipping cycle, for example, the supplier 102 uses the shipper 104 to transport the cargo, which is typically carried by the cargo contractor 106 during transit of the cargo via the public carrier 108 and through the customs 110. The goods are then subsequently carried by the broker 114, who delivers the goods to the consignee 116 and ultimately to the distribution center 118 and the retailer 120.

In accordance with aspects of the present invention, various computer hardware, software, user interface (UI) and/or communication functions may be utilized or involved in novel ways to provide the innovative systems and methods herein. According to some embodiments, for example, an exemplary implementation may include a set of computer network based applications and machine readable instructions interfaced with a TOS (Distribution Station Operating System) of a collection and distribution station. In some embodiments, the implementations herein can provide instant access to information and provide tools for commercial parties including SSCOs, trucking companies, brokers, consignees, etc., to update the information, for example, via this interface. Consistent with this disclosure, some implementations can drive operational efficiency and/or improve customer service. Some additional beneficial characteristics of various implementations may include, for example, one or more of the following: minimizing the problem of cargo movement at the terminal; improving the ability of the operator of the collection station to successfully service the SSCO and the carrier; The role of the broker between the trucking company and the shipping company removes the terminal; eliminates the reliance on telephone, fax and other non-electronic instructions to the terminal; delivers immediate, accurate information that the carrier can use to quickly pass through the gate of the terminal Preventing crowding stations/gates from being crowded; and/or accelerating troubleshooting of improved turnaround times for physical transfer of goods/cargo.

The various implementations herein have the ability to minimize communication and simplify various aspects of the process. In addition, some implementations can also achieve this benefit by interfacing with other applications, such as associated tracking applications. Here, for example, this application can facilitate logistics information sharing and communication processes between members of the shipping industry.

In accordance with such systems, methods, and functions herein, the present invention possesses performance and the ability to provide network-based visibility and functionality to a collection station from a variety of locations at any time. For example, via the functions and functionality associated with the present systems and methods, the implementation of this document may allow a trucking company to be notified when the container is ready for picking, handled by the driver, or missed a reserved time slot, and the like. In addition, trucking companies can be presented with quick links to access, check and update truck-related information about trucking companies.

In addition, some systems and methods for implementing the scheme may provide users with access to instant ship schedules, import and export container information, gate activities and/or user account information generated from the TOS. The distribution station manager can set the specific configuration and information of the distribution center; perform user account management and setting for automatic transmission of email or fax to the user.

2 illustrates an exemplary architecture of some exemplary implementations for using a particular method, which may be hierarchical, module based Basic and / or TOS is unknown. Examples of the various functions shown herein are described below.

Hierarchical architecture / business logic / data access

Referring to Figures 2 and 3A, an illustrative system including representations of exemplary expression layers 214, 301 can be shown in Figure 2, which can be built on ASP.NET and can involve hierarchical or hierarchical processing In this aspect, the hierarchical process or layered process includes the functionality of business logic, at least one domain layer 303, and/or at least one material access layer 305.

Hierarchical architecture

According to some of the systems and methods, the innovative hierarchical architecture of the present invention can provide a separation of concern and code factorization, which can be provided in some implementations without interfering with other parts of the application. The ability to update or enhance existing functionality and add new functionality and/or split the layer into separate entity hierarchies to improve scalability by adding more computing resources with increased usage. Splitting the source code into layers allows the individual layers of code to be individually edited/added/deleted/etc. so that some elements can be changed without affecting other elements of the system. According to one example of the present system and method, as illustrated in the exemplary implementation shown in FIG. 2, the technical innovations herein can be in four layers: expression 214, service 222, business logic 220, and data storage. Process and/or operate in 250 layers.

In some embodiments, the business logic in the present systems and methods may be represented by a domain model of the domain layer 303, which may or may be a conceptual model representing various business domains of the system. Here, for example, this field Models can mix data and processes, have multi-valued attributes and complex networked connections, and/or utilize inheritance capabilities. Domain layer 303 can include domain models and can define interactions between elements of the domain model.

As shown in FIG. 3A, for example, the material access layer 305 can be assembled as a layer in communication with a data store for storing and retrieving commercial items. In such an implementation, the material access layer 305 can include a create, read, update, and delete (CRUD) method, transaction management, data parallelism, and query mechanism to allow the business logic layer to retrieve objects for any given criteria. .

Different collection and distribution station operating systems can use different data preservation techniques and may require different methods to access the saved data, which has been solved in this paper. For example, this access may have to include access to a relational database from a different vendor (Oracle, MS Sql, MySql, etc.), or this access may be an access to the endpoint of the WS*-compliant website service. take. Implementations designed to be TOS agnostic may have to switch data access methods with minimal impact at the business logic and presentation layers.

According to further implementations, the systems and methods herein can be designed or assembled to be loosely coupled according to the principle of dependent inversion (DIP). In some embodiments, such a dependent inversion principle aspect may clarify that higher order functions (eg, business logic layer information or processing) may not rely on lower order classes (eg, data access layers). For example, a business logic layer or the like may instead rely on the abstraction of the required classes of the classes in the data access layer. Therefore, the data access layer can be easily replaced with other materials that can be abstracted or used with different architectures and technologies.

Here, the attached appendix / computer program (CD) material is exemplified above, Specific aspects and interrelationships of the functions described below and elsewhere herein.

Expression layer

In some other implementations, the presentation layer may include or involve components such as the Model-View Controller (MVC) framework as illustrated in Figures 3B and 3C, which can implement the model-view- Controller mode. This MVC mode can be used to model the domain, expression, and action into three separate classes based on user input 204: Model. Model 302 can contain or represent data that the user is using to work (eg, a view model or a domain model). The model 302 can manage the behavior and data of the application domain, respond to requests for information about the state of the model (usually from a view), and respond to instructions (usually from a controller) to change state.

View. View 310 manages the display of information. The view can be utilized to render portions of the model 302 as a user interface ("UI").

The controller 306 interprets the mouse and keyboard inputs from the user 204 to in turn notify the model 302 and/or view 310 to change as appropriate.

Exemplary details of this MVC framework are seen in Figure 3B, which shows an exemplary structural relationship between three objects. In addition, Figure 3C shows one set of exemplary interactions in an MVC application. In this example, controller 306 can incorporate HTTP input and provide an output represented as data in model 302, which in some implementations can be stored in relational database 314. The controller can feed this material to the view 310 via the expression model 308, which can determine how the material is displayed, and can prompt the user of the care response 312 or interact with the user of the care response 312. For example, the controller Receive HTTP messages, which may include details of user requests. Once the controller receives the user request, the controller can create a model to process the request and use the model to communicate with the repository. The model can be filled with information from the database or used to update the database. The model can be used to create a view that will be returned as a response.

The presentation layer also includes logic to support various mobile devices used by end users including automatic redirection and responsive UI.

Service layer

According to various implementations herein, the service layer can define a boundary of an application having a layer that establishes a set of available jobs and coordinates the response of the application in each job. In some embodiments, the service layer will include service contracts and work contracts that are used to define service interfaces that will be exposed at service boundaries. Data contracts are also defined to pass in and out of the service.

In addition, various systems and methods herein may implement a WCF [Windows Communication Foundation] service or similar service from Microsoft Corporation. However, the service boundaries can be explicit, and this situation includes or involves all the details of the implementation behind the hidden service boundaries. This may include displaying or specifying which particular technology is used.

In conjunction with the above, as explained in more detail in conjunction with FIG. 5, the systems and methods herein may include or involve an operational service, an infrastructure service, an appointment service, a payment service, an announcement service, and/or a reporting service.

In some implementations, the service layer 222 can be compiled into a separate class combination and hosted in a service host environment. Here, for example, the application layer 214 will only know and can use this layer. Whenever the service layer 222 receives the request, please The request can be dispatched to the business logic layer, and the business logic layer can perform the requested task. In such implementations, if the business logic layer requires any database support, the business logic layer can always review the data access layer.

Referring again to FIG. 2, a representative service layer 222 is illustrated in which a boundary of an application having a layer can be defined that establishes a set of available operations and coordinates the response of the application in each of the operations, the service layer 222 can include a service contract and Operating contracts, which are used to define the service interface that will be exposed at the service boundary. Data contracts can also be defined to pass in and out of the service.

In an exemplary instantiation, the present invention may implement a WCF (Windows Communication Foundation) service 216, a framework for building service oriented applications. However, in such instantiations, the service boundaries can be explicit, and this condition implies hiding all the details of the implementation behind the service boundary 222. This may include displaying or specifying which particular technology is used.

5 is a block diagram depicting various exemplary functions, services, or components related to the present TOS website portal implementation 514 consistent with one or more aspects of the innovations herein. Referring to FIG. 5, embodiments of the present system may include or involve components such as job service 502, subscription service 580, payment service 560, announcement service 520, reporting service 540, and/or infrastructure service 590, among other such components. Some of these exemplary services are shown in Figure 5. In some exemplary implementations, the job service 502 component can include subcomponent services to handle the inlet 504, the outlet 510, the device control 506, and the gate activity 508. Similarly, the illustrative notification service 520 can include subgroups for gate activity 522, reservation status 524, subscription 526, delay fee 528, and container status 530. Service. Reporting service 540 may include sub-component services for import container 542, ship schedule 544, exit order 548, gate activity 546, bill of lading 550. Payment service 560 can include subcomponent services for delay fee 562, rate table 566, and payment 564. Reservation service 580 may include sub-component services for import full 582, empty entry 584, exit full/empty 586, and chassis in/out 588. The infrastructure services 590 can include subcomponent services for the user account 592, at least one field service 594, and the SSCO service 596. Infrastructure services may include functionality for setting up and managing information in the application, such as users, trucking companies, shipping lines, and the basic entities of the venue.

In another example, the service layer 222 can be compiled into a separate class combination and hosted in a service host environment. Application layer 214 only knows and can use this layer. Whenever the service layer 222 receives the request, the request can be dispatched to the repository 226 and the business logic layer can handle the request. The repository 226 can access the material access layer 250 if the repository 226 requires any database support.

Business logic layer

Referring again to FIG. 2, the third layer in the illustrated example is the business logic layer 220. Such business logic associated with the TOS website portal 514 implementation of this document may be represented by a domain model that is a conceptual layer representing the business domain of the TOS website portal 514. Such domain models are free to mix data and processes, have multi-valued attributes and networked, and use inheritance.

According to an exemplary TOS website portal 514 implementation scenario, the domain model can be assembled into a database design that looks like a general domain object for each database table. Moreover, here, because business behavior is subject to change, it is important to be able to easily modify, build, and test this layer. Such as This allows for the minimum coupling function from the domain model to other layers in the system.

Entity. The implementation of this TOS website portal 514 may define a commercial item as an entity, such as a bill of lading, container, equipment, ordering, release, appointment, delay fee, payment, ship schedule, announcement, and the like. Each entity can represent some meaningful individual in the business world. These objects simulate information in the business and articles that capture the rules of commercial use. Define inheritance, composition, and aggregation relationships between these entities. Figure 6 depicts an example of an entity in a subscription module. The carrier entity has the nature of the ship, port, partner and ordering line entity, and there is a one-to-one relationship between the above, in addition to the ordering line. The ordering and ordering lines have a one-to-many relationship. The ordering entity may have one or more exit container entities inherited from the cargo box object. The export container entity has an export container status, an export container terminal status, and a trucking company entity as a property and has a one-to-one relationship. Here, for example, the ordering item 608 can have the status of the vessel 618, the port 620, the partner 622 item, and the trucking company 616 and the export container 606.

Data access layer

Referring again to FIG. 2, the fourth layer of the example is data access layer 250. In some implementations, the material access layer 250 is a layer that is only responsible for talking to the data store and for storing and retrieving commercial objects. The layers may include create, read, update, and delete (CRUD) methods, transaction management, data parallelism, and/or querying mechanisms to allow the business logic layer to retrieve objects for any given criteria.

Repository. Referring again to FIG. 2, repository 226 mediates between, for example, the application's data access layer 250 and the business layer 220. In some implementations, the repository 226 can query the data source, map the data from the data source to the business entity, and save the changes in the business entity and present the changes to the data source. In addition, repository 226 can separate business logic from interaction with underlying data sources.

4 is a block diagram showing various entities and interactions within or between such entities, as well as illustrative website or network based systems, consistent with one or more aspects of the innovations herein. The collection station operating system information may be input by devices 401-413, including but not limited to computers, laptops, mobile devices, servers, etc., each of which may be from a plurality of collection station operating systems 429, 431, and 445 Any one of them requests and obtains the information of the distribution station. Any of the data requests 1-7 can be entered at any of the devices 401-413. In this example, the information request is transmitted via the network 415 to the TOS website portal instance A 417 or the TOS website portal instance B 433. In FIG. 4, requests 1-3 are processed by website portal A 417, and requests 4-7 are processed by website portal instance B 433. Request 1 is a request for a list of the distribution terminals of the collection and delivery station A operating under the distribution station operating system A. The request is routed to the website portal instance A and processed by the exit service 421. The GetBookingList method is called by the egress service to the TOS A repository 425 and specifically to the egress repository, which is obtained from the egress repository. If the requested repository type is already cached, the repository instance is used to retrieve data from the TOS A database 429. However, if the requested subscription repository type is not in the repository cache, the repository instance is created and added to the cache. The list of postings is retrieved from the TOS A repository 429 using this newly created repository instance. Once retrieved, the posting list information provided in the TOS A format is mapped by the repository 425 to a TOS agnostic format such as a commercial entity or commercial object format, the TOS agnostic format being The same way is processed and presented to the user, regardless of which TOS the data was obtained from. The conversion from the TOS agnostic format to the TOS specific format is performed in the repository. Thus, all data requests/commands entered by any of the devices 401-413 are processed in a TOS agnostic format. The TOS agnostic data is converted into a data format compatible with different collection station operating systems only when directly interfaced with the terminal operating system. Therefore, the user can interact with a plurality of collection and delivery station operating systems from a single device without having to care about the collection and delivery station operating system used by each of the collection and distribution stations.

A similar process can occur for each of the remaining requests 2-7, and the difference is in the visited website portal instance, service, and repository. For example, the user at device 403 requests an export container list (#2) for the collection and delivery station B to operate using the terminal operating system B different from the terminal system A. Request 2 to the export container list is routed to the export service 421 of the website portal instance 417. The GetExportContainerList method is called to the exit repository of the TOS B repository 427. This export repository retrieves the requested export container list from the website portal service TOS B 431 via the network 447. Website entry instance A 417 returns the export container list 403 to device 403.

The user at device 407 can enter an update of the bill of lading (B/L) status for the collection station C using the collection and delivery station operating system C. The update is entered in the TOS Agnostic Data format. The import service 437 transmitted to the website portal instance B 433 is updated. The import repository call from the import service 437 to the TOS C repository 443 calls the update B/L method. Within the TOS C repository 443, the import repository maps the user input of the B/L update status to the TOS C data format and transmits the update to the TOS C API 445. In response, TOS C API 445 will A confirmation or other answer is transmitted to the TOS C repository 443. The TOS C repository 443 converts any data in the TOS C format into a TOS agnostic format and returns relevant information to the device 407. As another example, the user at device 413 inputs a request for the posting list information for the collection station C to operate using TOS C different from TOS A and TOS B. The request is forwarded to the export service 439 of the website portal instance B 433. The export service 439 calls the GetBookingList method to the export repository of the TOS C repository 443.

Referring to Figure 4, an example interaction with other entities such as a trucking/reservation system 459 (e.g., a system such as VoyagerTrack) and another TOS system/interface 457 (e.g., a system such as M21) is shown. . Information and materials may be processed throughout the service layer of any such system or entity through the functionality of this document. For example, request 477 from truck shipping/reservation system 459 can be processed consistent with request 475 regarding gate failure (#3) from entity 405. Also by way of example, request 473 from another TOS system/interface 457 can be processed in concert with request 471 from the list (#1) of entity 401.

Module-based application

In some examples of the systems and methods herein, the TOS website portal 514 can be a module-based application and can include modules that can be added and removed independently. Each module can be defined as a .NET combination (dynamic link library combination) within the TOS website portal 514. In addition, the module may be responsible for exposing the business logic to clients of any entity that is using the module.

If the user wishes to modify the module implementation, the change can be tied to only the module. This module-based architecture allows modules and customers The end evolves separately. New versions of existing modules can be deployed without affecting existing client applications. In addition, new versions of existing client applications can be deployed without affecting existing modules.

According to some implementations herein, the development of a module in such a TOS website portal implementation may have one or more of the following characteristics, some of which are depicted in Figure 7:

● Interface-based programming

The separation of the characterization interface from the implementation scheme. Here, for example, the client can be encoded with respect to the abstraction (interface) of the service rather than the specific implementation (object) of the service. Therefore, changing the implementation details on the server side or even switching to a different service provider does not affect the client.

● Position transparency

The TOS website portal implementation 514 can contain multiple modules. These modules may all exist in the same process, in different processes on the same machine or on different machines on the network. However, there may be nothing in the code of the client about where the object is performing.

● Version management support

The implementation of this document can deploy new or updated versions of existing modules without affecting other modules. Thus, modules can be allowed to evolve along different paths, and different versions of the same module can be deployed side by side on the same machine or even deployed in the same client process.

Referring to FIG. 7, the implementation of the TOS website portal 702 herein may include, involve, and/or access services such as the job service 704, the infrastructure service 705, the reservation service 706, the payment service 708, the announcement service 710, and/or the report service 712. . The user interface of the TOS website portal 702 can support various devices such as mobile devices, personal computers, and the like. Here, for example, the exemplary infrastructure services herein may provide an interface for a user to manage a user account, add or update a ship line, and/or change a site configuration, and the like. In addition, the appointment service may be utilized by the trucking company or used by the trucking company to create, read, update, and delete appointments for picking up or delivering containers at the terminal. Divergent station users can use such services to plan capacity and manage workloads. In a further implementation, the subscription service may also have reporting functionality.

In addition, referring also to FIG. 7, embodiments of the TOS website portal 702 herein may include, relate to, and/or may use the performance of the following modules: an import 714, an outlet 716, a gate 720, and a device capable of replacing the traditional functionality in existing systems. The control 718 module, the report 730 for the associated tracking application/component, the subscription 724, the payment 726 and the announcement 728 module, and/or the combination manager module 722 of both applications.

TOS is unknown

Some implementations or instantiations of the systems and methods disclosed herein may include a TOS agnostic design. That is, the system is configured such that the job can occur without "care" about the various processes with which TOS the system is involved. In the context of the framework set forth above, such an implementation may include configuration as a repository-mode. The repository mode is used to allow the distribution station operating system (TOS) to be independent. Each TOS can use its own unique capital Library outline.

8 is a block diagram showing an illustrative aspect of a repository mapping from a TOS to a business entity consistent with one or more aspects of the innovations herein. Referring to Figure 8, the illustrative repository 806 can separate the logic for retrieving material and mapping the data to the entity model from the business logic that acts on the model. Moreover, the business logic may not know the type of material that contains the data source layer 810. For example, the material source layer 810 can serve a database or a website. FIG. 8 shows an exemplary repository mapping from TOS to business entities 804, 812.

9 is a chart showing an exemplary repository cache scheme consistent with one or more aspects of the innovations herein. Here, for example, the backup storage for the data may be a business service exposed by the business line (LOB) application 908. Service calls are often expensive and benefit from the cache policy implemented within repository 906. In such a situation, the query logic in repository 906 may first check to see if the queried repository instance is at cache 912. If the instances are not in the cache, the repository 906 accesses the website service to retrieve information. This exemplary cache scheme is shown in FIG.

10 is an illustration of an exemplary TOS-independent or TOS-agnostic repository locator that is consistent with one or more aspects of the innovations herein. Referring to the representative diagram of FIG. 10, the TOS website portal service component 1004 can be designed to support multiple terminals with different collection station operating systems. To support a multi-distribution station in a TOS-agnostic manner, the service component 1004 can include or involve another component or application that performs processing associated with the repository and looks up the repository, the repository providing a decentralized collection base repository 1016 , 1018, 1020 access. Here, for example, this functionality can be used by the repository. The locator assembly or device 1008 is implemented.

According to the implementation herein, the repository locator 1008 can centralize distributed repository lookups, provide centralized control points, and can act as cache memory to eliminate redundant lookups. Additionally, an exemplary TOS-independent repository locator is shown in FIG. Additional technical details of some TOS agnostic technological innovations are further described below and in the included appendices.

System and process architecture

The design and architecture of some of the examples of systems disclosed herein allows the present TOS website portal implementation scheme 514 to be an addition to any existing TOS as opposed to a single TOS integration. This approach allows the innovation and functionality of this technology to be incorporated into any existing TOS via the Web Services API layer. Interfaces to other TOSs can be implemented without redesigning or rebuilding the TOS website portal implementation.

11 is a block diagram illustrating an exemplary system topology consistent with one or more aspects of the innovations herein. For example, multiple instances of the TOS website interface server will be deployed in two physical locations to support multiple terminals. A location has two instances (1120 and 1124) connected via a network switch. Network switches distract user requests to balance the load in each server instance. Another set of server instances (1128 and 1132) are performed in the same manner but in different physical locations to compensate for challenges such as earthquakes in a particular location, power shortages, and the like. As such, multiple instances of the TOS website portals 1120, 1124, 1128, 1132 can be used to interface with a plurality of different TOS systems 1136, 1140, 1144, 1148, 1152, 1156, even across multiple Internet providers 1104, 1108 interfaces with the different TOS systems, all such networks The network provider interfaces with the central cloud server 1102. The central cloud server 1102 can communicate with various end users (e.g., laptops, desktops, mobile devices, tablets, etc.) as shown in more detail in connection with Figures 46A-46S.

Object Oriented Programming (OOP)

The system and method of this paper can also be combined using the concepts and rules of object-oriented programming. Here, for example, some implementations may utilize object data structures and methods consisting of data fields - these methods are set together with the abstraction of the business process used for the operations of the collection station. Such implementations utilizing object-oriented functionality and/or programming can provide many benefits, such as in one or more regions of reusability, extensibility, decoupling, maintainability, and/or reduced complexity.

Reusability. Some exemplary object-oriented implementations with reusability functionality can be grouped using classes that can be used by several applications. For example, such systems and methods may define a shared business model as an object and use classes to represent such items, such as containers, ships, ports, partners, appointments, delays, payments, announcements, and the like. Here, an exemplary configuration may include a configuration such as found in an Insert X1: Reusability Code Example:

X1: Reusability

In the object-oriented approach, we build classes that can be used by several applications. A smart website defines a shared business model as an object and uses classes to represent such items, such as containers, ships, ports, partners, appointments, delays, payments, announcements, and the like.

Here, such construction and definition of the object can be reused many times throughout the application. In addition, the same object can be used to extend existing functionality or add new features to the application. Therefore, the work object can be used to modify the application and therefore the code does not need to be written from scratch. Such reuse of objects reduces the effort to recreate the objects and reduces the likelihood of introducing errors. This not only saves development time, but also improves the robustness of such applications.

In addition, various OOP programming functions and modules can be reused. For example, the following insert X2: A table instance can be used to call a method in a service. The same function can also be used throughout the application because the method is a defined OOP practice.

X2: Reuse

These definitions of objects can be used throughout the application. In addition, the same object can be used to extend existing functionality or add new features to the application. You can modify the application using work objects instead of writing code from scratch. Reuse of objects reduces the effort to recreate the objects and reduces the likelihood of introducing errors. This not only saves development time, but also improves the robustness of the application.

In OOP programming, functions and modules can be reused. The following methods can be used to call a method in a service. The same function is used throughout the application in this example because the method is a defined OOP practice.

Extensibility. To illustrate such a function, see Insert X3. Assume that the truck driver is a prominent partner. Here, the implementation scheme can then define the truck driver by inherited the partner. In this way, implementing the scheme eliminates redundant codes and extends the use of existing classes.

X3: extensibility

The truck driver is a partner. Therefore, we inherit the partners To define the truck driver. By doing so, we can eliminate redundant codes and extend the use of existing classes.

Decoupling. With regard to decoupling, systems and methods can be assembled to use an interface instead of using an implementation scheme to decouple the module. In some implementations, such as insert X4, the repository object can be defined to meet the interface. This decoupling of the interface from the implementation allows the application to be TOS agnostic; here, the exemplary configuration can be structured as follows.

X4: Decoupling

OOP practices in smart websites can use the interface rather than the implementation scheme to decouple the modules. For example, a repository object is defined to meet the interface. This decoupling of the interface from the implementation allows the application to be agnostic to the TOS.

Maintainability. With the use of the objects and various OOP functions, the functions defined in such implementations can have extremely simple return values and parameters compared to the return values and parameters in existing systems. The following table shows some illustrative examples, as seen in Insert X5:

X5: Maintainability

Using objects, the functions defined in this article can have very simple return values and parameters. E.g.

Reduce complexity. Here, given challenges in business can be considered Some different objects. Each item may represent a business entity and may have all relevant commercial properties and processes as a property and method. This abstraction reduces the complexity of the problem and makes the problem manageable. For example, in insert X6, the EquipmentControlEditModel object abstracts all commercial properties and processes associated with managing the container or chassis in the distribution station.

X6: The complexity of the reduction of the puzzle

A given problem in business can be seen as something different. Each item may represent a business entity and may have all relevant commercial properties and processes as a property and method. This abstraction reduces the complexity of the problem and makes the problem easy to manage.

For example, the EquipmentControlEditModel object abstracts all commercial properties and processes associated with managing containers or chassis in a distribution station.

This modularity allows the item to be maintained independently of other items. Objects can be independent of one another and can be maintained separately. Can not affect the functionality of other objects In the case of modifications in the object.

safety

Embodiments of the TOS website portal system and method may have one or more of the following security implementations: authentication to authenticate the user; authorization to determine which jobs the user can perform and which resources to access. The confidentiality of the protection that helps ensure the publication of sensitive information; and the integrity of user data that protects against changes, transmissions between the client and the server. 12 is an exemplary flow diagram of an exemplary user authentication and authorization process consistent with one or more aspects of the innovations herein. Referring to the exemplary process of FIG. 12, the user submits a request 1202 for a restricted resource, and the system verifies that the user is authenticated 1206. If not, the user must log in to 1218. Once the user is authenticated, the system can verify that the user has permission 1210, and or so, access to resource 1214 is allowed, or access 1222 is denied.

In some exemplary implementations of systems and methods, the identification can be found in different methods. Examples of such methods are, in particular, Windows authentication (users signaling to windows), formal authentication (using web pages to register), pass authentication (using Microsoft's pass (currently also known as Live Id) for authentication) Wait.

Formal authentication can allow for use from the Internet and limit usage to approved consumers. In addition, formal authentication can be a system based on tokens. For example, when a user logs in, the user can receive a token with basic user information. This information can be stored in the encrypted cookie, which is attached to the response, so the information is automatically raised on each subsequent request. cross. 13 is an exemplary flow diagram of an exemplary form identification and authorization process consistent with one or more aspects of the innovations herein. An example of this authentication process includes an initial client request 1302, which is passed to ASP.NET if the IIS authentication setting 1306 is appropriate. The system verifies that the user has assigned the authentication cookie 1310, and if so, the login form 1314 collects the user credentials and authenticates the credentials 1318. If the credential passes the authentication process 1322, the system attaches the cookie 1326 and tests if the credential is for the access authorization 1330. If the credential is not authenticated 1322 or authorized 1334, the system will deny access to 1338. If the credential is authenticated 1322 and authorized 1334, the system will allow the user to access the protected resource 1342.

In addition, the authoring system and method can use an authorization model. For example, an implementation scenario can be assembled to use a license-based security model. This model can have predefined roles, such as roles that perform functions similar to "groups" or "types" of existing systems. However, in some embodiments, an implementation may require a license for each action that requires a security confirmation, such as:

● To view or update the page, the user needs permission for the action.

● In order to observe or update the data/field, the user needs permission for the action.

● When the user wants to observe the list of imported containers, the user should have appropriate permission for the import container list page.

● When the user wants to update or save the contents of the imported container page, the user should have appropriate permission for the import container list page.

According to these implementations, the role can be made by the role A set of permissions allowed to define. A user can have multiple roles and will then have all the licenses belonging to each role. Such functionality allows the user to have a different role for the shipping company in the venue, or to have the same role for all shipping companies in the venue, or for all shipping companies and all venues.

In addition, implementations can have predefined roles and custom roles. Here, for example, the predefined role instances may include a user manager, a gate manager, a high capacity user, a reservation manager, a super manager, an SSCO user, a sink user, and possibly others. Custom roles allow users to have customized roles (a set of permissions). The administrator module of the TOS website portal system of this document may provide tools to assign licenses to users who will be saved as new roles, such as ABCD Manager, XYZ-Bob, and the like. In addition, these custom roles can be reused. In still other implementations involving security, the ASP.NET security framework can have a standardized user account system that supports all shared user account tasks, including registration, managing passwords, and setting personal preferences.

According to additional embodiments herein, there may be other functional areas that are practicable, including one or more of the following:

●Subsidiary, including a repository for registering user accounts and accessing account details and credentials

● Roles, including placing users in a group (possibly overlapping) of groups, usually for authorization

● Profiles that allow users to store arbitrary data on a per-user basis

It should be noted that ASP.NET provides an implementation for each of these three regions, however, some systems may be configured by the provider's system using a custom implementation. Here, for example, a custom provider can be derived from a "built-in" abstract provider class.

Finally, with regard to some implementation options, the system and method of this document involving the entry function of this TOS website can use SSL (Secure Data Transport Layer) in all modules.

TOS unknown details and aspects

The implementation of this document may involve the hierarchical architecture set forth above. Layers represent logical separations, such as introducing different combinations in the same process space. Layering provides separation of concerns and better code factorization, which gives us maintainability and scalability. According to various implementation schemes herein, there may be four layers in the TOS website portal system and method - an expression layer, a service layer, a business logic layer, and a data access layer.

The business logic layer/situation in this paper can be represented by a domain model, which can be a conceptual model representing the TOS website entry business domain. For example, domain models mix data and processes, have multi-valued attributes and complex phase networking, and use inheritance. In addition, the data access layer can be a layer that is only responsible for talking to the data store and for storing and retrieving commercial objects. The layers may include create, read, update, and delete (CRUD) methods, transaction management, data parallelism, and/or querying mechanisms to allow the business logic layer to retrieve objects for any given criteria.

Different collection and distribution station operating systems may use different data retention techniques and may require different methods to access the saved data. For example, for the connected but Access to databases from different vendors (Oracle, MS Sql, MySql, etc.), or access to endpoints of WS*-compliant web services. For TOS-agnostic systems, the system can switch data access methods with minimal impact on the business logic layer and the presentation layer.

Repository - Mode. The repository mode functionality and functionality of this article can be used to make the application independent of the TSS. For example, a repository may separate the logic for retrieving data and mapping data to a solid model from the business logic that acts on the model. Business logic may not know the type of material that contains the data source layer. For example, the data source layer can serve a database or a website.

In addition, in some implementations, backup storage for data can be a business transaction exposed by a business line (LOB) application. Service calls are often expensive and benefit from the cache strategy implemented within the repository. In this case, the logic first checks to see if the repository is in cache memory. If the repository is not in the cache, the repository instance is created and placed in the cache that is subsequently utilized to retrieve the requested information.

Service Locator Mode. This article service locator mode functionality and functionality defines the components that know how an application can retrieve a service. The calling program does not need to specify a specific type; the calling program can indicate an interface or an abstract type. The service locator pattern hides the complexity of component lookups, handles cache or polling of instances, and generally provides a common supply for component discovery and creation.

The focus in the service locator mode can achieve the lowest possible amount of coupling between components. The locator represents a centralized console that the application uses to obtain all the external dependencies that the application requires.

As such, the present implementation can be designed to support multiple terminals with different terminal operating systems. To support multiple collections in a TOS-agnostic manner, the TOS website interface application can involve processing to find a repository that provides access to each of the distributed collection database.

Repository initialization

Turning back to the overall aspects of the technical innovations herein, Figures 14A and 14B-1 show exemplary flow diagrams relating to an exemplary repository processing method consistent with one or more aspects of the innovations herein. Figure 14B-1 is a specific example illustrating the process outlined in Figure 14A. Detailed examples of codes that can be used by elements of the system in which the exemplary methods of Figures 14A and 14B-1 are performed can be found in Appendix 1 attached herein.

Turning first to Figure 14A-1, in 1440, the processing request can be received by the service module/processing layer. For example, the request can be a request to access and/or manipulate data in a TOS or commercial object. In response, the repository instance can be created and/or retrieved to facilitate processing of the request. In 1450, the request and/or the data associated with the request can be transferred to the repository module/processing layer. In 1452, the repository factory module/processing layer associated with the repository module/processing layer can process information to determine a repository instance that can be adapted to process the request. The repository instance may be specific to the TOS type for the TOS to be accessed and/or the repository type associated with the type of request received. In 1454, the repository type cache memory can be accessed by the repository factory to retrieve a previously generated repository implementation type suitable for the determined repository instance (eg, based on the repository type and/or TOS type). For example, the system may have received similar requests in the past to perform similar processing on the same TOS type, and may The repository has been generated in response and the repository is stored in the cache. It is also possible to store preset/usually encountered repositories. In some cases, a suitable repository may not be present in the cache memory, in which case the system may generate a suitable repository and store the repository in cache memory for future use. The relationship between the cached material and the TOS type can be determined by using reflection operations, helper attributes, conventions, and/or in some other way. For example, a reflection operation can be used to discover a TOS type that is configured to implement an interface that is assembled using a control container inversion; is included in a namespace of interest; and/or contains a TOS type attribute of interest and / or in a sub-namespace named after the TOS type of interest.

In 1456, the service resolver module/processing layer can instantiate the retrieved/generated repository by, for example, decomposing a service associated with the cached attribute material. In 1460, a repository instance can be delivered. For example, an instance can be provided to a user who makes an initial request for interaction.

In addition, as explained in more detail below, various processes and modules can be utilized in different classes, such as GetRepositoryInstance, DefaultRepositoryFactory, TosTypeAttribute, ReportRepository, ServiceAppRegistry, CoreRegistrations, RegisterTerminalRepository, and RegisterAdminRepository.

Regarding exemplary repository factory processing, for example, a repository may have a single constructor with dependencies defined as constructor parameters. However, the repository may not know how the components were created - the repository only knows which contract implementations the repository should inject into the constructor. In addition, the repository type can be decomposed based on the supplied TOS type. to this end, Introduce the IRepositoryFactory contract. Any implementation of this scenario represents the actual component that returns an instance based on some criteria.

The default repository is a DefaultRepositoryFactory that conveniently decomposes a particular repository type using reflections, helper properties, and a set of conventions. It uses the ReflectedRepositoryTypeCache utility class to hold the known type until the application is shut down.

As shown in FIG. 14A-2, once the repository factory 1401 retrieves the implementation type from the repository type cache memory 1411 for the interface type and TOS type, the repository factory 1401 can cause the IServiceResolver 1421 to build the instance. The cache memory 1411 can ensure initialization 1413 and obtain the repository implementation type 1415. Factory 1401 may include logic 1405 to define which type to instantiate, but actual creation 1425 may be delegated to IServiceResolver 1421. This allows for flexibility because all dependencies are automatically assembled.

Exemplary modules and processing

i. Repository type cache memory

The default repository factory (DefaultRepositoryFactory) is responsible for breaking down the specific repository type that will be instantiated. For example, it does this based on the TOS type of the supply station being supplied. For actual type discovery, it can use this set of conventions and helper attributes.

Within, it can use reflection to find types, such as: ● implementation of IoC-container interface; ● included in the "smart website" namespace; ● with defined (selective) selective TOS - The type attribute or (in the absence of a TOS-type attribute) has been placed in a sub-namespace named after the TOS-type.

To use an attribute or namespace, the factory tries to see if there is a defined TosTypeAttribute. If no attributes exist, the factory tries to calculate the relationship with the given TOS type by namespace. Namespace - convention is strong Convention, so attributes are only used for special situations.

As an example, consider two convenient subclasses for TosTypeAttribute: TOS1Attribute and TOS2Attribute. These subclasses are just shortcuts to allow [TOS1] or [TOS2].

The report repository for TOS1 can be tagged or placed in the namespace (or both), but placed in the namespace is clearer:

The type can be stored in the thread-safe dictionary by the Reflective Repository Type Cache when it is discovered. This situation eliminates the need for runtime reflections on each request, thus preventing performance loss. Lazy loading techniques are utilized on a per TOS-type basis in some examples, although other techniques may be used.

An example of the process mentioned above is illustrated in Figures 14A-3. The repository factory can obtain the repository instance 1431. The reflection repository type cache memory can obtain the repository implementation scheme type 1433, obtain the implementation scheme type 1435 for the TOS type, and obtain the implementation scheme type 1437 for the TOS type and interface type. Reflective repository type cache memory also ensures initialization 1441. If the cache memory already contains repository type 1443, the repository instance can be provisioned. If the cache memory does not contain the repository type 1443, the repository type can be constructed and added to the cache memory 1451-1459. In particular, in some embodiments, internal initialization 1451 may be ensured, repository implementation 1453 may be checked, enforcement 1455 may be checked, attributes and/or namespace matches 1457 may be checked, and if all checks pass, the repository is The type can be added to the cache memory 1459 and supplied.

Service resolver

To address the general service decomposition problem and gain the ability to follow the principle of dependent reversal, the IServiceResolver contract was introduced. IServiceResolver can decompose any service for the type supplied (the type supplied is an interface or a specific type), and any of its specific implementations may be able to perform "constructor injection", which is a dependent injection. Main technique.

It should be noted that IServiceResolver does not represent some specific infrastructure parts and only works on the .NET type hierarchy. The ServiceResolver is very generic and can decompose any kind of program component.

The program component may not contain any initialization code for its dependencies. The program component can receive the assembled instances only by its constructor and can never care where the instances come from. This situation completely eliminates tight coupling. There can be a unique location in the application that connects all components with wires. This location can be considered an "application architecture hub." As an example: Obtain a report repository for TOS 1 to process with TOS 1 from the user for processing The collection terminal obtained the import container request.

In one particular example of FIG. 14B-1, the service module/processing layer may send a request for a reservation repository for the first collection terminal (distribution station 1) to the repository module/processing layer. As shown, the collection station 1 can use the first TOS type (TOS 1). In 1452, the repository factory module/processing layer can retrieve the repository instance based on the reserved repository type and the TOS 1 type. In 1454, the cache memory can be searched for an appropriate implementation. In this example, a subset of cache memory 1430 contains an instance of a reserved repository for TOS 1 type TOS 1432 and TOS 2 type TOS 1434. Since the requested reservation repository is for TOS 1, the TOS 1 item 1432 can be selected. In 1456, the service resolver module/processing layer can instantiate the repository using the data retrieved from the cache memory and can send the appropriate subscription repository to the desired recipient.

About the exemplary module/processing of Figure 14B-2

Use the StructureMap library as the "backup" technology behind IServiceResolver. This can be done without any dependency on StructureMap due to the IServiceResolver design. Any other implementation of IServiceResolver can be easily supplied without changing the single line code.

The specific types of the repository can be combined in the "IoC Container Registration". In addition, no one can know the specific type of assembly used for the IRepositoryFactory except for the container registration. The ServiceAppRegistry class is "IoC Container Registration" using StructureMap and is used to assemble the repository and repository factory.

In some embodiments, such as shown in the following code and in the embodiment illustrated in Figure 14B-2, for example, processing may continue as follows. can Perform core registration (eg, data services, repository factory, user profile, etc.) 1491. Registered distribution station repositories (eg, truck shipping companies, EIR, fault gates, import containers, etc.) 1493. A manager repository (eg, user, venue, SSCO, etc.) 1495 can be registered. A reservation repository (eg, appointment, appointment limit, appointment report, etc.) can be registered 1497. Services can be registered (eg, import, export, appointment, etc.) 1499.

14C shows an exemplary block diagram of an exemplary reservation process and TOS agnostic process in accordance with one or more aspects of the innovations herein. Figure 14C is a specific example illustrating the process outlined in Figure 14D. Detailed examples of codes that can be used by elements of the system that perform the exemplary methods of Figures 14C and 14D can be found in Appendix 2 attached herein.

The TOS 1 database 1408 can be read for the subscription data 1410 and the corresponding container data 1412. The subscription data and corresponding container data can be provided in a table in a TOS 1 specific format. Data 1410 and 1412 can be read and transmitted over the network to TOS 1 repository instance component/process 1406. A similar process can occur for each of the TOS 2 repository instance component/process 1416 and the TOS 3 repository instance component/process 1422. The TOS 2 data source 1414 can be stored in the file system. Once the reservation/container data 1418 is read and transferred to the TOS 2 repository instance component/process 1416, the reservation/container data is different from the TOS 1 format and TOS 3 The formatted TOS 2 specific format is stored in the file system. The TOS 3 data source can be an API in which the Appointment Details API and the corresponding Container Detail API data are read and transmitted to the TOS 3 Repository Instance Component/Process in a TOS 3 specific format. In Figure 14C, each repository instance component / Processing corresponds to one of the reserved commercial items and one of the three TOS types. Appointment of commercial items may have multiple associated functions and properties, such as number of reservations, shipping company, ship, shipper, port of loading, port of discharge, type of reservation, order line, export container, refrigerated ship information, dangerous cargo information , EDI memo, user memo, etc. These properties may have a one-to-one correspondence with the data stored in the TOS databases 1412, 1418, and 1420, or may have a one-to-many correspondence.

Each TOS repository instance component/process 1406, 1416, and 1422 can be processed to process/transform data from a TOS-specific format retrieved from a corresponding repository into a commercial object format in a TOS-agnostic format. In Figure 14C, the transform/mapping process takes place from a TOS specific format to a commercial object format, but can also be transformed/mapped from a commercial object format to a TOS specific format. The retrieved data converted to the TOS agnostic business object format is transferred from the TOS repository instance component/process 1406, 1416, 1422 to the business object component/process 1404. The business item component/process 1404 processes the business item data, for example, based on user input. The results can be output to the service/expression layer 1402 for further processing and/or display to the user interface.

14D shows an exemplary flow diagram relating to an exemplary repository-based TOS agnostic process consistent with one or more aspects of the innovations herein. The process begins at step 1470 with accessing at least one data source containing data associated with the request. Next, at step 1480, the data within the data source is read and retrieved to fulfill the request. Subsequently, the retrieved material construction data construct from step 1480 can be used at step 1490.

Handling user requests in TOS agnostic

15 shows an exemplary flow of processing and associated processing via an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. The inventive systems and methods are not limited to a particular collection station operating system and users of the collection station. In contrast, the TOS agnostic system allows multiple users to access multiple collection and distribution stations operating under any of a plurality of collection and delivery station operating systems. Referring to FIG. 15, users 1502 and 1504 represent different users accessing a plurality of collection and distribution station sites, and the plurality of collection and distribution station sites operate under different collection and delivery station operating systems. For example, the user 1502 wishes to access the venue A where the TOS X is implemented, and the user 1504 wishes to access the terminal B that implements TOS Y, where TOS X and TOS Y are incompatible with each other. Specifically, each of the collection station operating systems operates on a proprietary language and/or data format. The same information stored by a TOS database can be described so as not to be unrecognizable and unavailable for different TOS repositories.

Conventionally, a user wishing to access data from a terminal of a terminal of a different terminal system may need to access an interface of a terminal system that is specific to the site of the terminal. However, consistent with the state of the art innovation, the data request is processed regardless of the collection station operating system used, such that each user 1502, 1504 can access any desired collection site. At step 1508, a data request can be received by the TOS agnostic system for either or both of the collection station A and the collection station B. For example, the user interface provides a list of distribution stations for the user to select. At step 1510, the TOS type can be determined based on the request. The system can determine the correspondence between the selected collection station and the TOS associated with the collection station. Based on the determined TOS type, A repository instance is constructed for the collection station that requested the material. The construction of the repository instance is discussed in more detail below in Figures 17A-17B. Next, one of steps 1512 and 1514 is performed based on the collection and delivery station that performs the data request. Step 1512 uses the created repository instance to request data to access the data source for the collection terminal A using the distribution station operating system X. Similarly, step 1514 uses the created repository instance to request data to access the data source for the collection and delivery station B of the distribution station operating system Y. At step 1516, the material may be received by the repository instance, whereby the material is subsequently processed to construct the commercial item data. Searched data from the TOS database can be converted to a common data format to provide a common commercial object data format. Commercial object data can be transferred to users who make data requests. At step 1518, the system can display the business item data to the user via a client application, such as a web browser or other user interface. In this manner, the user may be able to retrieve data from any of the collection stations that operate any of the collection station operating systems from the TOS agnostic system.

16 shows an exemplary operational flow diagram of an exemplary TOS agnostic process consistent with one or more aspects of the innovations herein. At step 1602, a request may be received from a user interface, such as a web browser, for a particular collection venue site among a plurality of collection and distribution venues. At step 1604, the TOS type may be determined from the venue information of the terminal. Based on the determined TOS type, a repository instance can be constructed within a TOS agnostic system specific to the TOS type and the terminal location. At step 1606, the TOS agnostic system may request material from the collection site to be stored in the repository instance. The requested data can then be received at step 1608 and processed by the TOS agnostic system. Create a set of commercial objects. The business item can be transmitted to the user interface and displayed at step 1610.

Repository locator

17A shows an exemplary flow diagram of an exemplary TOS agnostic repository locator process consistent with one or more aspects of the innovations herein. At step 1702, the collection site information is retrieved for the requested collection site based on the cache site of the collection site. At step 1704, based on the retrieved venue location, the type of the terminal system corresponding to the venue of the terminal can be determined, and the connection information is retrieved from the site information of the terminal. Next, at step 1706, an attempt is made to obtain a repository instance for specifying the venue of the collection and the corresponding TOS type from the cache list of the repository instance. At decision step 1708, if it is determined that the TOS agnostic system has previously constructed a repository instance for the requested collection and TOS type, then the cache repository instance may be returned at step 1716. However, if it is determined that the repository instance for the specified sink and TOS type does not exist, a new repository instance can be constructed for the specified hub and TOS type. Once created, the repository instance can be cached at step 1714 and returned to the user at step 1716.

17B shows an exemplary sequence diagram relating to an exemplary reservation process and TOS agnostic process consistent with one or more aspects of the innovations herein. The user 1720 operates the client/browser to enter a TOS profile request 1730, which in this case involves an appointment profile request 1730. The user can use various mobile devices to access the browser. The repository factory 1722 can receive this request and can attempt to locate the stored repository 1724 corresponding to the reservation request from among the plurality of repository instances 1726. If a match is found, then at the step At 1734, the corresponding reservation repository is returned to the repository factory 1722, and the requested appointment details 1748 from the located repository 1726A are returned to the browser on the mobile device or desktop 1720 and output to the user.

However, if no repository instance corresponding to the reservation request 1730 is located, the create repository function 1736 can be invoked to generate the reservation repository 1738. Once created, the repository locator 1722 can call the repository 1738 to retrieve the subscription data 1740 function to retrieve the requested subscription data from the data source 1728. The repository 1738 can then call the profile source 1728 to retrieve the subscription profile 1742 function to obtain the requested subscription information. In response, the material source 1728 can return the reservation entity 1744 to the repository 1738 in the form of a data source. Repository 1738 can then process reservation entity 1744 to map/convert/convert the reserved entities into reserved commercial items 1746 in a material source agnostic format.

The appointment item 1746 is then transferred from the repository 1738 to a repository locator 1722, which can process the appointment item 1746 into an appointment detail 1748. The repository locator 1722 can then transmit the subscription details 1748 to the browser 1720 in response to the reservation request 1730. In this system, the browser does not need to be compatible with the data format of the operating system or material source 1728 to request and receive information from the data source 1728 because the reservation entity 1744 is processed into a subscription object 1746 that is agnostic to the data source.

20 is a block diagram depicting an exemplary repository locator hierarchy/structure for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. The website interface 2002 can display the retrieved database data to the requesting user. Service layer 2010 can be processed and stored via repository 2020 Deposit the search data. The cache repository can retrieve data by using the individual data services 2032, 2034 and website services 2036. For example, the material service 2032 interfaces with the TOS1 DB for storage into the repository 2024. The web service 2036 can similarly retrieve the requested material from the website source 2046 for caching in the repository 2028.

TOS agnostic system layer architecture

18A is a block diagram depicting an exemplary layer architecture for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. In this example, user 1800 operates a computing device connected to network 1801 to view presentation layer 1802. The presentation layer 1802 receives material from the service layer 1804, which stores and processes the collection and sink data from multiple TOS types. The service layer 1804 includes a repository 1820 that includes a plurality of repository instances 1822, 1824, 1826, and the like. Repository 1826 is a website service that is provided with information from TOS W. The repository instance can be coupled to a material access layer 1806 that is coupled to a plurality of data sources 1810 that operate under different collection and delivery station operating systems 1808. The data access layer 1806 obtains the requested collection site data from any of the plurality of material sources 1810 via the corresponding database services 1830, 1832. A database service can be provided for each TOS type such that each data source corresponding to TOS X can be accessed by database service 1830. Similarly, each data source corresponding to TOS Y can be accessed by database service 1832. However, data source 1810 and data access layer 1806 are not required for TOS W. TOS W provides the information to Website Service 1826.

In some embodiments, the TOS agnostic system performs repository processing, including instantiating the first repository instance for the first TOS type. E.g, The first repository is requested using the first repository instance and the first repository service to access the data source for the particular venue. The first commercial item can be constructed using the first material, and the first commercial item can be presented to the user as a first TOS agnostic output. The second repository instance can be instantiated for the second TOS type. The second repository is requested using the second repository instance and the second repository service to access the data source for the particular venue. The second business item can be constructed using the second material, and the second business item can be presented to the user as a second TOS agnostic output. The third repository instance can be instantiated as a web service that accesses the third material directly from the third TOS type. The third business item can be constructed using the third material, and the third commercial item can be presented to the user as a third TOS agnostic output.

18B is a block diagram depicting an exemplary layer architecture for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. In this example, user 1800 operates a computing device connected to network 1801 to view presentation layer 1802. The presentation layer 1802 receives data from the service layer 1804B, which stores and processes the collection and sink data from the TOS using the relational database. Service layer 1804B includes a repository 1820B that includes at least one repository instance 1822B. The repository instance can be coupled to a material access layer 1830B that includes a plurality of data sources 1810B operating under the distribution station operating system 1808B. The data access layer 1830B obtains the requested collection site data from any of the plurality of material sources 1810B via the corresponding database service 1832B. A database service 1832B is provided for the TOS 1808B such that each data source 1810B corresponding to the TOS 1808B is accessible by the database service 1832B.

In some embodiments, the TOS agnostic system performs repository processing, including instantiating a repository instance for a TOS type. Repository instances and database service request materials can be used to access multiple data sources for a particular site. The first commercial item can be constructed using the material, and the first commercial item can be presented to the user as a TOS agnostic output.

Figure 18C is a block diagram depicting an exemplary layer architecture for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. In this example, user 1800 operates a computing device connected to network 1801 to view presentation layer 1802. The presentation layer 1802 receives data from the service layer 1804C, which stores and processes the collection of sink data from multiple TOS types using different relational databases. Examples of non-restrictive relational databases include Oracle, MS SQL, MySql, and the like. The service layer 1804C includes a repository 1820C that includes a plurality of repository instances 1822C, 1824C, and the like. The repository instance can be connected via data access layer 1830C to a plurality of individual data sources 1810C, 1811C operating at individual collection and delivery station operating systems 1808C, 1809C. The data access layer 1830C obtains the requested collection site data from any of the plurality of material sources 1810C, 1811C via the corresponding database services 1832C, 1834C. A database service is provided for each TOS type such that each data source corresponding to TOS 1 can be accessed by database service 1832C. Similarly, each data source corresponding to TOS 2 can be accessed by database service 1834C.

In some embodiments, the TOS agnostic system performs repository processing, including instantiating the first repository instance for the first TOS type. For example, using the first repository instance and the first database service request data to access At least one source for a particular site. The first commercial item can be constructed using the first material, and the first commercial item can be presented to the user as a first TOS agnostic output. The second repository instance can be instantiated for the second TOS type. The second repository is requested using the second repository instance and the second repository service to access at least one data source for the particular venue. The second business item can be constructed using the second material, and the second business item can be presented to the user as a second TOS agnostic output.

Figure 18D is a block diagram depicting an exemplary layer architecture for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. In this example, user 1800 operates a computing device connected to network 1801 to view the presentation layer. The presentation layer 1802 receives data from the service layer 1804D, which stores and processes the collection site data from a plurality of TOS types, including TOS 1828D that provides material using the website service 1826D. The service layer 1804D includes a repository 1820D that includes a plurality of repository instances 1822D, 1824D, 1826D, and the like. The repository instance is connected via data access layer 1830D to a plurality of data sources 1810D, 1811D operating under individual collection and delivery station operating systems 1808D, 1809D. Repository instance 1826D is a web service that is provided with information from TOS 1828D. The data access layer 1830D obtains the requested collection site data from any of the plurality of material sources 1810D, 1811D via the corresponding database services 1832D, 1834D. A database service is provided for the TOS types 1808D, 1809D such that each data source corresponding to the TOS 1808D is accessible by the database service 1832D. Similarly, each data source corresponding to TOS 1809D can be accessed by database service 1834D.

In some embodiments, the TOS agnostic system is located at the repository The method includes instantiating the first repository instance for the first TOS type. For example, the first repository instance and the first repository service request material are used to access at least one data source for a particular venue. The first commercial item can be constructed using the first material, and the first commercial item can be presented to the user as a first TOS agnostic output. The second repository instance can be instantiated for the second TOS type. The second repository is requested using the second repository instance and the second repository service to access at least one data source for the particular venue. The second business item can be constructed using the second material, and the second business item can be presented to the user as a second TOS agnostic output. The third repository instance can be instantiated as a web service that accesses the third material directly from the third TOS type. The third business item can be constructed using the third material, and the third commercial item can be presented to the user as a third TOS agnostic output.

19 is a block diagram depicting an exemplary layer architecture and associated processing module for an exemplary TOS agnostic system consistent with one or more aspects of the innovations herein. In Figure 19, each user 1902, 1904, and 1906 enters a request to the presentation layer 1802 to access data from different collection centers using different collection and delivery station operating systems. For the sake of brevity, the description of the elements that have been described is omitted.

The PA.Tos. smart website at step 1910. The website UI represents a server component that can be built based on the MS ASP.NET MVC framework. This component can be designed based on the Model-View-Controller (MVC) design pattern and can be responsible for receiving and processing user requests and constructing responses and sending responses to the user. Next, the PA.Tos.Smart Website. Service 1912 can receive the service group requested by the user from the controller in the PA.Tos.Smart Website.Web UI component. Pieces. The service component can call methods in the repository to process user requests. The service component retrieves the data from the repository, sends the data to the repository to update the data source, processes the business logic, and constructs the response and sends the response to the controller in the UI component of the PA.Tos.Smart Website. The PA.Tos.Smart Website.Repository 1914 may be a server component that implements a repository locator that instantiates a repository instance for the collection and TOS type depending on the user request.

PA.Tos. Smart Website. Repository. Library 2 1924 can be a repository instance for a specific repository of TOS. The repository instance knows the type of repository, how it communicates with the repository, and where the repository is located. A repository instance can construct a business entity from a TOS-type-specific material or convert any information in a business entity to a material used in a TOS-specific database.

PA.Tos. Smart Website. Repository. Website Service 1926 can be a repository instance for retrieving data or sending data to a TOS source using a web service. Repository instances can know the type of website service, service contract, data contract, job contract, how to communicate, where to access the service, and so on. A repository instance can construct a business entity from a TOS-type-specific material or convert any information in a business entity to a material used in a TOS-specific data source.

TOS agnostic processing

21 shows an exemplary sequence diagram relating to an exemplary search reservation process and TOS agnostic process consistent with one or more aspects of the innovations herein. Referring to FIG. 21, an exemplary process may be based on a website by a user. The basic user interface starts at the step of logging into the collection station A and inputting a reservation information request for the container of the collection station A. For example, the user can request information for the container number CNTR123456. Next, the TOS Agnostic Service receives and processes the user request for the booking information for the container. The GetApptInfo method in the service call reservation service. The appointment service implements methods related to the appointment of a business process. The GetApptInfo method is handled by the reservation repository. The reservation service first requests an appointment repository instance from the repository factory using the GetApptRepository method. The repository factory is the repository locator that returns the repository instance for the collection station A. The repository factory requests the reservation repository for the collection station A using the GetInstance method. The reservation repository retrieves and stores the reservation information from the reservation database for the collection station A.

Next, the GetAppointment method is defined in the subscription service to call the GetAppointment method of the reservation repository to request the reservation information corresponding to the container number CNTR123456 of the distribution station A. The GetAppointment method accesses the reservation database and obtains the requested reservation information as a reservation entity. The reservation entity is then stored as an appointment item in the reservation repository. For example, a reservation entity retrieved from the reservation database as the original material is converted/converted into an appointment commercial item. The appointment item 2136 is then returned to the appointment service.

In addition, GetContainer is an internal method call to retrieve container information related to the requested appointment. Similar to the GetApptRepository method, the reservation service executes the GetTosLookUpRepository method to the repository factory to obtain container information corresponding to the reservation information requested by the user. The GetInstance method requests the TosLookUp repository for the distribution station A. Example. The GetContainer method implemented by the reservation service requests the repository to retrieve container information related to the reservation information from Tos. The tos lookup repository uses the GetContainer method to retrieve information about the container corresponding to the container number from the collection station A database. In response, the collection station A database transmits the requested data as a container entity. The reservation entity and container system are provided in the format of the distribution station A operating system, which is incompatible with the format of other distribution station operating systems. Therefore, the tos lookup repository converts/converts the original container data of the distribution station A into container objects that will be added to the container repository. Once the appointment item and the corresponding container item are returned to the appointment service, the collection of the reservation item and the container item is returned to the TOS unknowable service. The TOS agnostic service processes the commercial item data and displays the appointment item and the container item to the user via a web-based user interface including the mobile device and the personal computer, as shown in more detail in connection with Figures 46A-46S.

Incorporated TOS unknown code

For some of the functions and functionality of this document, the TOS Agnostic Computer Code in the CD-ROM submitted in Application No. 13/987,447, filed on July 24, 2013, with respect to the sub-subordinate TOS agnostic function defined therein This is incorporated herein by reference in its entirety as needed.

Additional service layer

In addition to the basic architectural functions set forth above, the service layer can serve as a baseline for the integration of/integration of various exemplary components between the various exemplary components, such exemplary components can be associated with the TOS interface/distribution herein. Station operating systems (eg, other web applications and distribution system operating systems such as M21) are associated with various implementations of this document. Interface/distribution station operating system communication. Here, for example, the present disclosure and the appendices herein show how various functionalities and information can be communicated and processed between a web application and a TOS (eg, M21) via or through a service layer. For example, the computer code associated with M21 that assists in exemplifying such functions is included in the "TOS Data Access Library" of the attached CD.

With regard to the Equipment Exchange Reporting (EIR) function, generating EIR can be a process of data and business logic intensive. A large amount of data is collected from one or more TOS databases and archived databases such as the M21 database. The data is manipulated in a variety of processes and applied business logic to be presented in a printed format. In addition, the gate activity module in the differential system or web application can perform such processes and maintain the processes separately. In some implementations, the ReportService functionality can be utilized to provide all the material for the EIR to be used for presentation, but to hide the details of the business logic and data access process. This situation improves the maintainability and extensibility of the application.

Here, it is specifically reiterated that the above and below functions should also be understood in conjunction with the associated computer code appendix and Appendices 1 through 4 submitted with this document. Some of the functions and functionality shown and described at a level of detail herein are provided in more detail via such appendices. In addition, many of the systems and processes described above, as well as other functions and functions, can be used with various user interfaces, supported by various user interfaces, and/or interacted with various user interfaces. In one aspect, the systems and methods provided herein include multiple interfaces accessible, for example, via an internet connection and/or other network connection. In some embodiments, the interface combines the functionality of the summary report with the status update, which allows the user to access, check, and update each during the shipping process. The state of the components.

Any information that can be checked and updated includes, but is not limited to, information relating to: appointments (see, for example, Figure 25A); online payments (see, for example, Figures 27A-27B); announcements (see, for example, 29A to 29C); administration (see, for example, FIG. 31, FIG. 32A to FIG. 32B); report (see, for example, FIGS. 35A to 35C); tools (see, for example, FIG. 36, FIG. 34A to FIG. 34B) );and others.

It should be noted that any reference to a menu or drop down menu may include any number of data entry fields and is not limited to drop down menus. A free text box can be used, which can be selected using the Auto Fill Text Input Box radio button or any number of menu selection options. The various specific illustrations herein are for exemplary purposes only.

The system and method herein also allows for various interfacing with other applications such as VRU/IVR (Voice Response Unit/Conversational Voice Response) and Voyager Tracking System. However, any network-based device can be used to access the system.

22A is a block diagram illustrating an exemplary environment 2200, network 2200, and other aspects consistent with one or more aspects of the innovations herein, the exemplary environment including a reservation system 2204, which in some implementations Can be unknown to the TOS. Each particular TOS may have its own reservation system, and the different reservation systems TOS may not be compatible with each other or with other TOS database schemas. The reservation system 2204 of Figure 22 can be built on top of the TOS agnostic architecture such that the reservation system can interact with various TOSs such as TOS 1 2224 and TOS 2 2228. Reservation system 2204 allows users (eg, trucking companies, etc.) make, observe, edit, search, and/or cancel appointments in multiple TOS environments via one access point.

Reservation system 2204 can include and/or be related to one or more computers and can have its own subscription database 2208. The reservation system 2204 can maintain the reservation data in the reservation database 2208. The reservation system 2204 can also communicate with one or more TOS data repositories. In the example of FIG. 22, reservation system 2204 is coupled to TOS 1 data repository 2212 and TOS 2 data repository 2216. Each of these repositories 2212, 2216 can be an internal repository for its individual TOS 2224, 2228. . The reservation system 2204 can access the repositories 2212, 2216 to retrieve the data (eg, to evaluate the status in making the appointment), but can store the reservation data in the own database 2208 of the reservation system rather than in the reservation system. Repositories 2212, 2216.

Reservation system 2204 may enable a user to use one reservation system 2204 for different collection centers using different TOSs 2224, 2228 in the same geographic area. Additionally, the user can view and manage multiple collection and distribution stations in one reservation system 2204. For example, FIG. 22 shows a TOS 1 user 2220A (eg, a user of a TOS 1 collection and distribution station) and a TOS 2 user 2220B (eg, a user of a TOS 2 collection and distribution station) making reservations using the reservation system 2204. Any user can make, observe, change, delete, search, etc. reservations for TOS 1 or for TOS 2, regardless of which TOS is used by the collections of such users. Thus, picking or delivery by the TOS 1 user 2232A or TOS 2 user 2232B may have been scheduled by the TOS 1 user 2220A or TOS 2 user 2220B via the reservation system 2204 without having to access a particular TOS 2224, 2228. .

22A is a block diagram illustrating an exemplary environment 2200, network 2200, and other aspects consistent with one or more aspects of the innovations herein, the exemplary environment including a reservation system 2204, which in some implementations Can be unknown to the TOS. Each particular TOS may have its own reservation system, and the different reservation systems TOS may not be compatible with each other or with other TOS database schemas. The reservation system 2204 of Figure 22A can be built on top of the TOS agnostic architecture such that the reservation system can interact with various TOSs such as TOS 1 2224 and TOS 2 2228. The reservation system 2204 may allow a user (eg, a trucking company, etc.) to make, view, edit, search, and/or cancel an appointment in multiple TOS environments via one access point. The TOS users 2220A and 2220B access the system via the reservation system 2204 to make a reservation. The reservation system 2204 can include an appointment database 2208 and TOS data repositories 2212, 2216. TOS users 2232A and 2232B can interact with TOS 2224, 2228 for container picking and delivery.

Figure 22B is a block diagram illustrating a conventional reservation system. The reservation system in Figure 22B is tightly constrained to the TOS. When the user 2220A, 2220B (e.g., a trucking company) makes a reservation, the user accesses the reservation system 2296, 2298 working with the particular TOS 2297, 2299. In addition, conventional reservation systems 2296, 2298 share a database used by the TOS. A reservation system that works with one TOS cannot be used by another TOS using a different database schema.

Figure 22C is a block diagram illustrating another conventional reservation system. In order to pick up or deliver the container, the user 2232A, 2221B (eg, truck driver) should access the database-specific TOS and retrieved by the reservation system 2296, 2298 Built information.

22D is a block diagram illustrating an exemplary environment that includes a reservation system 2240 that is built on top of the TOS agnostic architecture in some implementations and that uses the subscription database 2242 to save subscription data. The reservation system 2240 only accesses the TOS database 2244, 2246 to retrieve the data (in the absence of an update to the TOS database) to evaluate the status to make a reservation.

22E is a block diagram illustrating an exemplary environment, including reservation system 2240, in accordance with some implementations. To pick up or deliver the container, the users 2220A, 2220B access the TOS 2250, 2252 that are connected to the reservation system 2240 and are in communication with each other. The reservation system 2240 functions as a centralized hub for the TOS 2250, 2252, TOS DB 2244, 2246, and reservation DB 2242, and controls and completes the gate process. According to some embodiments, users 2220A, 2220B (eg, truck shipping companies) use one reservation system 2240 for, for example, two different collection and distribution stations 2250, 2252 that use different TOSs in the same geographic area. In addition, the user can observe and manage multiple collection and distribution stations in the system.

23A is a chart illustrating an exemplary appointment process consistent with one or more aspects of the innovations herein. The user 2232A of the user 2232A of the TOS 1 collection terminal (distribution station 1) and/or the TOS 2 collection terminal (distribution station 2) 2232B can start this process by requesting a reservation. The reservation system 2204 can receive a container information request to make a reservation 2304 at the collection station 1 using TOS 1 or at the collection station 2 using TOS 2. The reservation system 2204 can retrieve the TOS type (ie, TOS 1 or TOS 2) from the collection station information and is directed to the collection and delivery station and the TOS type. Repository instance 2308 is constructed. Depending on the TOS type, the reservation system 2204 can use the repository instance to request container data to access the data source 2312 for the hub 1/TOS 1, or use the repository instance to request container data for access to the hub 2/TOS 2 data source 2316. Once the data has been accessed, the reservation system 2204 can receive the data, construct the container item for the reservation, and transfer the data 2320. The reservation system 2204 can also request the existing reservation data 2324 from the reservation database 2208 for the container. The reservation system 2204 can cause the container information to be displayed on the client (e.g., the collection terminal 1 or the collection terminal 2) application 2328, such as a web browser.

Notification agent

The notification agent can be an application for evaluating notification requests and performing other background processing tasks. The notification agent can operate in the context of other processes described herein and can evaluate the following notification requests based on the scheduled work, such as: availability request, retention status request, entry gate request, exit gate request, subscription valid request, container Prepare an appointment request, a delay fee notification request, or a combination of the above.

After evaluating the request for each request that is satisfied by observing the various database tables, the notification agent can set a request status value that can be used to send the notification to the user. The customer service manager in the notification agent can group all the announcements of a single user together and send the announcement by, for example, an email, fax or text message.

23B is an exemplary block diagram of the functionality of a request evaluator and an announcer transmitter consistent with one or more aspects of the innovations herein. The request evaluator 2330 transmits the data to the notification transmitter 2340. Request evaluator 2330 may include functionality including availability 2131, retention status 2332, delay fee 2333, entry gate 2334, exit gate 2335, subscription 2336, TMF release 2337, and TMF release reversal 2338. The notification sender 2340 can include functionality including container notification 2342 and TMF request notification 2344.

Container request notice:

As shown in Figure 23C, the following can be used to notify the various sub-modules in the container notification instance. The request evaluator 2330 may include an availability request evaluator 2331 (checking the container that becomes available), retaining the status request evaluator 2332 (checking the container that will retain the status quo), entering the gate 2334 (checking the container entering the gate), exiting the gate 2335 (Check the container exiting the gate), delay 2333 (check the container that will be given the delay alarm condition), TMF release 2337 (check the container released by TMF), TMF release reverse 2338 (check the TMF release counter of the container) Transfer (return to TMF retention status) and/or subscription 2336 (check to become effective subscription). Announcement sender 2340 may include container notification sender 2342 (send notification request email/fax to user) and / Or TMF request notification sender 2344 (send TMF-related notification request email/fax to the user).

The request evaluator 2330 can check the status of the container based on the notification request stored in the database. If the current condition of the container matches the request status, the request will have been deemed satisfied or completed. For example, for availability conditions, the request can be satisfied when the container becomes available. If the current situation makes it impossible to achieve the requested condition, the request may become invalid. In the availability state, for example, if the container is found to be inland before it is detected as available, the corresponding request becomes invalid. After the assessment, the shape can be changed State update request. If there are any errors during the evaluation of the request, the request may be flagged as such and re-evaluated during the next cycle.

A TMF release request may be implicitly created when a user registration page for an availability request or, in particular, "registration all" or in a "customized request" is entered into the UI. The TMF release evaluator can check the release status in the TOS table and update the request when it is satisfied. For example, the TMF state can become a release state or return to the TMF hold state.

The evaluator inherits from the base class, which can contain processing logic common to all evaluators. This shared logic can call methods in subclasses of a particular logic.

The Container Announcement Transmitter can group all of the user's announcements into a single email, fax or text message and send a message. If any error occurs during the transmission of the message, you can try to send the message in the next cycle. The request can be marked as sent after a successful transmission.

The TMF announcement sender can combine the TMF release and reverse email in a single message and send the message.

The timer interval evaluation period and some settings can be read from the configuration file.

Suspension notice (fault transaction)

23D is an exemplary block diagram of a pause notification functionality consistent with one or more aspects of the innovations herein. The suspension announcement 2350 can include a failed transaction evaluator/transmitter 2352.

FIG. 23D shows an exemplary suspension notification module 2350. A suspension notice can be a notification that the user has not explicitly requested the request. Can be entered in user preferences The line is set and the system can determine if a condition related to the setting has occurred. For example, a faulty transaction setting can be presented. The user can request an announcement whenever the gate transaction enters a fault or leaves the fault. All such notifications by the user may be grouped together and sent by the failed transaction evaluator/transmitter module 2352 once the condition is detected. Users and transactions can be connected by the user's truck driver. When a transaction enters (or leaves) a failure, if all users of the truck driver in the associated list of users have registered, an announcement can be sent for all of the users.

The timer interval evaluation period can be read from the configuration file. The settings can be stored in the USER_SITE_CONFIG table as part of the UserPreferences stored in the ADMIN repository.

The fault notification sends the details of the fault message to all users who have registered for the fault notification. The announcement can be sent based on the truck driver's associated user associated with the failed transaction. Container advertisements may be sent on a per request basis upon request by the user, however such container advertisements may be grouped at the time of transmission.

Appointment notice

23E is an exemplary block diagram of subscription announcement functionality consistent with one or more aspects of the innovations herein. The appointment notice 2360 can include a reservation logout evaluator/transmitter 2362, an SSCO authorization request sender 2364, a container ready appointment evaluator/transmitter 2366, and a truck driver authorization alert sender 2368.

FIG. 23E shows an exemplary appointment notification module 2360. Following an exemplary notice may be related to an appointment.

Container ready for booking notice 2366 - per request (CUSTOMER_REQUEST)

This notification can be sent by the container ready appointment evaluator/transmitter module 2366 when the container becomes ready to make an appointment. Due to various reasons related to importing containers, the container may not be ready to make an appointment. In this case, the user can request that the notification be sent when the container becomes ready. All of the user's announcements can be grouped together in a single message. This notice may only be applicable to import appointments in some embodiments.

Appointment Cancellation Notice 2362 - Preset (not configurable)

This announcement can be sent by the appointment cancellation evaluator/transmitter module 2362 when the appointment is cancelled due to the restriction being cancelled or modified in the set limits. In the setting restriction, if the reservation manager deletes the slot in which the reservation has been made, the reservations may be marked as cancelled. This evaluator can check all such appointments and send a message to the user whose appointment was cancelled. All of the user's announcements can be grouped together in a single email. All types of appointments can be cancelled.

SSCO Authorization Request Notice 2364 - Preset (not configurable)

When a user makes an empty appointment for a container with a status of "required authorization", the status of the appointment will be "pending". In this case, the message can be sent by the SCCO Authorization Request Transmitter Module 2364 to the SSCO requesting the return of the authorized container. SSCO can authorize the return of the container by performing an operation to update the TOS form xxxxx. In some embodiments, this message can only be sent if the SSCO has allowed the sending of an email for this purpose.

Truck Driver Authorized Alert Notice 2368 - Preset (not configurable)

This notification may be sent by the truck driver authorized alert sender module 2368 to the user making the appointment. This notification may be generated and sent when it is detected that the SSCO has not authorized the return of the empty container and the appointment is less than 2 hours apart. The timer interval evaluation period and some settings can be read from the configuration file. Some other settings related to these announcements are stored in the database.

Batch process

23E is an exemplary block diagram of batch process functionality consistent with one or more aspects of the innovations herein. The batch process 2370 can include an import reservation status updater 2371, an exit reservation status updater 2373, an empty entry reservation status updater 2375, a container snapshot creator 2377, and a hidden container checker 2379.

As shown in FIG. 23E, the batch process module 2370 can include various modules that are assembled to handle various processes. The reservation status updater-import module 2371 can update the status of the activity/pending/startup appointment to activity or pending, complete/suspend, miss or early pick as needed. The Appointment Status Updater-Exit Module 2373 can update the status of non-import/non-empty, active/startup appointments to completion/suspend or miss as needed. The reservation status updater-empty entry module 2375 can update the status of the activity/pending/initiate empty appointment as needed to active or pending, early missed or completed/suspended, or cancelled or missed as needed.

When the transaction starts, the TOS can set the reservation status to start for all reservation types. The above updater module can ignore all "fake" appointments, which are reservations created by the TOS. These updater modules can process appointments created from the website/VRU. The CREATED_FROM field can be used for this purpose.

The Container Snapshot Creator Module 2377 can create container statistics relating to users who have occupied or have reserved appointments, and the like. These statistics can be displayed in the Set Limit Screen and Limit Report. The data can be updated in the APPT_LIMITS form.

The hidden container verifier module 2379 can unhide the empty inbound containers, which have a valid double appointment. The user can hide the container in the empty return checker page. Only containers that do not have any reservations can be hidden. An vacant appointment can have a dual import appointment. This double appointment can be made in the import booking module. This process can check all hidden containers for any import appointments, and if any hidden containers are found to have an import reservation, the hidden containers can be marked as "unhidden". When the user makes an inquiry to return to the container, these containers can be displayed on the empty entry page.

The timer interval evaluation period and some settings can be read from the configuration file. Various other settings related to these announcements can be stored in the SITE_CONFIG form.

24A-1 and 24A-2 are block diagrams illustrating a truck company profile system or process consistent with one or more aspects of the innovations herein. Figure 24A-1 illustrates one implementation of truck line management, including company profiles, RFID, and UTN. 24A-1 illustrates a truck company profile in which a plurality of users can access the reservation system 2410A and the reservation database 2420A. Users 2402A, 2404A, 2406A may be collection terminal managers or truck line managers and allow each of the different users to access reservation system 2410A to create/observe/modify/update truck company profiles.

In accordance with the embodiments herein, a truck company profile is provided for a truck line company authorized to receive and deliver equipment to a collection station. Each truck line company can include multiple trucks.

According to some implementations, in order to enter the NOLA distribution station, each truck is required to have an RFID tag. This RFID tag is required to support call forwarding and gate processes. Register RFID tags with the management of the car company and these tags. The distribution station manager can create RFID tags in batches and assign batches of predetermined numbers to different truck shipping companies. Truck company managers can manage RFID and assign these RFIDs to individual trucks. Maintenance of the RFID tag is performed by the RFID registration page.

According to some implementations, the truck company has defined a defined list of trucks authorized to receive and deliver equipment to the collection station. Each truck has a unique truck number called UTN. Each truck line has assigned a UTN range to the truck line. The truck company manager or the distribution station manager can then assign the RFID to the UTN. The assignment of RFID and UTN is carried out via a truck maintenance screen.

For example, in Figure 24A-2, each of the different users 2401A, 2403A, 2405A accesses the reservation system 2411A via an interface 2407A, such as a web browser interface. The reservation system 2411A accesses and retrieves data from the reservation database 2421A. For example, user 2403A requests to create/update/modify/observe company information via interface 2407A. The request and any associated inputs are transmitted to reservation system 2411A, which requests the data and/or provides the input to reservation database 2421A. The request is subsequently processed and the reservation database returns the appropriate data to the reservation system 2411A. Reservation system 2411A subsequently lost A success/failure signal and any appropriate information are displayed to be displayed on interface 2407A. Interface 2407A displays success/failure confirmation and truck company information.

24B-1 is a block diagram depicting one exemplary layer architecture of an exemplary TOS agnostic system for making a reservation consistent with one or more aspects of the innovations herein. The computing device is operated by a sink station A user 2402B using TOS1, a sink station B user 2404B using TOS2, and a sink station user 2406B using TOS3, the computing device being connected to the website user interface portal 2412B Expression layer 2410B. The presentation layer 2410B receives material from the service layer 2420B that stores and processes a plurality of TOS type of collection and sink data from the TOS 2442B, 2444B, 2446B, and/or the reservation repository 2440B. The service layer 2420B includes a reservation repository 2426B that includes a plurality of repository instances 2428B. The repository instance can be connected to the Appointment Repository Service 2432B and/or the Repository Service 2434B. Repository instances can also serve the website. The service layer further includes a TOS website portal service 2422B and a TOS website portal repository 2424B. The repository instance can be coupled to a material access layer 2430B that includes a plurality of database services 2434B that operate at the individual collection and delivery station operating systems 2442B, 2444B via the material access layer 2430B. A repository instance for the website service is available from TOS 2446B. The data access layer 2430D obtains the requested collection site data from any of the reservation database 2440B and the TOS via the corresponding database services 2432B, 2434B. The reservation repository 2426B can also retrieve data directly from, for example, TOS 2446B.

In some embodiments, the TOS agnostic system performs repository processing, including instantiating the first repository instance for the first TOS type. use The first repository instance and the first repository service request the first profile to access at least one data source for the particular venue. The first commercial item can be constructed using the first material, and the first commercial item can be presented to the user as a first TOS agnostic output. The second repository instance can be instantiated for the second TOS type. The second repository is requested using the second repository instance and the second repository service to access at least one data source for the particular venue. The second business item can be constructed using the second material, and the second business item can be presented to the user as a second TOS agnostic output. The third repository instance can be instantiated as a web service that accesses the third material directly from the third TOS type. The third business item can be constructed using the third material, and the third commercial item can be presented to the user as a third TOS agnostic output. Commercial items may include reservations in a collection station that uses different TOS.

24B-2 is a block diagram depicting an exemplary layer architecture of an exemplary TOS agnostic system for import reporting consistent with one or more aspects of the innovations herein. The computing device is operated by a sink station A user 2401B using TOS1, a sink station B user 2403B using TOS2, and a sink station user 2405B using TOS3, the computing device being connected to the website user interface inlet 2413B Expression layer 2411B. The presentation layer 2411B receives material from the service layer 2421B, which stores and processes a plurality of TOS type of sink data from TOS 2441B, 2443B, 2445B. The service layer 2421B includes a reservation repository 2426B that includes a plurality of repository instances 2428B. The repository instance can be connected to the repository service 2433B. Repository instances can also serve the website. The service layer further includes a TOS website portal service 2445B and a TOS website portal repository 2424B. Storage The repository instance can be coupled to a material access layer 2431B that includes a plurality of database services 2433B that operate at the individual collection and delivery station operating systems 2441B, 2443B via the material access layer 2431B. A repository instance for the website service is available from TOS 2445B. The data access layer 2431D obtains the requested collection site data from any of the database services 2433B and the TOS. For example, a user may request an import report from multiple collection stations using different TOSs using the system of Figure 24B-2.

In some embodiments, the TOS agnostic system performs repository processing, including instantiating the first repository instance for the first TOS type. The first data is requested using the first repository instance and the first database service to access at least one data source for a particular venue. The first commercial item can be constructed using the first material, and the first commercial item can be presented to the user as a first TOS agnostic output. The second repository instance can be instantiated for the second TOS type. The second repository is requested using the second repository instance and the second repository service to access at least one data source for the particular venue. The second business item can be constructed using the second material, and the second business item can be presented to the user as a second TOS agnostic output. The third repository instance can be instantiated as a web service that accesses the third material directly from the third TOS type. The third business item can be constructed using the third material, and the third commercial item can be presented to the user as a third TOS agnostic output. Commercial objects may include import reports in multiple terminals that use different TOS.

Figures 24C-1, 24C-2, and 24C-3 present exemplary embodiments of systems and methods described herein in connection with truck line company management. For example, a truck line company can use an authorized to receive and deliver containers to a set A team of trucks in the station. Each truck may have an RFID tag that may allow for example tracking of the truck and interaction between the truck and the docking station. The truck company may have a defined list of trucks authorized to receive and deliver the equipment to the collection station. Each truck can have a unique truck number called UTN. Each truck line can be assigned a UTN range.

Figure 24C-1 is a TOS agnostic reservation method consistent with one or more aspects of the innovations herein. This method of appointment can be used, for example, to manage trucks equipped with RFID tags in a fleet of trucks, or to manage other groupings of vehicles. The appointment method of Figure 24C-1 can be used to generate an appointment, for example, for a truck picking up a container. Thus, the exemplary process in Figure 24C-1 is illustrated as being based on a container to be picked up, although in other implementations, reservations may be made based on other circumstances. The Inspect Container command can be entered into the TOS Service 2481A, which specifies the container for which the appointment will be made. As discussed throughout, this TOS service can serve any TOS due to the TOS agnostic nature of the method. The TOS service can request container and/or reservation information 2481B from the reservation service. The reservation service can request reservation information 2481C from the reservation repository. The reservation repository may retrieve subscription information 2481D from the subscription source, which may send the available reservation slot to the reservation repository 2481E. The available reservation slots in the repository can be reported to the reservation service 2481F. The reservation service can also request the container information 2481G about the container from the TOS lookup repository. The TOS lookup repository can retrieve container information 2481H from the TOS data source, which can send container information to the TOS lookup repository 2481J. Container information can be reported to the booking service 2481K. The booking service can request the verification of the container by the reservation utility 2481L, and the reservation utility can verify the container in the return. 2481M. The booking service can send container information, booking information and verification to the TOS Service 2481N. The user may be able to view this information and make an appointment 2481P. The reservation service 2481Q, the reservation repository 2481R, and the reservation material source 2481S can be used to save the reservation. The save can be reported by the reservation data source 2481T, the reservation repository 2481U, and the reservation service 2481V.

For example, a method of processing information relating to a collection station operating system can include some or all of the following actions. Information may be provided for displaying an interface to a user, the interface comprising a reservation system operating system reservation function and an input field for receiving user input, the information including the first information including the container information and the information including the reservation information Second information. Information related to user input received via the interface can be processed to manage the distribution system operating system reservation functionality. Processing may be performed to generate an output/result to transmit an instruction within the system, to transmit the instruction to a third party, or a combination of the two; to perform a docking station operating system reservation functionality in the system such that the managed collection station operation is generated The output of the result of the system reservation functionality; or a combination of the two. The user input can include a command to create a truck container appointment, modify a truck container appointment, search for a truck container appointment, delete a truck container appointment, observe a truck container appointment, or a combination of the above. Truck container reservations may include an import reservation, an export reservation reservation, an empty container reservation, or a combination of the above appointments. Outputs may include established truck container reservations, modified truck container reservations, search results including truck container reservations, removal of truck container reservations, display of truck container reservations, or a combination of the above. Truck container reservations may include an import reservation, an export reservation reservation, an empty container reservation, or a combination of the above appointments. Process to produce an output/junction The result may include retrieving container information, appointment information or a combination of the above information from a repository, a data source or a combination of the repository and the source. Processing to produce an output/result can include verifying the container. Processing to produce an output/result can include saving the information related to the appointment in a repository, a data source, or a combination of the repository and the source. The output may include container information, appointment information, verification information, save confirmation, or a combination of the above.

Figure 24C-2 is a TOS agnostic reporting method consistent with one or more aspects of the innovations herein. This reporting method can be used, for example, to manage trucks equipped with RFID tags in a fleet of trucks, or to manage other groupings of vehicles. The reporting method of Figure 24C-2 can be used, for example, to find an import report for a container and/or an appointment for a container that is scheduled to be picked up by a truck, although other reports may be possible. The Get Container command can be entered into the TOS Service 2843A, which can specify the container of the required information. As discussed throughout, this TOS service can serve any TOS due to the TOS agnostic nature of the method. The TOS service can request container information 2843B from the reporting service. The reporting service can request container information 2843C from the reporting repository. The report repository can retrieve container information 2843D from the TOS data source, which can send container information to the report repository 2843E. The report repository sends container information to the Reporting Service 2843F. The reporting service can also request 2423G reservation information related to the container from the reservation repository. The reservation repository can retrieve the reservation information 2843H from the reservation source, which can send the reservation information to the reservation repository 2843J. The reservation repository can send appointment information to the Reporting Service 2843H. The reporting service guides the reservation utility calculations for the availability of the report 2843L. Availability can be returned to 2843M, and the reporting service can include containers, reservations and/or The report of the usability information is sent to the TOS service 2843N.

For example, a method of processing information relating to a collection station operating system can include some or all of the following actions. Information may be provided for displaying an interface to a user, the interface including a distribution system operating system reservation functionality and an input field for receiving user input, the information including first information including container information. Information related to user input received via the interface can be processed to manage the distribution system operating system reservation functionality. Processing may be performed to generate an output/result to transmit an instruction within the system, to transmit the instruction to a third party, or a combination of the two; to perform a docking station operating system reservation functionality in the system such that the managed collection station operation is generated The output of the result of the system reservation functionality; or a combination of the two. The user input may include a command to create a truck container import report, modify a truck container import report, search for a truck container import report, delete a truck container import report, observe a truck container import report, or a combination of the above. The Truck Container Import Report may contain container information, booking information, availability information or a combination of the above. Outputs may include established truck container import reports, revised truck container import reports, search results including truck container import reports, removal of truck container import reports, display of truck container import reports, or a combination of the above. Processing to produce an output/result can include retrieving container information, appointment information, or a combination of the above information from a repository, a data source, or a combination of the repository and the data source. Processing to produce an output/result can include computational availability. The output can include container information, appointment information, availability information, or a combination of the above. 24C-3 is a TOS agnostic notification method consistent with one or more aspects of the innovations herein. notice The method can provide the notification to the user via email, fax, SMS or other reporting technology. For example, an appointment profile, an import report, etc. can be delivered to the user via an announcement. The announcement may be similar to the announcements discussed in other embodiments herein. The notification service can retrieve the consumer request 2485A from the notification repository. The notification repository may retrieve the consumer request 2485B from the notification database, which may send the consumer request to the notification repository 2485C. The notification repository can send a consumer request to the notification service 2485D. Consumer requests may include information such as contract information for the consumer and/or triggers for sending announcements (eg, when making an appointment or when approaching an appointment, etc.). Based on the information in the consumer request, the notification service can identify the container for which the notification is directed. The notification service can retrieve container information 2485E from the notification repository. The notification repository can retrieve container information 2485f from the TOS source, which can send container information to the notification repository 2485G. The notification repository can send container information to the notification service 2485H. The notification service can direct the utility to evaluate consumer requests and container information to determine if the notification is guaranteed 2485J, and the utility can make a determination and report the determination to the notification service 2485K. For example, if the consumer requests to specify that the announcement will be sent when the reservation for the container is scheduled, and the container information indicates that the appointment is scheduled, it may be determined that the evaluation of the notification should be sent. Accordingly, the notification service may send an announcement 2485L and update the information in the notification repository 2485M and/or the notification repository 2485N to indicate that the announcement was sent.

For example, a method of processing information relating to a collection station operating system can include some or all of the following actions. Information can be provided for displaying the interface to the user, the interface including the functionality of the distribution system operating system notification and To receive an input field entered by the user, the information includes first information including notification information relating to the truck container. Information related to user input received via the interface can be processed to manage the functionality of the distribution system operating system announcement. Processing may be performed to produce an output/result to transmit an instruction within the system, to transmit the instruction to a third party, or a combination of the two; to perform a hub system notification functionality in the system such that the managed collection station operation is generated The system notifies the output of the functional result; or a combination of the two.

User input may include a command to register import availability/hold status, modify import availability/hold status, search for import availability/hold status, delete import availability/hold status, observe import availability/hold status, or each of the above The combination. The output may include registered import availability/hold status, modified import availability/hold status, search results including import availability/hold status, deletion of import availability/hold status, display of import availability/hold status, or each of the above combination.

The user input may include a command for registering a traffic levy release/release reversal notice, modifying a traffic voyage fee release/release reversal notice, searching for a traffic levy release/release reversal notice, and deleting a traffic voyage fee release/ Release the reversal notice, observe the traffic levy release/release reversal notice, or a combination of the above. The output may include the registered traffic levy release/release reversal notice, the modified traffic levy release/release reversal notice, the search result including the traffic levy release/release reversal notice, and the traffic levy release/release reversal notice. The deletion, the display of the traffic release fee release/release reversal notice, or a combination of the above.

The user input may include a command to register a delay fee notice, modify a delay fee notice, search for a delay fee notice, delete a delay fee notice, observe a delay fee notice, or a combination of the above. The output may include a registered delay fee notice, a modified delay fee notice, a search result including a delay fee notice, a deletion of a delay fee notice, a display of a delay fee notice, or a combination of the above.

The user input may include a command for registering a valid notice, modifying a valid notice, placing a valid notice, deleting a valid notice, observing a valid notice, or a combination of the above. The output may include a registered effective notice, a revised effective notice, a search result including a valid notice, a deletion of a valid notice, a display of a valid notice, or a combination of the above.

The user input may include a command to register the exit gate notification, modify the exit gate notification, search for the exit gate notification, delete the exit gate notification, observe the exit gate notification, or a combination of the above. The output may include a registered exit gate notice, a modified exit gate notice, a search result including an exit gate notice, an exit gate notice deletion, an exit gate notice display, or a combination of the above.

The user input may include a command to register an entry gate notification, modify an entry gate notice, search for an entry gate notice, delete an entry gate notice, observe an entry gate notice, or a combination of the above. The output may include a registered entry gate notification, a modified entry gate notification, a search result including an entry gate notification, a deletion into the gate notification, a display of the entry gate notification, or a combination of the above.

The user input may include a command to register a suspension notice, modify a suspension notice, search for a suspension notice, delete a suspension notice, observe a suspension notice, or a combination of the above. The output may include a registered pause notice, a modified pause notice, a search result including a pause notice, a pause notice deletion, a pause notice display, or a combination of the above.

24D-1 is an exemplary flow diagram of an exemplary workflow process consistent with one or more aspects of the innovations herein. The basic operation begins with receiving a request 2402D from a web browser for a particular venue. The TOS type is retrieved from the venue information and repository instance 2404D is constructed for the TOS type and venue. The repository instance is then used to request material to access the data source 2406D for a particular venue. The data is then received, a commercial object is constructed and the data 2408D is transmitted. Display data 2410D on your web browser.

24D-2 is an exemplary flow diagram of an exemplary workflow process for repository initialization consistent with one or more aspects of the innovations herein. The site information 2414D for the requested venue is received from the cache site list. Receive TOS type and connection 2416D from site information. From the repository's cache list, retrieve the repository instance 2418D for the specified venue and TOS type. Determines whether the repository instance exists 2420D. If it exists, it returns to repository instance 2426D. If no repository instance exists, a new repository instance 2422D is constructed for the specified venue and TOS type. Cache the repository instance 2424D for the specified venue and TOS type.

24D-3 is an exemplary flow diagram of an exemplary workflow process for connecting to a data source consistent with one or more aspects of the innovations herein. Make a connection to the data source 2430D and then call the repository The method retrieved the data 2432D from the data source. The data 2434D is received and the received data 2436D is returned. The data source 2438D is then disconnected.

24D-4 is an exemplary flow diagram of an exemplary workflow process for displaying material consistent with one or more aspects of the innovations herein. Receive data 2442D from the data source. The model object 2444D is updated in the view object with the retrieved data. The view object 2446D is constructed with the updated model object. Returns the view object 2448D.

24D-5 are exemplary flow diagrams of an exemplary workflow process for making a reservation consistent with one or more aspects of the innovations herein. A request to receive available time slot information to make a reservation 2552D at the first collection station or the second collection station. Determine if the time slot is available to determine 2554D. If no time slot is available, set the time slot and limit 2556D for the first terminal or the second terminal. If the time slot is available, the time slot is selected and a full appointment 2558D is made at the first collection station or the second collection station. A determination is made as to whether or not to select a double reservation 2560D. If no double reservation is selected, the full reservation information is saved to the reservation database in the 2562D for the first collection station or the second collection station. If a double appointment is available, an empty appointment 2564D at the first collection station or the second collection station is made and the data is saved to the reservation database.

24E is an exemplary flow diagram of an exemplary workflow process for making a dual appointment consistent with one or more aspects of the innovations herein. In order for the truck line dispatcher to use the truck driver time effectively, the dispatcher will schedule a truck driver schedule to deliver and pick up the equipment in the same access to the terminal. Therefore, when scheduling a truck driver for an appointment, The buddy can make an appointment for both the warehousing movement and the warehousing movement of the same truck during the same date and time slot. Users have the ability to pair and unpair appointments. In addition, users can create paired dual mobile appointments (one inbound and one out) for all combinations of mobile types.

In some implementations, the user requests to create an appointment repository instance for a particular TOS and will modify the subscription profile relative to the data in the TOS.

Some of the repository methods for dual appointments may include the following exemplary code:

As illustrated in Figure 24E, a full entry reservation 2402E is created. Subsequently, a determination is made as to whether the subscription information is available 2404E. If not available, the subscription information 2420E from the TOS is retrieved. If available, a determination is made as to whether the UNT information is available or whether the reservation is a one-time access decision 2406E. If not available, UTN Info 2408E is retrieved. Time slot if available And determine whether the 2410E is available. If it is not available, set the time slot 2412E. If available, enter container, chassis and crew information. The information is sent to the subscription data source 2416E and the information 2418E is verified in the TOS.

For vacancies, create an empty appointment 2422E. Subsequent decision 2424E is made as to whether the subscription information is available. If not available, the subscription information 2420E from the TOS is retrieved. If the information is available for 2424E, the UTN information is the same as the In move. Similarly, the time slot is limited to the same 2428E as the inbound movement. Then enter the size, type and chassis information 2430E. Send the information to the appointment data source 2416E.

24F is an exemplary flow diagram of an illustrative workflow process for making a reservation for a plurality of collection stations consistent with one or more aspects of the innovations herein. According to some implementations, a voyage tracking user associated with a licensed truck carrier may create and modify an appointment for all mobile type appointments. When an appointment is created, the truck carrier user (based on the user license) will then have the ability to make, modify, and delete appointments for the defined type of movement. Truck drivers at different terminals can make appointments simultaneously using the Voyager Tracking System. Based on the collection station selection, the reservation repository will connect to different TOS repositories and use the associated TOS verification information.

As illustrated in Figure 24F, each user 2402F, 2404F, 2406F interacts with individual website interfaces 2408F, 2410F, 2412F. The user may be the manager or dispatcher of a different truck company at a different collection station, the manager or dispatcher selecting a type of movement such as an in/out/double. Based on mobile type and TOS type, for the distribution station 1/TOS1 and the distribution station 2/TOS 2 structure Repository instance 2414F. Requesting and verifying the subscription/bill of lading/Edo information using the repository instance to access the data source 2418F for the collection station 1/TOS1 2416, the distribution station 2/TOS 2, and access for the collection station 1 or the collection station 2 /TOS 1 or TOS 2 data source 2420F. Information 2422F is generated for creating a reservation for the collection station 1 or the collection station 2. Subsequently, a repository instance 2424F is constructed for the hub 1/TOS 1 and the hub 2/TOS 2 based on the TOS type. Request and verify device information using the repository instance to access the data source 2426F for the hub 1/TOS 1. The repository instance is requested and verified using the repository instance to access the data source 2428F for the hub 2/TOS 2. The materials are received and the appointment object 2430F is constructed for each appointment. The existing data 2432F for reservation is requested from the reservation database. Display single/double appointment data 2434F.

24G is an exemplary flow diagram of an exemplary workflow process with a reservation interface for a gate operating system consistent with one or more aspects of the innovations herein. The reservation system can be used by different gate operating systems. These systems may use an interface developed using, for example, WCF (Windows Communication Foundation) services or some other interface to make an appointment. Each truck 2402G, 2404G, 2406G includes an RFID/UTN for individual terminals in individual gate operating systems. When the truck enters the collection station, based on the RFid and OCR readings of the device, information can be received to verify the UTN (eg, the truck is relative to the RFID 2408G for the collection station 1 or the collection station 2). The appointment can be verified by an individual collection site source. For example, a sink gate repository instance 2412G connected to an appointment data source can be constructed. The reservations 2414G and 2416G using the TOS 1 and TOS 2 data sources can be verified. The best reservation 2418G can be selected from the candidate/formal/one-time access reservation from the reservation database. Can be constructed to be used to make reservations The reservation item 2420G of each truck of the library. The reservation data 2422G for the gate operating system can be returned. Information can be passed back to the gatekeeper. Based on the available data, the gate manager may decide to allow the truck to enter the collection station (eg, if the truck has an appointment for its schedule). Additionally, when the truck exits the collection station, the appointment can be updated (eg, updated with information about the delivered device from the dock).

24H is an exemplary block diagram of an exemplary workflow process with a reservation interface for a gate operating system consistent with one or more aspects of the innovations herein. Truck freight company managers and dispatchers can create appointments. Use this appointment when the truck reaches the gate. The gate operating system can query appointment information to speed up device picking or equipment unloading. Some embodiments of the invention include a service API that can be used by a gate operating system. These APIs will use the TOS system for instant verification and return appointment and device information to the gatekeeper. Based on this information, the gate manager will decide to allow the truck to enter the terminal. Examples of exemplary codes are provided below:

In Figure 24H, a user 2402H, such as a hub manager, truck line manager, or dispatcher, interacts with the appointment interface 2404H. Interface 2404H receives and transmits data using reservation system 2408H. The reservation system 2408H provides the reservation information and receives the reservation from the gate operation system 2406H. The gate operating system can be an external system. The reservation system requests information and receives a response from the TOS database 2410H. The reservation system provides reservation information and receives insertions/updates from the VT database 2412H.

24I is an exemplary flow diagram of an exemplary workflow process for RFID registration consistent with one or more aspects of the innovations herein. In order to enter the collection and distribution station, each truck is required to have an RFID tag. This RFID tag is required to support call forwarding and gate processes. Register the RFID tag with the truck company. The distribution station manager can create RFID tags in batches and assign them to the truck shipping company as needed. Truck company managers can manage RFID and assign these RFIDs to individual trucks. Use the RFID registration page for maintenance of RFID tags. Here are some implementation options for the interface for RFID repositories:

Users 2402I, 2404I, and 2406I provide information to create RFID 2408I for collection station 1 or collection station 2. The user can be a collection station manager of any of a plurality of collection and distribution stations. An RFID repository instance 2410I that connects to the subscription data source is constructed. The data is received and an RFID object is constructed for each of the collection stations and the data 2412I is transmitted. Request for existing data 2414I for RFID from the reservation database. The RFID registration data 2416I is displayed.

24J-1 is an exemplary flow diagram of an exemplary workflow process for truck company registration consistent with one or more aspects of the innovations herein. A truck company registration is provided for truck line companies authorized to receive and deliver equipment to the collection and distribution station. Each truck line company includes the registered truck. Some implementation options for truck company registration include the following exemplary codes provided:

Users 2402J, 2404J, and 2406J provide information to create a truck line terminal 1 or 2 2408J. The user can be the truck company manager of a different truck company of any of the multiple collection stations. A truck company repository instance 2410J connected to the reserved material source is constructed. Receive data and construct truck line items for each truck line and transmit data 2412J. Request for existing data 2414J for the truck line from the reservation database. Display information on the truck company profile 2416J.

24J-2 is an exemplary flow diagram of an exemplary workflow process for picking up containers using appointments consistent with one or more aspects of the innovations herein. The truck driver arrives at the gate and requests the container 2420J. The gate system in the TOS requests the reservation information 2422J. A determination is made as to whether the reservation information is available 2432J. If it is not available, the error 2434J is determined. If available, the gate system in the TOS processes the transaction and completes the appointment 2436J. After requesting the appointment information 2422J, the reservation system determines 2424J the appointment associated with the container. Determine whether the reservation/container information is available 2426J. If the appointment is not found, a determination is made as to whether or not the fake appointment is allowed 2428J. If a fake appointment is allowed, a fake appointment 2430J is created.

25A-25V are diagrams of exemplary subscription user interfaces including the ability to manage appointments consistent with one or more aspects of the innovations herein. Moreover, various functions of the present invention, such as the functionality of the reservation system described herein, and associated system/server processing may also be implemented via or in conjunction with a mobile application and associated mobile device interface, where such technological innovations are utilized. An exemplary mobile device interface is illustrated in Figures 47A through 47U and In the description of the associated writing.

Specifically, in FIGS. 25A-1 and 25A-2, the user can make, modify, delete, and observe the reservation information for the empty container, and run a designated query that allows the user to work on the appointment. The time slot 2502 allows the user to view the number of appointments available for a particular time slot and allows the user to select a particular time slot for the empty entry container reservation. Hidden 2504 allows the user to filter the empty container out of the appointment list view so that the selected container will not be displayed. Hidden filters can be added and removed as needed. The container return status 2506 is assigned to verify the empty return status of the empty container relative to the shipping company. Here, the implementations herein will use TOS to transmit/process information to determine or verify status or data regarding the return and return status of the container, and/or to perform various other empty entry verifier functions as set forth herein. For example, when a shipping company, container equipment information such as size type, etc., has been identified, processing can be performed to provide the correct status and the equipment is automatically authorized to enter the collection station. In some implementations, the empty container return status 2506 includes functionality to reference data from the TOS system to determine the condition of the container. If the return is unacceptable, the TOS return to the container is unacceptable. Moreover, systems and methods may include or involve TOS agnostic processing, functionality, and functionality as set forth elsewhere herein. Returning to the figure, the spurious/empty container 2508 allows the user to separate appointments for empty inbound containers that have been defined as dual mobile appointments (empty in and out). This feature allows empty containers to move without full movement.

Figure 25B illustrates an exemplary GUI that a user can make, modify, delete, and observe appointment information for a subscription such as an exit subscription. The time slot 2510 allows the user to observe the number of appointments available for a particular time slot and allows The user selects a specific time slot for the export subscription reservation. The double vacate movement 2512 allows the user to make two appointments simultaneously for different types of movement (eg, full entry and exit movements and vacancies). Additional processing and or functionality of the selections shown herein are set forth in further detail in conjunction with FIG. Based on such functionality, an improvement in the technical utilization of the system is achieved, including avoiding any additional processing to directly contact the collection station in order to prevent previously performed steps, providing an innovative verification process that prevents various non-essential system actions and processing A setting such as an invalid appointment in which the truck arrives to deliver the cargo, for example, when the ship has left.

25C-25D illustrate an exemplary GUI that a user can make, modify, delete, and observe import reservation information for an import container. Figure 25C shows the made import container reservation, while Figure 25D, described below, illustrates the import container reservation display prior to the final selection. Notifications 2590, 2514 allow the user to request a container reservation availability notification based on the container status (ie, "Ready to Make a Reservation", "Not Ready to Make a Reservation"). The slots 2592, 2516 allow the user to observe the appointments available for the particular time slot. Quantity, and allows the user to select a specific time slot for the import container reservation. Double vacant movements 2594, 2518 allow the user to make two appointments simultaneously for different types of movement (empty in and out of import movement). By the selection of such functions, processing is performed via the system to allow the user to receive or otherwise be notified of notification information regarding changes in the appointment status. For example, in the case of "out" processing of various imported containers, the present embodiment may be automated and/or involve processing associated with causing or returning empty containers "in". Based on such features, improvements are made to the technical utilization of the system, including by inputting containers and SSCO information. With the implementation of a dual mobile appointment, the container and SSCO information can further define and perform processing associated with the move in and/or the double move. Additionally, further processing and technological innovations may be provided herein via the functionality and functionality associated with the BOL routine as illustrated in Figure 25L. For example, various booking processes can be performed before the container is available.

Figure 25E illustrates an exemplary GUI for single/dual appointment setup. A single/double appointment option 2501 can be selected from the reservation menu bar to make a new single/double appointment. The user will have the option to make a single or dual mobile appointment by selecting the specified mobile type 2503.

25F-25V are diagrams of exemplary subscription user interfaces consistent with one or more aspects of the innovations herein. Figure 25F illustrates an exemplary GUI for single/dual appointment settings for a single appointment. After selecting the inbound and outbound movements, multiple movement types 2509 can be utilized for selection. The move type 2509 can be selected from the drop down menu. Thereafter, the appointment details can be entered based on the selected movement type 2509. Figure 25F illustrates the user selection of the move, and the display of the drop down menu for the selection of the exit, empty, import, and bare bottom entry options.

Figure 25G illustrates an exemplary GUI for single/dual appointment settings for a single appointment. After selecting one or both of the inbound and outbound movements, multiple movement types 2515 may be utilized for selection. The move type 2515 can be selected from the drop down menu. Thereafter, the appointment details can be entered based on the selected movement type 2515. Figure 25G illustrates the display of a user selection for movement, and a drop down menu for selection of the inlet, outlet, exit, and bare bottom options.

Figure 25G illustrates an exemplary GUI for single/dual appointment settings for dual appointments. After selecting one or both of the move and exit moves, multiple move types 2519 can be utilized for the selection. The move type 2519 can be selected from the drop down menu. Thereafter, the appointment details can be entered based on the selected movement type 2519. Figure 25H illustrates the user selection of moving in and out, respectively, and for moving in: exit, empty, import, and bare bottom, and move: import, vacate, exit, and exit The display of the drop-down menu for the selection of the bare chassis option. The exit entry is selected as the move type 2519 for entry into the move.

Figure 25I illustrates an exemplary GUI for scheduling a single/dual appointment setting for a header assembly. Make a reservation for the mobile type of entry and exit. To begin some of the ordering inquiry processing for an exit or vacancy reservation, enter the booking number 2523. The subscription information corresponding to the subscription number is presented from the TOS to provide details regarding the deadlines of the received device and the delivered device to the collection and delivery station. Information can also include details about dangerous cargo. The posting information is shown in FIG. 25I as the stowed state 2525, the stowage summary result 2527, and the appointment details 2529. Based on the information shown in Figure 25I, the user can decide how to proceed with the transaction. The additional processing herein is explained in further detail in conjunction with FIG. Based on such functionality and functionality, the user can explore a single subscription query or multiple subscription queries and be returned status information for all of the subscriptions for all devices.

For the scheduled inquiry, an initial verification process is performed to determine whether the status of the order is valid, the booking is undiscovered or past booking (where the ship/cargo leaves). If the status of the subscription is not found in the TOS, notify the dispatcher (example) For example, the trucking company) contacted the shipping company to determine why the booking information does not exist in the TOS. This feature prevents users from directly contacting the port collection terminal to avoid previous steps. In addition, the verification process performed prevents settings such as invalid reservations in which the truck arrives to deliver the cargo, for example, when the ship has left.

Figure 25K illustrates an exemplary GUI for a single/dual appointment setting for a bill of lading bill of lading. The bill of lading is inquired about the type of imported mobile. For an import reservation, enter the bill of lading number 2533 to request a bill of lading. Presents bill of lading information corresponding to the bill of lading number. The bill of lading information is shown in Figure 25K as state 2535, summary result 2537, and appointment details 2539.

If the bill of lading is valid, the appointment details 2539 will appear for the user to make an appointment. The bill of lading will return one of the valid bills of lading, the unclaimed bill of lading or all the containers delivered on the bill of lading. If a valid status is returned, an appointment can be made to pick up the load. A first verification process is performed to provide one of the three states discussed above. Subsequently, for the active state, a second verification process is performed. The user can make an appointment and check the status of the goods, customs status and other maintenance information. The hold state can indicate hold or release. If left as appropriate, the user can still make an appointment and return to the pending state, inactive/completed state. If the user makes a reservation while maintaining it, the system automatically advances the status/process once it has been promoted to automatically switch the status from pending to active. In the pending state, the reason for the processing is processed and includes the pending/hold status. Subsequently, when the state switches to activity, another notification is generated to the user indicating the next available step (eg, delivering or picking up the cargo).

Figure 25L shows an exemplary sequence diagram of an exemplary bill of lading (BOL) process and TOS agnostic process in accordance with one or more aspects of the innovations herein. Referring to Figure 25L, the illustrative process can begin at step 2536, where the user logs into the collection and delivery site A via a website-based user interface and enters a request for bill of lading information for the collection station A database. For example, the user can request information on the bill of lading number BK123456. Next, the TOS Agnostic Service 2534 receives and processes the user request for the bill of lading information. Service 2534 calls the FindBOL method 2542 in the Import Service 2544. Import Services 2544 implements methods related to the importation of commercial processes. The FindBOL method 2542 is processed by the BOL repository 2572. The import service 2544 first requests the BOL repository instance from the repository factory 2554 using the GetBOLRepository method. The repository factory 2554 is a repository locator that returns a repository instance for the collection and distribution station A. The repository factory 2554 requests the bill of lading repository for the collection station A using the GetInstance method. The BOL repository 2572 retrieves and stores the bill of lading information for the collection station A from the collection station A database.

Next, the FindBOL method 2558 is defined in the import service 2544 to call the FindBOL method 2576 of the BOL repository 2572 to request bill of lading information corresponding to the BOL number BK123456 of the collection and delivery station A. The FindBOL method 2576 accesses the distribution station A database and obtains the requested bill of lading information from the collection station A database as the BOL entity 2578. The BOL entity 2578 is then stored in the BOL repository 2572 as a bill of lading object 2560. For example, the BOL entity 2578 retrieved from the collection station A as the original data is converted/converted into the bill of lading commercial item 2560. The bill of lading object 2560 is then returned to the import service 2544.

In addition, GetContainer 2562 is used to retrieve and request A single method call for the relevant container information. Similar to the GetBOLRepository method, the import service 2544 executes the GetContainer method 2568 on the repository factory 2554 to obtain container information corresponding to the bill of lading information requested by the user. The GetInstance method 2564N requests an instance of the container repository 2580 for the collection station A. The GetContainers method 2568, implemented by the Import Service 2544, requests container information relating to the bill of lading information from the container repository 2580. The container repository 2580 uses the GetContainers method 2584 to retrieve information relating to the imported containers corresponding to the bill of lading number from the collection station A database. In response, the collection station A database transmits the requested data as a container entity 2586. The BOL entity 2578 and the container entity 2586 are provided in the form of a distribution station A operating system that is incompatible with the format of other collection station operating systems. Accordingly, the container repository 2580 converts/converts the original container information 2586 of the collection station A into a container item 2570 to be added to the container repository 2580. Once the BOL item 2560 and the corresponding container item 2570 are returned to the import service 2544, the bill of lading and container item collection 2546 is returned to the TOS Agnostic Service 2534. The TOS Agnostic Service 2534 processes the business item data 2546 and displays the bill of lading and container object 2548 to the user via a website based user interface.

Figure 25M illustrates an exemplary GUI for scheduling a single/dual appointment setting for a header device bill of lading (EDO). EDO queries are made for vacant and bare chassis movement types. For each type of reservation in these mobile types, enter EDO number 2543 for EDO inquiry. An EDO message corresponding to EDO number 2543 is presented. The EDO information is shown in Figure 25M as state 2545, summary result 2547, and appointment details 2549. If a valid EDO is provided, The appointment details 2549 will be displayed. When looking for a subscription, you can also search for EDO records. However, this is different from the bill of lading and is more similar to the find ordering function for exporting.

Figure 25N shows an exemplary sequence diagram relating to an exemplary EDO process and TOS agnostic process consistent with one or more aspects of the innovations herein.

Figure 25N shows an exemplary sequence diagram relating to an exemplary EDO process and TOS agnostic process consistent with one or more aspects of the innovations herein. Referring to FIG. 25N, an exemplary process may begin at step 2536N, where the user logs into the collection terminal A via a website-based user interface and enters a request for EDO information for the collection station A database. . For example, the user can request information for the EDO number BK123456. Next, the TOS Agnostic Service 2534N receives and processes the user request for the EDO information. Service 2534N calls the FindEDO method 2542N in the null service 2544N. The Air Service 2554N implements methods related to the empty business process. The FindEDO method 2542N is processed by the EDO repository 2572N. The empty service 2544N first requests the EDO repository instance from the repository factory 2554N using the GetEDORepository method. The repository factory 2554N is a repository locator that returns a repository instance for the collection and distribution station A. The repository factory 2554N requests the EDO repository for the collection station A using the GetInstance method. The EDO repository 2572N retrieves from the collection station A database and stores the EDO information for the collection station A.

Next, the FindEDO method 2558N is defined in the empty service 2544N to call the FindEDO method 2576N of the EDO repository 2572N to request EDO information corresponding to the EDO number BK123456 of the collection station A. The FindEDO method 2576N accesses the distribution station A database and obtains the requested EDO information from the distribution station A database as the EDO entity 2578N. The EDO entity 2578N is then stored in the EDO repository 2572N as an EDO object 2560N. For example, the EDO entity 2578N retrieved as raw material from the collection station A is converted/converted into an EDO commercial item 2560N. The EDO object 2560N is then returned to the empty service 2544N.

In addition, GetContainer 2562N is an internal method call to retrieve container information related to the requested EDO. Similar to the GetEDORepository method, the null service 2544N executes the GetContainer method 2568N on the repository factory 2554N to obtain container information corresponding to the EDO information requested by the user. The GetInstance method 2564N requests the container repository 2580N instance for the collection station A. The GetContainers method 2568N implemented by the empty service 2544N requests container information related to the EDO information from the container repository 2580N. The container repository 2580N uses the GetContainers method 2584N to retrieve information relating to empty containers corresponding to the EDO number from the collection station A database. In response, the collection station A database transmits the requested data as the container entity 2586N. The EDO entity 2578N and the container entity 2586N are provided in the format of the distribution station A operating system, which is incompatible with the format of other distribution station operating systems. Therefore, the container repository 2580N converts/converts the original container information 2586N of the collection station A into the container item 2570N to be added to the container repository 2580N. Once the EDO object 2560 and the corresponding container item 2570N are returned to the empty service 2544N, the EDO and container item set 2546N is returned to the TOS Agnostic Service 2534N. TOS unknowable service 2534N processing commercial object information 2546N and via the network The station-based user interface displays the EDO and container object 2548N to the user.

Figure 25O illustrates an exemplary GUI for single/double reservation settings for subscription details. The appointment details include the UTN type, which includes a lease voyage 2553, a visitor 2555, and a registered UTN 2555. The lease voyage option involves, for example, a truck's allocation agreement, which requires further input that can be verified by the system. A visitor provides an option for a user of an unregistered device to enter the collection and delivery station for a single reason. Time slot 2557 allows the user to view the number of appointments available for a particular time slot and allows the user to select a particular time slot for the appointment and candidate reservation 2559. A candidate appointment is an option to not schedule a reservation time. There are delegates for delivery or picking instead of time. The reservation can be set without a specific time.

Figure 25P illustrates an exemplary GUI for submitting a single/dual subscription setting for a subscription for verification. After entering the appointment details for the specified move, submit the appointment details and TOS verification. If the VT reservation verification 2563 displays an error 2565 based on the reservation details information, the system will remain on the reservation page until the error is corrected and resubmitted.

Figure 25Q illustrates an exemplary GUI for single/double reservation setup for a secondary verification process. The subscription can be released with an error that must be resolved. The problem can be corrected by the navigator or by contacting the entity involved. The resulting message detail page 2569 will be returned with the final TOS verification and includes a note 2571. Once all fields have been entered and submitted by the user, the initial verification process is performed. Verification is performed from the initial inquiry, via the intermediate segment, to verify and determine/provide a final appointment to be made. Conduct with all fields The associated verification uses a variety of TOS or other databases to confirm/verify the information and status to provide a final verified appointment.

FIG. 25R illustrates an exemplary GUI for modifying single/double reservation settings for subscription details 2579. After successfully submitting the appointment, the user can modify the appointment by button 2577 to pair a single mobile appointment or unpair the dual mobile appointment, clear the appointment page and make a new appointment, change the subscription, bill of lading or EDO, and modify/delete the appointment details And resubmit for verification. In this manner, the user is provided GUI functionality to modify the appointment, such as by pairing a single appointment to create a dual entry appointment, unpairing dual moves to create a single appointment, clearing, changing the subscription/BOL/EDO. Verify all booking details.

Figure 25S illustrates an exemplary GUI for single/double reservation settings for pairing reservations. Pairing an existing single mobile appointment 2583 can be viewed by modifying the subscription page by selecting the pairing button 2585 to pair the existing single mobile appointment with another existing single mobile appointment. Existing appointment searches can be made by date range, UTN or reservation ID. From any existing single-entry mobile appointment, the user may simply add a new single out-of-mobile 2583 appointment to thereby create a dual mobile appointment.

FIG. 25T illustrates an exemplary GUI for canceling the single/double reservation setting of the pairing reservation. The unpairing button 2589 can be selected to unpair the existing dual mobile subscription from the modified subscription page to unpair the dual mobile subscription, resulting in two single mobile appointments. When the dual mobile appointment is unpaired, the UTN and the appointment date/time from the original dual appointment will apply to both appointments.

Figure 25U illustrates an exemplary GUI for changing the single/double reservation settings for the subscription/bill of lading/EDO. The appointment booking/bill of lading/EDO can be changed for the event and pending appointments in the following manner. For existing appointments for export entry, the vacate, import or bare bottom option changes the subscription/bill of lading/EDO button 2593. The system will prompt the user to enter the order/bill of lading/EDO number and, if valid, the user can apply the change. In some implementations, the function illustrated in Figure 25U utilizes the process associated with Figure 25L (finding the bill of lading) and Figure 25N (finding the EDO).

Figure 25V illustrates an exemplary GUI for deleting single/double reservation settings for subscription details. For example, after successfully submitting an appointment, the user can delete the specific device appointment using the delete option 2597. The delete action may result in the unpairing action such that if the appointment associated with the dual move is deleted, the system will automatically trigger the unpair action.

26A through 41 below illustrate various functions and functionality of the reservation system illustrated by the illustration in a conventional desktop computer display. In addition, various functions of such inventions, such as the functionality of the reservation system described herein, and associated system/server processing may also be implemented via or in conjunction with a mobile application and associated mobile device interface for use in such technological innovations. An exemplary mobile device interface is illustrated in Figures 47A-47U and associated written descriptions.

In Fig. 26A, the manager can set the configuration of the first reservation system (PAS) for the current collection and distribution station and set various configuration values. The location/move type requires that the appointment 2602 allows the user to match the requirements to have an appointment for all mobile types as well as a particular import container mode. Moved on all devices used by The reservation limit 2602 is provided in the case where a specific movement type definition of the appointment is made. For example, each type of movement can be associated with different restriction requirements. The location/move type import container unavailability factor 2604 allows the user to be grouped to exclude specific import container availability factors that require an appointment. In the implementations herein, for example, various subscription functionality (e.g., functionality regarding status, announcements, etc., as set forth elsewhere herein) may be performed even when a particular action may be to preserve the status quo to otherwise prevent such processing. The Position/Moving Type Import Container Reservation Delete Cutoff option 2606 allows the user to configure an option to allow the truck shipping company user to delete or create a reservation within a given time slot that provides the user with the flow to change the appointment at any time. Sex. The appointment time wind pressure difference 2608 allows the user to assemble and define an appointment time wind pressure differential that allows the truck driver to arrive within a defined margin before and/or after his scheduled appointment time. Because of these functions and functionality, the systems and methods herein can be assembled to automatically plan and locate containers for outbound operations such as delivery, and to coordinate space and other terminal requirements for inbound containers and operations.

Figure 26B illustrates an exemplary GUI of a reservation limit report that displays time slots and appointment statistics for the selected date range, location/mobile type, and dock area. Figure 26C illustrates an exemplary GUI in which an administrator can set limits including setting gate hours, time slots, and reservation limits for the current collection station for the selected date. A template for saving and applying settings. The appointment statistics for the dock area can be observed and the appointment can be cancelled. The Set Limit Fold view 2610 allows the user to collapse and expand the view for all types of movement. 26B to 26C show how the type of movement can be based on About the restrictions, information about ship loading, ship unloading, and dock activities to automatically manage and match the performance of the distribution station. Based on such capabilities, improvements in system technology utilization are achieved, including the planning and positioning of cargoes delivered by ships, trains and/or trucks in container terminals, and limit settings to control truck traffic/traffic volume. The collection and distribution station can set limits according to the type of movement, the state of the ship, the capacity of the container, and the like.

Figure 26D illustrates an exemplary GUI in which setting constraints are defined with respect to an administrator appointment, demonstrating an exemplary setting restriction undefined location 2611 interface or functionality. Regarding this function, the system and method of the present invention provides a view of an undefined dock position by an area or block that does not have a reservation limit setting. A user such as an administrator can utilize the GUI to determine an area of the dock that does not yet have a set limit by providing, for example, the number of the container in the predetermined area. Additional processing and or functionality of the selections shown herein are set forth in further detail in conjunction with FIG.

Figure 26E illustrates an exemplary GUI in which the administrator can observe the selected date range, location/movement type, and time slot of the dock area and the reservation report display of the reservation statistics. Set Limit View Dock Area Statistics 2612 allows the user to view statistics from a designated dock area and update the appointment limit for a specific dock area in time slot. In addition, users such as managers can define new appointment limits.

The pop-up window and associated functions shown in Figures 26D-26E provide a graphical summary of the container and/or restriction information for the manager, which can be utilized to allow for improved management of the container terminal.

Figure 26F illustrates that the manager can set limits as described herein. An exemplary GUI. The dock area 2614 for the deck entrance allows the user to define a particular imported deck dock area by means of a block or area dock type. The time slot 2616 for the selected position/move type allows the user to define a particular time slot for all container and chassis movement types. Template 2618 allows the user to create and save a customized template for applying predefined reservation restrictions. The Set Limit Fold view 2620 allows the user to collapse and expand the view for all types of movement. More generally, Figure 26F provides a statistical report that the user sets limits and allows the limit template to be determined. Manage equipment in/out and traffic in/out flows to automatically reduce bottlenecks at gates and terminals to reduce and/or eliminate inefficiencies. Based on the limitations that the administrator can set via this GUI, the systems and methods herein can be configured for gate and/or terminal manager control and associated automated management to, for example, prevent bottlenecks or other logistics problems or problems.

27A-27B illustrate an exemplary GUI sequence in which a user makes an online payment, including a non-deferred payment (multiple payment). Referring to Figure 27A, rate table information 2702 functions and processes may be provided; for example, when a user selects a multi-pay link, the system provides functionality to allow the user to select a predefined terminal fee for the non-delay fee rate table These non-delayed fee schedules are applied to multiple containers or driver's licenses when defined. In addition, the functions and functions of various collection and distribution stations can be completely matched by administrative users. The rate table information 2702 may include a form provided and controlled by the manager. In addition, an edit check process may be provided; for example, from the multi-pay page, when the user submits 2704 container and rate information, the system uses the container edit check rule relative to the TOS to verify the inventory status. Referring to Figure 27B, payment authorization 2706 allows the user to check the payment made for the container and provide Input of bank account information. Here, for example, the option to authorize the payment may cause the system to communicate with the vendor API, which verifies the bank account information and returns to the approved status. In addition, according to various implementations, the payment process of Figures 27A-27B automatically processes the rate table information prior to the time of the sink event, with such third party entities (eg, verifying bank account information, accepting payment providers) API) communication to eliminate or reduce latency and save requirements to prevent additional processing and thus eliminate any associated waste of resources, time, and the like. Thus, contrary to conventional systems that deal with payment problems between dispatchers and trucks at the gates, resulting in cumbersome delays, the payment process is automatically handled and simplified. 28A1 through 28A4 illustrate an exemplary GUI in which a manager can edit a user profile of a user. Referring to FIG. 28A1, the system and method of the present invention provide administrators with 2801 functions, GUI options, and functionality from the administrator user account editing page for profile and permissions. These functions, GUI options, and functionality allow the administrator to use The associated user account is associated with a plurality of terminal locations, thereby allowing the user to access the venues by logging in using the same account. The recent user profile email can also be sent to the user. Referring to Figures 28A1 through 28A3, the additional user association 2802 function allows the administrator to associate the confirmed user account with the truck carrier or ship line to provide a system function related to access for the defined user type. Referring to Figures 28A1 and 28A4, the system and method can provide qualifier/criteria 2804 functionality and functionality from the administrator user account editing page for profile and permissions, which allows the administrator user to The confirmed user account is associated with various criteria, such as report qualifiers, which reflect the defined reporting criteria.

Figure 28B illustrates an exemplary GUI in which a manager can edit a user account profile for a user. The bulk mail 2804, as shown in the manager user account edit page for editing the user, allows the manager to restrict the user from receiving broadcast emails from the voyager tracking. The Appointment Maker 2806 allows the administrator user to define a licensed user to make a reservation for the user to request the container to pre-install the container before picking up. The functionality provided herein can be used to provide a means for an administrator user to obtain a subscribed subscription based on desired criteria, such as a subscription status number or any other type of information.

28C-28D illustrate an exemplary GUI of a search/results page displaying user account profile information based on a user-entered user search query. Figure 28D illustrates an exemplary GUI that an administrator may utilize with some advanced search tools and criteria. User Account Search 2808, as shown in the User Account List page, allows the administrator to make detailed user account information based on specific criteria (ie, login name, first name, last name, email, company name, etc.) or a combination of criteria. search.

Figure 28E illustrates an exemplary GUI of an unconfirmed user results page showing a list of unconfirmed user account information. Here, for example, from the user account list page, the system allows the administrator/user to perform a search for unconfirmed user account information. In addition, once the administrator user accesses the user account information, the administrator user has the ability to confirm the user. According to the updated administrative information and the functions performed in FIGS. 28A to 28E, various processes at the collection and collection station can be automatically performed to avoid time consumption and unnecessary communication between computer systems.

29A-29C illustrate exemplary interfaces by which a user may register for an announcement from a system. FIG. 29A illustrates an exemplary GUI for ordering invalid numbers, which may be registered for event notification 2902 once the subscription becomes valid. The user can register or cancel the registration to receive an event notification via, for example, an email, fax, and/or SMS message.

FIG. 29B illustrates an exemplary GUI that a user may advertise for a customized event 2904, such as for import availability, TMF, lag, exit gate, and/or entry gate status registration. The user can register or cancel the registration to receive an event notification via, for example, an email, fax, and/or SMS message. Another exemplary GUI allows a user to register their account to receive a pause failure status announcement for all device movement types that have a problem with the failure occurring at the gate. For example, the self-accounting account preferences page can do this. The system may allow the user to register or unregister to receive a suspension event notification via, for example, an email, fax, and/or SMS message.

Various notification configuration 2906 functions, GUI options and functionality are available. Referring to Figure 29C, various failure status suspension announcements can be provided. Here, for example, the self account user preference page, the system and method herein allows a user to register their account to receive a pause failure status announcement for all device movement types that have a problem with the failure occurring at the gate. In addition, in some implementations, the user may register or cancel registration to receive a suspension event notification via email, fax, and/or SMS message.

Figure 30 illustrates an exemplary lag delay calculator that the system can provide. From the Deferred Charge Calculator page, the user can calculate the current or future delay payable by the 3002 import container based on, for example, the last free day defined and the tariff rate. Delayed fees. The system allows the user to calculate a delay fee for a single or multiple containers in one query. The system may allow the user to specify a future date of interest and a view report generated by the delay fee calculator. Thus, contrary to conventional systems that deal with payment problems between dispatchers and trucks at the gates, resulting in cumbersome delays, the payment process is simplified, allowing the user to automatically observe the amount of delay fees and/or other fees owed. Figure 31 is an exemplary manager interface that provides venue management functionality to a user. From the Manager Site Management page, the administrator user can select one or more specific terminal locations for configuration. The administrator user can use a custom configuration for, for example, terminal communication, equipment activity reporting, delay fee notification, equipment exchange reporting (EIR), and/or pre-installation to group specific terminal locations. The management of the site configuration of the terminal is provided in an automated manner, saving time and allowing the administrator to establish different configuration levels as needed.

32A-32B illustrate an exemplary manager interface that can provide shipping company management functionality to a user. The SSCO configuration page allows the hub manager to observe and update the SSCO at the site. FIG. 32A illustrates a ship company editing page, and FIG. 32B illustrates a ship company listing page. From the Manager Shipping Company List page, the system allows the administrator user to select the shipping company for editing. From the edit page, the system allows the administrator user to enable or disable the activation of specific functionality by the shipping company. A function 3202 can be edited relating to, for example, announcements, online payments (delayed and non-delayed), import reports, gate activities, and/or ship schedules.

According to the manager function and functionality via FIG. 31 to FIG. 32B, the system and method of the present invention can be automatically simplified for each SSCO. The configuration of the SSCO interface functionality. In this way, the functional configuration including the license, payment, delay fee, announcement, report, gate activity, schedule, etc. is improved for the manager, resulting in improved management by the manager and use of the SSCO. Ease of use.

Figure 33 illustrates an exemplary GUI of a user's trucking company state management functionality. When loading the booking page (imported container, export ordering, empty entry checker, etc.), the system verifies the trucking company status for each trucking company associated with the user account by the shipping company. If the trucking company has an invalid status, an alert message 3302 is displayed along with the details. In the example, the trucking companies in the list each have an explanation of the invalid state and why the state is invalid. In various implementations, when the user's associated trucking company has an insurance issue or alert about the SSCO of the displayed container, the trucking company's insurance timeout/status invalidation alert is displayed each time the import booking page is loaded. Pop up the window. A pop-up window is provided, for example, to inform the user that the trucking company has overdue insurance or that the trucking company has been retired. This allows the user to be automatically notified to avoid any delays and/or problems during gate processing. Although the return status of the truck company insurance is provided, the overdue status does not prevent the user from making an appointment.

34A-34B illustrate an exemplary GUI of the administrator's daily message management functionality for the user. Referring to Figure 34A, self-editing the daily message page, the system provides a GUI interface 3402 that allows the administrator user to define a new layout based on the available configuration. In addition, in some implementations, a message may be highlighted to indicate an alert status, and the user may post a new message or modify an existing message. The daily message editing page allows users to edit and save today Daily priority message and today's message. Referring to Figure 34B, an exemplary new custom control item 3404 pops up and functionality is shown in which the user/administrator can edit the Today message. In some implementations, Figures 34A-34B serve as salient pages for providing communication status of the collection station/instrument.

35A-35C are diagrams of exemplary report user interfaces consistent with one or more aspects of the innovations herein. Figure 35A illustrates an exemplary GUI of a manager's report management functionality for a user. The returned manager report shows the event appointment and historical information. Specifically, the report provides real-time information about the status of the truck. Based on the report, the user may, for example, be able to determine the cause of the delay or may assign another truck to pick up the container. In other implementations, the user and/or manager may be notified to miss the appointment and other information related to the container. The reports generated by Figures 35A-35C may be particularly useful for, for example, users, managers, trucking companies, and dispatchers.

Figure 35B illustrates an exemplary GUI of the user's exit report management functionality. Figure 35C illustrates an exemplary GUI of the user's import report management functionality including online payment and deferred payment. The import report displays container information for the selected consignee from the list of associated import qualifiers for the user. The posting report displays the shipper's summary information from the list of associated export qualifiers of the user. The Appointment Report displays appointments, search options (by date, date/time range, container number or order/release number) for the selected location/mobile type, appointment status, selective reporting field, truck shipping company and report The type (summary or detail) specifies the sort order of the detailed report. When the import container has a delay fee due amount, the system allows the administrative management user to match the display of the payment link 3502, the payment link allows The user is required to pay a deferred fee for a specific container. When the import container has a delay fee due amount, the system allows the administrative user to assemble a display of the payment link 3504, which allows the user to pay a delay fee for a single or multiple containers in a transaction, and Payment for future dates.

36 is a diagram of an exemplary broadcast email user interface consistent with one or more aspects of the innovations herein. The Broadcast Email page allows the hub manager to send an email to all users of the venue. Referring to Figure 36, an exemplary GUI is shown, again as observed in conjunction with the appendix, in which the administrator can broadcast deciding information by weighing all emails to all application users of the collection station.

37A-37C are diagrams of exemplary EIR (Device Exchange and Inspection Report) user interfaces consistent with one or more aspects of the innovations herein. Figure 37A illustrates an exemplary GUI for a user to report gate activity management functionality. The Gate Activity Report displays information on gate activity for a combination of the following criteria: transaction status (complete, in progress, suspension, all), trucking company, ship route, shipper/consignee, container and chassis movement type, number of moves, Specific container or chassis, displayed fields, sort order of displayed fields, report type (summary, details, or both). The gate activity report may be generated when the truck leaves the terminal facility and may serve as an official record for the container, such as a proof of delivery. Figure 37B illustrates an exemplary GUI of a user reporting gate activity result management functionality. A summary including all moves, empty in/out, active timestamps, status, and medium is available. Figure 37C illustrates an exemplary GUI for a user to report gate activity search display management functionality. Can be set Values are reported as a combination activity.

38 is a chart of an exemplary release user interface consistent with one or more aspects of the innovations herein. The TMF (Traffic Mitigation Fee) release and TMF release reversal notices apply to the import cycle and are especially applicable to, for example, the PierPASS terminal. As a background, the container has a TMF state that is held or released. Here, subsequently, all users can maintain status registration with the TMF for email or fax TMF release notifications for the container. The Distribute Station Manager function allows certain containers to make exceptions for certain fees such as TMF. Referring to Figure 38, an exemplary GUI is illustrated in which a manager can release a container from various holding situations or events, such as by the port for LA and Long Beach for container picking, during peak hour traffic hours. The amount of traffic is relieved.

39 is a chart of an exemplary reporting ship schedule user interface consistent with one or more aspects of the innovations herein. The Ship Schedules page allows the user to select shipping routes and time slots to view the ship's schedule. Referring to Figure 39, an exemplary GUI is illustrated in which a user can query and obtain information regarding ship arrival, departure, and work schedules. A report ship schedule can be provided to determine when the ship arrives, cargo availability, empty release, and full start, where the empty release indication will where the empty bin will be released for picking, and the full start will indicate when to begin receiving/picking the full container.

40 is a chart of an exemplary multi-tracking user interface consistent with one or more aspects of the innovations herein. The multi-tracking query function and functionality here allow users to run queries on multiple containers, bills of lading (BOL) or on-demand, and provide innovative treatments based on such containers, bills of lading or bookings. UI and results. Referring to Figure 40, an exemplary GUI is illustrated in which a user may have innovative features and options as well as quick access to run queries on a plurality of data items such as containers, bills of lading, booking, release, announcements, and appointments.

41 is a diagram of an exemplary device history user interface consistent with one or more aspects of the innovations herein. The device history page allows the hub manager to search for the history of the device. Referring to Figure 41, an exemplary GUI is illustrated in which an administrator can access information about devices (containers and chassis). Among other things, the implementations herein include processing and may include further processing associated with current container status, history of state changes, and gate transactions. A device history report is provided to provide an order of events associated with the container, and the status is provided to the user to save time and allow proper planning and execution of the container logistics.

In some implementations, the integration of the Voyager Tracking (VT) reservation system with the Terminal Station Operating System (TOS), the Terminal Station Trucking System, and the Gate System provides the dispatcher/truck driver with the dispatcher/truck The pre-arrival notification of the planned movement of the driver and the verification of the purpose of the adjustment to the terminal are used to facilitate the simplification of the truck traffic through the terminal. This situation is verified relative to the terminal operating system, allowing for erroneous or missing information to be corrected before dispatching the truck to the terminal. In addition, integrated data simplifies gate operations by providing automatic gate performance. For example, by identifying via optical character recognition (OCR) and dynamic ground scale (WIM), the device data can be utilized to match the reservation device to the device that reaches the gate carrier.

Figure 42 illustrates an exemplary block diagram of a pre-notification for a container consistent with one or more aspects of the innovations herein. Dispatcher will import / export The appointment is entered into the reservation system. The reservation system API integrates the reservation to the TOS terminal plan 4203 via the TOS 4205. The terminal planner sets the terminal block allocation and plans equipment requirements 4209 based on the expected type and number of container movements from the appointment.

Figure 43 illustrates an exemplary block diagram for truck arrival at a collection station consistent with one or more aspects of the technical innovations herein. When the truck 4301 passes the RFID antenna checkpoint, the reservation system API 4305 can be called to return to the reservation state. The appointment is found 4307 and then verified via the TOS Validation API 4311 within both the reservation system rules 4309 and TOS 4315. The Terminal Station Operating System (TOS) verifies that the requested appointment meets all equipment, ordering, equipment bill of lading (EDO), bill of lading (BOL) and container status verification. This verification relative to the TOS allows for errors or missing information to be corrected before dispatching the truck to the terminal. The appointment status is returned to 4317 and provided to the collection station truck queue system 4319. A determination is made as to whether there is a pending appointment or no appointment 4319. The result is transmitted to the truck driver 4321 via the notification agent.

In some implementations, a VT return reservation status API is provided to determine if the truck arriving at the collection station has a valid appointment and thereby has an adjustment purpose for reaching the collection station. After the truck arrives at the terminal truck lane, the API request will be posted to the reservation system for the current appointment status. The reservation system will receive the RFID (Radio Frequency Identification) tag number and arrival time of the truck. Using this information, the reservation system will locate the best appointment to match the RFID time slot and return the status of the matching appointment to the collection station truck queue system. In addition, the reservation system will send the announcement to the truck driver via text and/or email messages to inform the truck driver of the appointment status. Reservation status result At least one of the following 4321 is included: an active appointment that results in a call forwarding announcement indicating that the driver continues to advance to the gate, or a receipt of a pending appointment or no appointment announcement 4319 in which the driver must contact the dispatch for assistance. Once the dispatcher corrects the appointment 4323, the updated reservation status will be available to the driver via a wall mounted display or via text/email message reception 4321.

44 illustrates an exemplary block diagram of an OCR inlet and entry gate bracket consistent with one or more aspects of the innovations herein. The truck arrives at the OCR entrance and the container and chassis numbers are read 4401. The gate system requests a target reservation 4403 from the reservation system. The RFID truck data and OCR equipment are transmitted to the VT acquisition target reservation API 4405. The API returns the target subscription data as summarized in FIG.

At the entry gate, the reservation device is matched 4415 with the device data previously retrieved from the OCR device data or manually entered by the gate administrator via the carriage camera 4413. If the device data from the appointment does not match the receiving device, the truck is requested to exit the terminal 4417, or the truck can continue to enter the terminal 4409.

Figure 46 In some implementations, the Get Target Appointment API is provided to utilize all available information from the terminal truck queuing system and portal (UTN/RFID tag number, OCR device number) to find the best or target appointment match. This routine returns the target reservation ID, the type of movement, the status, and the equipment defined as the target reservation for the portion of the planned inbound and/or outbound movement. This information can be used by the gate operation to verify that the intended equipment is matched to the actual equipment (container and/or chassis number) that arrives at the gate bracket or exits the gate bracket. And device size/type). This information simplifies the gate operation by ensuring that the pre-arrival equipment is in good condition before entering the collection and distribution station, and facilitates automatic gate operation when the expected equipment data and actual equipment data match.

To find a target appointment, a series of matching methods can be performed until a good target appointment match is found. Once a good result is found, there is no need to perform other matching methods. These matching methods are a list of the order in which the routine will attempt to find the best target reservation. (That is, starting with Method 1, if no appointment is found, then continue with methods 2, 3, and 4 as needed). The match will return the only time when no results are found by the appointment. If each of the following methods fails to return the result. A set of exemplary but non-limiting matching methods are described below.

According to the first exemplary matching process, the UTN has a start appointment or a single out appointment in the dock holding area (IYHA). The first method may include a plurality of parameters including arrival date/time, RFID/UTN (unique truck number), location, start indicator, first container, second container, chassis number, and chassis LPN (license number), where the arrival The date/time corresponds to the use of a truck arrival date that only matches appointments with the same date. The RFID/UTN corresponds to the UTN or RFID number from the truck profile to find the UTN if the (configurable) truck profile is provided, the location corresponds to the acquisition target. The current position of the truck at the time of the reservation request, the start indicator corresponds to Yes, the first container corresponds to the unused first container, the second container corresponds to the unused second container, the chassis number corresponds to the unused, and the chassis LPN ( The license plate number corresponds to unused.

The first matching process can include two parts including a single out appointment and a start appointment. For the first part 4611, check a single appointment, where Only when the position is IYHA, the best time slot or candidate activity or pending single out movement matching the same date and UTN specified in the parameter is returned. If the UTN is already on the collection station and its previous pickup movement is cancelled, then this method is utilized to assign the pickup movement to the UTN. Once the truck is in the terminal of the terminal, the appointment is initiated. The second portion 4612 of the method queries all start appointments that match the specified date and UTN. If the activation appointment is not found, the second and third matching methods are continued until a start appointment is found. This extra step is required for a single access truck that does not have a UTN.

The following cases illustrate possible situations related to the first matching method. For example, when the truck enters the gate carrier, the gate system will query the reservation system for all activation appointments of the gate system for status processing to completion or cancellation based on the TOS transaction status. If the driver is directed to IYHA due to a trouble ticket, the method will return to the method's activation appointment for fault handling within the gate system and TOS system. For the assignment of a new single appointment in the case of double movement at the gate, where the incoming movement is active and the out movement is pending and must be cancelled by the administrator at the pre-gate bracket via the TOS. The gate system will send an exit reservation for cancellation to the reservation system, wherein the reservation system will cancel the pairing and cancel the start of the move reservation. Instruct the driver to go to IYHA to get the driver's new move instruction. From IYHA, if the UTN requests a new appointment, the dispatcher must have created the appointment as a slot candidate single out appointment that was assigned to the same UTN for the first matching method to find the appointment. In the unlikely event that if there are multiple single out reservations for the same date and the same UTN, the time slot logic will determine the best appointment.

According to a second exemplary matching process, the container device is provided by a gate system. The second method may include a plurality of parameters including arrival date/time, RFID/UTN, location, start indicator, first container, second container, chassis number, and chassis LPN (license number), where the arrival date/time corresponds To utilize a truck arrival date that only matches appointments with the same date, the RFID/UTN corresponds to the UTN or RFID number used to find the UTN from the truck profile if the (selective) truck profile is provided, the location corresponds to the target acquisition The current position of the truck at the time of the request, wherein if the activation indicator corresponds to YES, the activation reservation is included, and if not, the activation reservation is excluded, the first container corresponds to the required first container, and the second container corresponds to the selective The second container is used if available, the chassis number corresponds to unused, and the chassis LPN (license number) corresponds to unused.

The second matching process is performed only when the gate system sends a good OCR reading or the gatekeeper enters the container number. The container number is the most important device match, so once an appointment matching the same container is found, the result is returned and the matching process stops. If the UTN is specified, the UTN must match the appointment to qualify for the target appointment. In the unlikely event that if multiple appointments for the same container are found, the time slot logic will narrow the time slot logic to the most recent appointment for that UTN.

If the activation indicator is 4621 for all activation candidates and slot reservations, the date and other available device data (such as RFID/UTN and container number) are used to initiate a reservation reservation system for matching the specified device profile. If the UTN is specified, the UTN must match the appointment to qualify for the target appointment. On the other hand, if the start indicator is no 4622, Then, for the activity/pending (single entry, double entry) search reservation system, if the UTN is specified, the UTN must match the reservation to obtain the target appointment qualification. For tie breakers, find more than one appointment using the same container number specified, or 2-20 through OCR to match two different target appointments (ie, one container matches one appointment and another container number Matching another), the time slot logic will be utilized to further reduce the result set. For the final key factor, the earliest subscription ID is used, assuming that the primary device subscription for the multi-device subscription will be entered first.

The following cases illustrate possible situations related to the second matching method. For the entry gate, when the truck enters the gate bracket, the gate system will reserve an inquiry reservation system for all targets of the activity and pending, for the gate processing to utilize all available (either via OCR data or input by the administrator) Equipment information. Here, the start indicator is no. For an IYHA failure, a visit to the driver (ie, the truck has no UTN number but a container number) is directed to IYHA due to a TOS transaction in the dock. Here, the startup indicator is yes. This method will use the container information entered by the clerks to initiate a reservation inquiry to search for the reservation system. For IYHA OOG (super-standard) entry gates, OOG cargo cannot be processed through the gate entry, and the cargo is routed to IYHA for use in the gate processing with equipment data manually entered by the administrator. Here, the start indicator is no.

According to a third exemplary matching process, the chassis device is provided by a gate system. The third method may include a plurality of parameters including arrival date/time, RFID/UTN, location, start indicator, first container, second container, chassis number, and chassis LPN (license number), where the arrival date/time corresponds To utilize a truck arrival date that only matches appointments with the same date, the RFID/UTN corresponds to the UNT or RFID number used to find the UTN from the truck profile if the (selective) truck profile is provided, the location corresponding to the target acquisition The current location of the truck at the time of the request, wherein if the activation indicator corresponds to yes, only the activation appointment is included, and if not, the activation appointment is excluded, wherein the first container and the second container are optional and unused, the chassis number If it is available, it is used, and the chassis LPN (license plate number) is used if it is available.

In some implementations, the third matching method can include the following steps. If the activation indicator is yes for all activation candidates and slot reservations, the activation reservation search reservation system 4631 for matching the specified device data is utilized using the date and other available device data, RFID/UTN and chassis number. If UTN is specified, the UTN must be utilized in the match. If no appointment is found, the chassis number is used, and if the chassis flag is 4632, then the chassis LPN is attempted to find the start target reservation. If the chassis flag is no, the LPN is not used in the match. If the activation indicator is no 4633, the date and other available device data are used to make the RFID/UTN and chassis number only for active or pending primary candidates and slot reservation search reservation systems. If UTN is specified, the UTN must be utilized in the match. If the chassis flag is no. 4634, only single ingress and double in movement (no movement) are utilized. If the chassis flag is YES and the container data is not provided by the gate system, single entry, double entry and single exit movement are utilized. If the chassis flag is yes and the container data is provided by the gate system, single entry and double entry (no movement) are utilized.

If the appointment is not found using the chassis number, if the chassis flag is yes and the container information is not provided by the gate system, then the chassis LPN is used to find active or pending major candidates for a single entry, single exit or double entry target appointment. Slot reservation 4635. If the chassis flag is yes and the container data is provided by the gate system, single entry and double entry (no movement) are utilized. If the chassis flag is no, the LPN match is not used. As for the key factors, if more than one appointment is found using the same chassis/LPN specified, the time slot logic will be utilized to further reduce the result set. For the final deciding game, the earliest reservation ID is used, assuming that the primary device pre-admission for multi-device reservations will be entered first. If there is no match result, the fourth matching method is continued.

This method is only executed if the above container match does not return a result and the gate system sends a good OCR reading or the gate manager enters the chassis/LPN data. When multiple appointments are found that match the same chassis/LPN, then the time slot logic will narrow the time slot to the most recent appointment.

The following cases illustrate possible situations related to the third matching method. For example, when the truck enters the gate bay, the gate system will query the reservation system for all target activities and pending appointments of the reservation system for the gate processing to utilize all available (or via OCR or administrator input) devices. data. Here, the start indicator is no.

When a visit to the truck (ie, the truck has no UTN number) enters the gate bracket, the gate system will send chassis equipment information (either via OCR data or by the administrator) to query the reservation system for all activation appointments of the reservation system. For processing based on TOS truck transaction status status to completion or cancellation. Here, the startup indicator is yes.

If a visit to the driver (ie, the truck has no UTN number) is routed to IYHA due to the ticket, this method will use the chassis information entered by the administrator to initiate a reservation inquiry for the method for use in the gate system and Fault handling within the TOS system. Here, the startup indicator is yes.

According to a fourth exemplary matching process, the RFID/UTN is provided by the gate system and no other device data is provided by the gate system. Only UTN and date/time 4640 are utilized in the truncation method. The fourth matching method can be performed when all of the previous methods 1-3 have not yet returned the reservation result.

The fourth process may include a plurality of parameters including arrival date/time, RFID/UTN, location, start indicator, first container, second container, chassis number, and chassis LPN (license number), where the arrival date/time corresponds In the case of utilizing a truck arrival date that only matches appointments having the same date, the RFID/UTN corresponds to finding the UTN from the truck profile using the UNT or RFID number if the (configurable) truck profile is provided, the location corresponding to when the target reservation request is obtained The current position of the truck, the start indicator corresponds to no. The first container, the second container, the chassis number and the chassis LPN (license number) are not used and should be blank.

The fourth matching process can include the following steps. With the RFID/UTN number and arrival date and time search, only the activity and pending single truncated appointments will be searched in the reservation system. As for the key factors, if more than one appointment is found using the same UTN truncation specified, the time slot logic will be utilized to further reduce the result set. For the final key factor, the earliest reservation ID is used, assuming that the primary device subscription for multi-device reservations will be entered first. If there is no match result, the fourth matching method is continued.

The following cases illustrate possible situations related to the fourth matching method. For example, for call forwarding, all conditions known to the gate system when the truck enters the terminal are RFID/UTN. Here, the start indicator is no. For the gate, all cases are known, and the truncation is RFID/UTN. Here, the start indicator is no.

According to the fifth exemplary matching process, the RFID/UTN is provided by the gate system, but no other device data requirements are utilized in this matching algorithm. Only UTN and date/time 4650 are required in the time slot logic method. The fifth matching method can be performed when all of the previous methods 1-4 have not yet returned the appointment result.

The fifth process may include a plurality of parameters including arrival date/time, RFID/UTN, location, start indicator, first container, second container, chassis number, and chassis LPN (license number), where the arrival date/time corresponds In the case of utilizing a truck arrival date that only matches appointments having the same date, the RFID/UTN corresponds to finding the UTN from the truck profile using the UNT or RFID number if the (configurable) truck profile is provided, the location corresponding to when the target reservation request is obtained The current position of the truck, the start indicator corresponds to no. Selectively do not use the first container, the second container, the chassis number and the chassis LPN (license number).

The fifth matching process can include the following steps. Including the RFID/UTN number and arrival date and time, only the activity including the single in, single out, double inbound movement and the pending main moving candidate and the slot reservation are searched using the time slot logic described below. If you use time slot logic to find more than one appointment, the final key factor will be the earliest reservation ID, assuming multiple device pre- The appointment of the main equipment will be entered first by the dispatcher. If no reservation is returned after using this last method, the message without reservation is returned to the gate system. This method is only performed when the above method finds no match or no device data is available, such as during initial call forwarding, when UTN and date-time are known.

In some implementations, the first matching method may be first and if unsuccessful, move to the order or priority of methods 2, 3, 4, etc. for time slot matching.

Figure 45 illustrates an exemplary graph of a time slot situation consistent with one or more aspects of the innovations herein. The first step will look at whether the appointment exists for the UTN in the exact time slot. If no appointment is found, the next step will check for the arrival of the UTN reservation in the time slot window. The time slot window is greater than or equal to the time slot of the time slot start time of -30 minutes (the parameterized value is the wind pressure difference (30) in the set limit) or less than or equal to the time slot end time + 30 minutes (in the set limit) The definition of the arrival time of the parameterized value wind pressure difference (30)). The third step checks the candidate reservation to check if a candidate appointment exists for the UTN and date. The next step will check for the most recent time slot that is earlier or later than the UTN arrival time. The earlier slot deviation is calculated by subtracting the slot end time of the earlier reservation from the arrival time. If there is no earlier appointment on the day, the earlier slot deviation is set to 1440. The later slot deviation is calculated by subtracting the arrival time from the slot start time of the later appointment. If there is no late appointment on the day, the slot deviation will be set to 1440 at a later time. From the above calculations (early groove deviation and later slot deviation), it is determined by which the time slot deviation value is the lesser of the two time slot deviations to determine which reservation is closer to the UTN arrival time. If two If the time slot deviations are equal, an earlier appointment is obtained.

The following cases illustrate possible situations related to the fifth matching method. Any UTN without reservation is returned in the previous process 1-4.

47A-47U are diagrams of exemplary reservation system mobile application user interfaces consistent with one or more aspects of the innovations herein, the subscription system mobile application user interface including a landing page (FIG. 47A) , the landing page landing page (Fig. 47B), menu (Fig. 47C), login (Fig. 47D), gate inquiry (Fig. 47E to Fig. 47F), import inquiry (Fig. 47G to Fig. 47H), reservation (Fig. 47I to Fig. 47P) , daily message (Fig. 47Q), location of the collection and distribution station (Fig. 47R to Fig. 47S), contact person (Fig. 47T), and related (Fig. 47U).

The Voyager Tracking Appointment System Mobile App is an action web page integrated into the Appointment System and the Terminal System (TOS), which provides users with easy access to information via any mobile browser such as a smart phone or tablet device. Ability.

The mobile app provides system users with the ability to create/update/delete appointments from mobile devices from virtually anywhere, at any time and before actually arriving at the terminal. The application can also provide basic terminal information/rules/consultation, location/direction of the terminal, equipment availability and inventory summary, EIR observation and container inventory screen.

The TOS mobile application processing via the reservation system can help reduce congestion at the gate and simplify gate transactions by reducing the occurrence of gate failures.

In various implementations as described herein, the various GUIs provided by the mobile interface are comprised of one or more servers, meters that can be TOS agnostic systems The computing device and/or computer readable medium transmits and processes. The actions performed by the system are provided to a mobile interface or any computing interface.

In some implementations of the invention, the system includes one or more servers, computing devices, and/or computer readable medium processing instructions executable by one or more processors for management Reservation system and / or collection station operating system. The instructions include instructions for processing information for display on a mobile device from a reservation system for a collection and delivery station operating system, the information including first information, the first information including action input reservation information. A action interface is provided for receiving user input associated with the subscription functionality. The one or more processing devices process information related to user input received via the mobile interface to manage the subscription functionality, and the processor processes to generate an output and/or result, the output and/or result being associated with: Processing and/or transmitting instructions within the reservation system, processing and/or transmitting instructions to a computing device external to the reservation system, or a combination of the two; performing reservation functionality via the reservation system such that the managed subscription functionality is generated Output of the results and/or processed information; and/or processing, transmitting and/or performing a combination of functions involving output and/or results.

Moreover, in certain implementations, the technical innovations herein may include or involve a collection station operating system (TOS) agnostic process. User input may include an order to establish an import container appointment, modify an import container reservation, search for an import container reservation, delete an import container reservation, observe an import container reservation, or a combination of the above. Outputs may include established import container reservations, modified import container reservations, search results including import container reservations, deletion of import container reservations, display of imported container reservations, or A combination of the various. Appointment functionality may include login page functionality, distribution site login page functionality, menu functionality, login page functionality, gate query functionality, import query functionality, subscription query functionality, appointment detail functionality, appointment modification functionality , reservation deletion function, reservation setting function, reservation status function, message function, position function, direction function, contact function, general information function, or a combination of the above. The resulting output and/or results provide reduced operating costs, improved throughput, better equipment utilization, or a combination of the above, from improved gate efficiency.

Figure 47A illustrates an exemplary mobile application landing page GUI consistent with one or more aspects of the innovations herein. For example, the action landing page can be linked to an action website URL associated with an active dock site defined in the reservation system. From this landing page, the user can enter/search/select the 4700A specific distribution station. Once entered, the GUI will redirect the user and display the action website page for that particular collection station, as illustrated in Figure 47B.

Figure 47B illustrates an exemplary mobile application collection site landing page GUI consistent with one or more aspects of the innovations herein. The GUI of Figure 47B illustrates an individual mobile website URL page 4700B for a particular collection and distribution station. The website of the distribution station website can represent the website network of the combination of the collection and distribution stations, depending on the user's login access rights. Other available options from the landing page are that the user can select a specific function widget, which prompts the user to identify the collection station and display the data related to the collection and distribution station. The information will be retrieved from the reservation system.

Figure 47C illustrates one or more aspects of the technical innovations herein An exemplary action application menu GUI. The side menu 4700C provides the user with another means to open the mobile web application. In addition to the interactive function links, there will be additional links to the user for information such as about us, logout, etc. that are not listed on the main function page.

Figure 47D illustrates an exemplary mobile application login GUI consistent with one or more aspects of the innovations herein. Access to certain features will require user login. When the login page 4700D appears, the user will be asked to enter a username and password. Once entered, the username and password can be verified against the appointment system login security data. After the system verification of the login, the user can access all mobile application security functions via the reservation system.

47E-47F are diagrams of exemplary mobile application gate query GUIs consistent with one or more aspects of the innovations herein. The gate interrogation functionality as illustrated in Figure 47G will provide the user with the ability to explore EIR for a container or chassis. Because this feature is a security feature, the user will be required to log in first before searching for the EIR associated with the EIR data that the user can use. The GUI 4700F illustrated in Figure 47F displays the results of the EIR search and may include information associated with the container number, container size, movement type, SSCO, etc. from the reservation system gate activity page.

47G-47H are diagrams of an exemplary mobile application import query GUI consistent with one or more aspects of the innovations herein. Users can use the import enquiry to search for 4700G to check the availability status of the imported containers by entering relevant search information. GUI 4700H shown in Figure 47H The results of the import search are displayed, and may include information associated with the container number, container size, location, SSCO, etc. from the import system report page of the reservation system.

47I-47P are diagrams of exemplary mobile application subscription GUIs consistent with one or more aspects of the innovations herein. Figure 47I is an exemplary appointment inquiry page in which a user can enter search parameters at 4700I and/or select a reservation movement type, such as from a drop down menu, which may include, for example, an empty container, a full shipping cabinet (import), vacated Options for containers, full containers (exports), ordering numbers, release numbers, bare bottom plates, bare bottom plates, imported pallets, exit pallets, bills of lading, etc. Because this may involve security functions and functionality, all users will be required to log in first before searching for a 4700I device appointment to determine the appointment status and then making, modifying, or deleting an appointment associated with the reservation system material that the user can use. Figure 47J is an exemplary appointment detail page 4700J showing appointment details including container details and availability from the reservation system import report page. Appointment actions and settings can also be selected to allow the user to make, modify or delete an appointment for the final appointment verification. Figure 47K is an exemplary make-up page that includes a reservation action 4700K that the user can select to make a reservation. Figure 47L is an exemplary modified subscription page that includes a reservation action 4700L that the user can select to modify the appointment. Figure 47M is an exemplary deletion appointment that includes a reservation action 4700M that the user can select to delete the appointment. FIG. 47N is an exemplary appointment setting page including a reservation action 4700N in which the user can set an appointment detail including a time slot, a truck driver code, a date, and the like. To submit an appointment for final appointment verification for making, modifying, or deleting an appointment, an action can be displayed to show Indicates the appointment details 4700N that have been made, modified or deleted. Figure 47O is an exemplary appointment result page including a reservation status 4700O confirming the making of a reservation action. Figure 47P is an exemplary appointment result including a reservation status 4700P confirming the deletion of the reservation action.

Figure 47Q illustrates an exemplary mobile application message GUI consistent with one or more aspects of the innovations herein. The daily message announcement 4700Q can be obtained directly from the daily message page of the reservation system. The content will vary depending on the requirements of each distribution station and may include messages associated with today's priority messages, today's messages and truck driver information.

47R-47S are diagrams of exemplary mobile application distribution station location GUIs consistent with one or more aspects of the innovations herein. The location of the terminal can be displayed on the map 4700R. For example, a link to the third party map 4700R can be provided and the user is allowed to request a route direction from the location of the user to the collection station. The map 4700S illustrated in Fig. 47S1 further includes the illustrated directions. The GUI can also display the writing direction 4710S as shown in Fig. 47S2.

Figure 47T illustrates an exemplary mobile application contact GUI in accordance with one or more aspects of the innovations herein. The contact page can include contact information 4700T, such as a mailing address and related phone number.

Figure 47U illustrates an exemplary mobile application with respect to one or more aspects of the innovations herein. The About Us page can include general information about the 4700U for a collection station or any number of terminals.

The technical innovations herein may be implemented by one or more components, systems, servers, electrical devices, other sub-components, or dispersed among such components between. When implemented as a system, the system may include, inter alia, software modules such as those found in general purpose computers, general purpose CPUs, RAMs, etc., and/or components of FPGAs and/or ASICs found in more specialized computing devices. In an implementation in which a technological innovation exists on a server, the server may include or involve components such as a CPU, RAM, etc., such as components found in a general purpose computer.

Additionally, the technical innovations herein may be achieved via implementations having software or hardware components other than those described above. With respect to such other components (eg, software, processing components, etc.) and/or computer readable media associated with or embodying the present invention, for example, aspects of the innovations herein may be associated with many general purpose or special purpose computing systems or groups. The state is implemented consistently. Various exemplary computing systems, environments, and/or configurations that may be suitable for use with the subject innovations herein may include, but are not limited to, software or other components, such as wiring/connections, in a personal computer or embodied on a personal computer. Server or server computing device for portable components, portable or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, consumer electronics, network PCs, other existing computer platforms A distributed computing environment, including one or more of the above systems or devices.

In some cases, aspects of the innovations herein may be made via or via logic and/or logic instructions, including, for example, with such components or circuits. A program module that is executed in association with it. In general, a program module can include routines, programs, objects, groups that perform specific tasks or implement specific instructions herein. Pieces, data structures, etc. The invention can also be practiced in the context of a distributed software, computer or circuit environment in which the circuits are connected via a communication bus, circuit or link. In a decentralized environment, control/instructions may occur from both the regional computer storage media including the memory storage device and the remote computer storage media.

Innovative software, circuits, and components herein may also include and/or utilize one or more types of computer readable media. Computer readable media can be any available media that can be found on, or inaccessible to, such circuitry and/or computing components. Computer-readable media can include computer storage media and other media by way of example and not limitation. However, computer readable media herein does not cover/include temporary media. Computer storage media includes both power-based and non-electrical, removable and non-removable media implemented by any method or technology for use in information such as computer readable instructions, data structures, program modules or other materials. Store. Computer storage media includes (but is not limited to) RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, tape, disk storage or other A magnetic storage device, or any other medium that can be used to store the desired information and that can be accessed by the computing component. The communication media may contain computer readable instructions, data structures, program modules or other materials that are functional in this non-transitory format. In addition, the communication medium may include tangibly embodied wired media, such as a wired network or a direct wired connection. Combinations of any of the above are also included within the scope of computer readable media.

In this description, the terms component, module, device, etc. may relate to Any type of logical or functional software component, circuit, block, and/or process implemented in various ways. For example, the functions of the various circuits and/or blocks can be combined with each other into any other number of modules. Each module can even be implemented as a software program stored in a tangible memory (eg, random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be centrally The processing unit reads to perform the functions of the innovations of this document. Alternatively, the module can include programming instructions that are transmitted to a general purpose computer via a transfer or to a processing/graphics hardware. In addition, the modules can be implemented as hardware logic circuits that perform the functions encompassed by the innovations herein. Finally, the modules can be implemented using dedicated instructions (SIMD instructions), on-site programmable logic arrays, or a mixture of the above or other suitable components that provide the desired level of performance and cost.

As disclosed herein, functions consistent with the present invention can be implemented via computer hardware, software, and/or firmware. For example, the systems and methods disclosed herein can be embodied in a variety of forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or a combination of the above, in addition to the disclosed embodiments. Some describe specific hardware components, but systems and methods consistent with the innovations herein can be implemented using any combination of hardware, software, and/or firmware. In addition, the above-described functions and other aspects and principles of the technical innovations herein may be implemented in various environments. Such environments and related applications may be specially constructed for performing various routines, processes, and/or operations in accordance with the present invention, or such environments and related applications may include selectively activated or reassembled by code A general purpose computer or computing platform that provides the necessary functionality. Revealed in this article The process is not inherently related to any particular computer, network, architecture, environment, or other instrument and may be implemented by a suitable combination of hardware, software, and/or firmware. For example, various general purpose machines may be used with programs written in accordance with the teachings of the present invention, or it may be more convenient to construct specialized instruments or systems to perform the required methods and techniques.

The methods and system aspects (such as logic) described herein can also be implemented as functionality in programming to any of a variety of circuits, including programmable logic devices ("PLDs"), such as on-site programmable Gate array ("FPGA"), programmable array logic ("PAL") devices, electrical programmable logic and memory devices, and standard cell-based devices, as well as application-specific integrated circuits. Some other possibilities for implementing the aspect include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, and the like. In addition, aspects can be embodied in microprocessors that have software-based circuit emulation, discrete logic (continuous and combined), custom devices, fuzzy (like-like) logic, quantum devices, and A mixture of any of the above types of devices. The underlying device technology can be provided in a variety of component types, such as metal oxide semiconductor field effect transistor ("MOSFET") technologies such as complementary metal oxide semiconductors ("CMOS"), such as emitter-coupled logic ("ECL"). ") Bipolar technology, polymer technology (for example, ruthenium-conjugated polymers and metal-conjugated polymers - metal structures), mixed analogies and digits, and the like.

It should also be noted that the various logic and/or functions disclosed herein can be enabled using any combination of hardware and firmware, and/or Logic and/or functional behavior, register transfer, logic components, and/or other features are enabled as data and/or instructions embodied in various machine readable or computer readable media. Computer readable media, which may be embodied in such formatted data and/or instructions, include, but are not limited to, non-electrical storage media (eg, optical, magnetic or semiconductor storage media) in various forms, yet The media does not cover/include temporary media.

Unless the context clearly requires otherwise, the phrase "comprising" or the like is to be interpreted in the sense of the contrary to the exclusive or exhaustive meaning; that is, in the sense of "including but not limited to". Words using singular or plural also include plural or singular, respectively. In addition, the words "herein", "hereafter", "above", "below" and the like are intended to refer to this application as a whole and do not relate to any particular part of the application. When the word "or" is used in relation to two or two lists of items, the word covers all of the following interpretations of the word: any item in the item in the list, all items in the item in the list and Any combination of items in the list.

Although certain preferred embodiments of the present invention have been described in detail herein, it will be apparent to those skilled in the <RTIgt; Implement changes and modifications to the program. Therefore, it is intended that the invention be limited only to the extent required by applicable legal rules.

204‧‧‧User input/user

214‧‧‧ expression layer, expression/application layer

216‧‧‧WCF (Windows Communication Foundation) Service

220‧‧‧Business Logic/Commercial Layer

222‧‧‧Service/Service Layer/Service Limits

226‧‧‧Repository

250‧‧‧Data access/data access layer

Claims (285)

A computer-implemented method for processing information, the information relating to a reservation system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface including reservation functionality and An input field for receiving a user input, the information includes first information, the first information includes reservation information, and processing information related to the user input received through the interface to manage the reservation function; And processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the reservation system, processing and/or transmitting instructions to the outside of the reservation system a computing device, or a combination of the two; the subscription functionality is performed via the reservation system such that one of the results of the managed subscription functionality and/or one of the processed information is output; and/or processing Transmitting, and/or performing a combination of functions related to the output and/or result. The method of claim 1, wherein the user input comprises a command for establishing an import container reservation, modifying an import container reservation, searching for an import container reservation, deleting an import container reservation, observing one Import container reservations, or a combination of each of the above. A method of claim 1, request 2, or any of the claims herein, wherein The output includes an established import container reservation, a modified import container reservation, a search result including an import container reservation, one of the import container reservation deletions, one of the import container reservations, or a combination of the above. The method of claim 1, wherein the user input includes a command for establishing an export subscription reservation, modifying an export subscription reservation, searching for an export subscription reservation, and deleting an export subscription. Make an appointment, observe an export booking reservation, or a combination of the above. The method of claim 1, claim 4 or any of the claims herein, wherein the output comprises an established export subscription reservation, a modified export subscription reservation, a search result including an export subscription reservation, and an export order One of the reservation reservations, one of the export reservation reservations, or a combination of the above. The method of claim 1, wherein the user input includes a command for establishing an empty container appointment, modifying an empty container appointment, searching for an empty container reservation, deleting an empty container reservation, and observing An empty into the container reservation, or a combination of the above. The method of claim 1, claim 6, or any of the claims herein, wherein the output comprises an established empty container reservation, a modified empty container reservation, a search result including an empty container reservation, and an empty container reservation One of the deletions, one of the empty into the container reservations, or one of the above. The method of claim 1 or any of the claims herein, wherein the user input includes a command for establishing an appointment report, modifying a pre- A report, a search appointment report, an appointment report, an appointment report, or a combination of the above. The method of claim 1, claim 8, or any of the claims herein, wherein the output comprises an established appointment report, a modified reservation report, a search result including a reservation report, one of the reservation reports deleted, and an appointment One of the reports shows, or a combination of each of the above. The method of claim 1, wherein the user input includes a command for establishing a reservation limit setting, modifying a reservation limit setting, searching for a reservation limit setting, deleting a reservation limit setting, observing a Reservation limit settings, or a combination of each of the above. The method of claim 1, wherein the output includes an established reservation limit setting, a modified reservation limit setting, a search result including a reservation limit setting, a reservation limit setting deletion, and an appointment. One of the limit settings is displayed, or a combination of one of the above. The method of claim 10, claim 11, or any of the claims herein, wherein the reservation limit setting comprises a gate operation time, a time slot, a reservation limit for a collection station, or a combination of the foregoing. A method of claim 10, claim 11, or any of the claims herein, further comprising generating and storing one of the subscription limit settings templates. The method of claim 1, further comprising displaying the appointment statistics. The method of claim 1, wherein the user input includes a command for establishing an appointment restriction report, modifying an appointment restriction report, searching for an appointment restriction report, deleting an appointment restriction report, observing a An appointment limit report, or a combination of each of the above. The method of claim 1, claim 15 or any of the claims herein, wherein the output comprises an established reservation restriction report, a modified reservation restriction report, a search result including an appointment restriction report, and an appointment restriction report Delete, one of the appointment limit reports, or a combination of the above. The method of claim 1, wherein the user input includes a command for establishing a reservation configuration for a collection station, modifying a reservation configuration for a collection station, searching A reservation configuration for a collection station, deletion of a reservation configuration for a collection station, observation of a reservation configuration for a collection station, or a combination of the above. A method of claim 1, claim 17, or any of the claims herein, wherein the output comprises an established reservation configuration for a collection station, a modified reservation configuration for a collection station, including A search result of a reservation configuration of the collection station, deletion of one of the reservation configurations for a collection station, display of one of the reservation configurations for a collection station, or a combination of the above. A method of claim 1 or any of the claims herein, wherein the generated output and/or result provides reduced operating cost, accelerated throughput, preferred device utilization, or a combination of the foregoing, from improved gate efficiency. A computer-implemented method for processing information, the information relating to a payment system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface including payment functionality and An input field for receiving a user input, the information including the first information, the first information including online payment Processing information related to the input received via the interface to manage the payment functionality; and processing to generate an output and/or a result, the output and/or the result being associated with: Processing and/or transmitting instructions within the payment system, processing and/or transmitting instructions to a computing device external to the payment system, or a combination of the two; performing the payment functionality via the payment system such that the Managing one of the results of the payment functionality and/or one of the processed information; and/or processing, transmitting, and/or performing a combination of functions related to the output and/or results. A method of claim 20, or any of the claims herein, wherein the user input comprises a non-deferred payment. A method of claim 20, or any of the claims herein, wherein the output/result includes one of a non-delay fee payment display. A method of claim 20, or any of the claims herein, wherein the user input comprises a deferred payment. A method of claim 20, or any of the claims herein, wherein the output and/or result comprises a display of one of the deferred payment. A computer-implemented method for processing information, the information relating to an announcement system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface Including an announcement function and an input field for receiving a user input, the information includes first information, the first information includes notification information, and processing information related to the user input received through the interface to manage The notification functionality; and processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the notification system, processing and/or transmitting instructions a computing device external to the notification system, or a combination of the two; performing the notification functionality within the system such that one of the results of the managed notification functionality and/or one of the processed information is output And/or processing, transmitting, and/or performing a combination of functions related to the output and/or results. The method of claim 25, wherein the user input includes a command for registering an import availability/hold status, modifying an import availability/hold status, searching for an import availability/hold status, deleting one Import availability/holding status, observation of an import availability/holding status, or a combination of each of the above. The method of claim 26, claim 27, or any of the claims herein, wherein the output includes a registered import availability/hold status, a modified import availability/hold status, a search result including an import availability/hold status, One of the import availability/holding states is deleted, one of the import availability/holding states is displayed, or one of the above is combined. The method of claim 25, wherein the user input includes a command for registering a transit fee release/release reversal notification, modifying a transit fee release/release reversal notification, searching Traffic migration fee release/release reversal notice, deletion of a traffic migration fee release/release reversal notice, observation of a traffic migration fee release/release reversal notice, or a combination of the above. The method of claim 25, claim 28, or any of the claims herein, wherein the output comprises a registered traffic travel cost release/release reversal notice, a modified traffic travel cost release/release reversal notice, including a traffic trip A search result of the fee release/release reversal notice, one of a traffic travel cost release/release reversal notice deletion, one of a traffic migration fee release/release reversal notice, or a combination of the above. The method of claim 25, wherein the user input includes a command for registering a delay fee notice, modifying a delay fee notice, searching for a delay fee notice, and deleting a delay fee. Announce, observe a delay fee notice, or a combination of the above. The method of claim 25, claim 30, or any of the claims herein, wherein the output includes a registered delay fee notice, a modified delay fee notice, a search result including a delay fee notice, and a delay One of the fee notices is deleted, one of the delay fee notices is displayed, or one of the above is combined. The method of claim 25, wherein the user input includes a command for registering a valid announcement, modifying a valid announcement, searching for a valid announcement, and deleting a reservation. Announcement, observation of a binding effective notice, or a combination of the above. The method of claim 25, claim 32, or any of the claims of the present invention, wherein the output comprises a registered effective notice, a modified effective notice, a search result including a valid notice, and a binding One of the valid notices is deleted, one of the posted valid notices is displayed, or one of the above is combined. The method of claim 25, wherein the user input includes a command for registering an exit gate notice, modifying an exit gate notice, searching for an exit gate notice, deleting an exit gate notice, observing a Exit the gate notice, or a combination of each of the above. The method of claim 25, claim 34 or any of the claims herein, wherein the output comprises a registered exit gate notification, a modified exit gate notification, a search result including an exit gate notification, and an exit gate notification Delete, one of the exit gate announcements, or a combination of each of the above. The method of claim 25, wherein the user input includes a command for registering an entry gate notification, modifying an entry gate notification, searching for an entry gate notification, deleting an entry gate notification, observing a Enter the gate notice, or a combination of each of the above. The method of claim 25, claim 36, or any of the claims herein, wherein the output comprises a registered entry gate notification, a modified entry gate notification, a search result including an entry gate notification, and an entry gate notification Delete, one of the entry gate notifications, or a combination of each of the above. The method of claim 25, wherein the user input includes a command for registering a suspension notice, modifying a suspension notice, searching for a suspension notice, deleting a suspension notice, observing a suspension notice, or One of the above combinations. The method of claim 25, claim 38 or any of the claims herein, wherein the output comprises a registered suspension notice, a modified suspension notice, a search result including a pause notice, a pause notice deletion, a pause One of the notices is displayed, or a combination of one of the above. A computer-implemented method for processing information, the information relating to a reporting system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface including reporting functionality and An input field for receiving a user input, the information includes first information, the first information includes delay fee information; processing information related to the user input received through the interface to manage the report function And processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the reporting system, processing and/or transmitting instructions to the report a computing device external to the system, or a combination of the two; performing the reporting functionality within the system such that one of the results of the managed reporting functionality and/or one of the processed information is output; and Or processing, transmitting and/or performing the output and/or result A combination of features. The method of claim 40, wherein the user input includes a command for establishing a delay fee calculation, modifying a delay fee calculation, searching for a delay fee calculation, and deleting a delay fee. Calculate, observe a delay fee calculation, or a combination of the above. The method of claim 40, claim 41 or any of the claims of the present invention, wherein the output comprises an established delay fee calculation, a modified delay fee calculation, a search result including a delay fee calculation, and a delay. One of the fee calculations is deleted, one of the delay fee calculations is displayed, or one of the above is combined. The method of claim 40, wherein the user input includes a command for establishing a gate activity report, modifying a gate activity report, searching for a gate activity report, deleting a gate activity report, observing a Gate activity report, or a combination of each of the above. The method of claim 40, wherein the output includes a established gate activity report, a modified gate activity report, a search result including a gate activity report, one of the gate activity reports, and one gate. One of the activity reports shows, or a combination of each of the above. The method of claim 43, claim 44, or any of the claims herein, wherein the gate activity report includes a transaction status, a trucking company, a ship line, a shipper/consignee, a container movement type, a chassis The type of movement, a time of movement, a particular container, a particular chassis, a display field, a sort order of one of the display fields, a report type, or a combination of the above. A computer-implemented method for processing information, the information relates to A multi-tracking system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface comprising multi-tracking functionality and an input field for receiving a user input, The information includes first information, the first information includes multiple tracking information; processing information related to the user input received through the interface to manage the multi-tracking functionality; and processing to generate an output and/or a result The output and/or the result is associated with processing and/or transmitting instructions within the multi-tracking system, processing and/or transmitting instructions to a computing device external to the multi-tracking system, or both One combination; performing the multi-tracking functionality within the system such that one of the results of the managed multi-tracking functionality and/or one of the post-processing information is generated; and/or processing, transmitting, and/or performing is involved A combination of output and/or result functionality. The method of claim 46, wherein the user input comprises a command for establishing a ship equipment history, modifying a ship equipment history, searching for a ship equipment history, deleting a ship equipment history, observing a Ship equipment history, or a combination of each of the above. The method of claim 46, claim 47 or any of the claims herein, wherein the output comprises an established ship equipment history, a modified ship equipment history, a search result including a ship equipment history, a ship equipment One of the history is deleted, one of the ship equipment histories is displayed, or one of the above is combined. A computer-implemented method for processing information, the information relating to a pre-installation system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface comprising pre-ampere Functionally and an input field for receiving a user input, the information comprising first information, the first information comprising pre-installation information; processing information received via the interface related to the user input, Managing the pre-installation functionality; and processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the pre-installation system, instructions Processing and/or transmitting to a computing device external to the pre-installation system, or a combination of the two; performing the pre-installation functionality within the system such that one of the results of the managed pre-installation functionality is generated And/or outputting one of the processed information; and/or processing, transmitting and/or performing a combination of functions related to the output and/or result. A computer-implemented method for processing information, the information relating to an administrative management system for a collection station operating system, the method comprising: providing information for displaying an interface to a manager, the interface including administrative functions Sex and a loss to receive a manager's input In the field, the information includes first information, the first information includes administrative information; processing information related to the manager input received through the interface to manage the administrative function; and processing to generate an output And/or a result, the output and/or the result being associated with processing and/or transmitting instructions within the administrative system, processing and/or transmitting the instructions to a computing device external to the administrative system, Or a combination of the two; performing the administrative function within the system such that one of the results of the managed administrative functionality and/or one of the processed information is output; and/or processing, transmitting, and / or perform a combination of functions involving the output and / or results. The method of claim 50, wherein the manager input includes a command for establishing a reservation limit setting, modifying a reservation limit setting, searching for a reservation limit setting, deleting a reservation limit setting, observing a Reservation limit settings, or a combination of each of the above. The method of claim 5, wherein the output includes an established reservation limit setting, a modified reservation limit setting, a search result including a reservation limit setting, a reservation limit setting deletion, and an appointment. One of the limit settings is displayed, or a combination of one of the above. The method of claim 51, claim 52 or any of the claims herein, wherein the reservation limit setting comprises a gate operation time, a time slot, and a An appointment limit for the collection station, or a combination of one of the above. A method of requesting item 51, requesting item 52, or any of the claims herein, further comprising generating and storing one of the template of the reservation limit setting. The method of claim 50 or any of the claims herein, further comprising displaying the appointment statistics. The method of claim 50, or any of the claims of the present invention, wherein the manager input includes a command for establishing an appointment restriction report, modifying an appointment restriction report, searching for an appointment restriction report, deleting an appointment restriction report, observing a An appointment limit report, or a combination of each of the above. The method of claim 50, claim 56 or any of the claims herein, wherein the output comprises an established reservation limit report, a modified reservation limit report, a search result including a reservation limit report, and an appointment restriction report Delete, one of the appointment limit reports, or a combination of the above. The method of claim 50, or any of the claims of the present invention, wherein the manager input includes a command for establishing a reservation configuration for a collection station, modifying a reservation configuration for a collection station, searching A reservation configuration for a collection station, deletion of a reservation configuration for a collection station, observation of a reservation configuration for a collection station, or a combination of the above. A method of claim 50, claim 58 or any of the claims herein, wherein the output comprises an established reservation configuration for a collection station, a modified reservation configuration for a collection station, including a search result of a reservation configuration of the distribution station, deletion of one of the reservation configurations for a collection station, display of one of the reservation configurations for a collection station, or each of the above One of the combinations. The method of claim 50, wherein the administrative information includes an appointment administration information, a user account administration information, a system site setting information, a company configuration information, or a combination of the foregoing. The method of claim 60, or any of the claims herein, wherein the company configuration information comprises a shipping company configuration information, a trucking company configuration information, or a combination of the foregoing. The method of claim 50, wherein the administrator input includes a command for establishing a user profile, modifying a user profile, searching for a user profile, deleting a user setting. File, observe a user profile, or a combination of each of the above. The method of claim 50, claim 62 or any of the claims herein, wherein the output comprises an established user profile, a modified user profile, a search result including a user profile, a user One of the profiles is deleted, one of the user profiles is displayed, or one of the above is combined. The method of claim 50, wherein the administrator input includes a command for establishing a user license, modifying a user license, searching for a user license, deleting a user license, observing a User license, or a combination of each of the above. The method of claim 50, claim 64, or any of the claims herein, wherein the output comprises an established user license, a modified user license, a search result including a user license, and a user license One deletion, one of the user licenses, or a combination of the above. The method of claim 50 or any of the claims herein, wherein the manager input includes a command for establishing a truck shipping company insurance timeout/status invalid, modifying a truck shipping company insurance timeout/status invalid, searching Trucking company insurance timeout/status invalid, deletion of a trucking company insurance timeout/status invalid, observing a trucking company insurance timeout/status invalid, or a combination of the above. A method of claim 50, claim 66, or any of the claims herein, wherein the output comprises an established truck shipping company insurance timeout/status invalid, a modified truck shipping company insurance timeout/status invalid, including a truck freight One search result of company insurance timeout/status invalidation, one of the trucking company insurance timeout/state invalidation deletion, one of the trucking company insurance timeout/state invalidation, or a combination of the above. The method of claim 50, wherein the administrator input includes a command for establishing daily message information, modifying daily message information, searching for daily message information, deleting daily message information, and observing Daily message information, or a combination of each of the above. The method of claim 50, claim 68, or any of the claims herein, wherein the output includes one of daily message information, modified daily message information, a search result including daily message information, and one of daily message information. Delete, one of the daily message information displays, or a combination of each of the above. The method of claim 50 or any of the claims herein, wherein the manager input includes a command for establishing import report information, modifying Report information, search for import report information, delete import report information, observe import report information, or a combination of the above. The method of claim 50, claim 70 or any of the claims herein, wherein the output includes an established import report information, a modified import report information, a search result including import report information, one of import report information deletion, and an import report One of the information is displayed, or a combination of one of the above. The method of claim 50 or any of the claims herein, wherein the manager input includes a command for establishing an export report information, modifying an export report information, searching for an exit report information, deleting an export report information, and observing an export report information, Or a combination of one of the above. The method of claim 50, claim 72, or any of the claims herein, wherein the output includes established export report information, modified export report information, a search result including export report information, one of export report information deletion, and an export report One of the information is displayed, or a combination of one of the above. The method of claim 50, wherein the manager input includes a command for establishing import reservation report information, modifying import reservation report information, searching for import reservation report information, deleting import reservation report information, and observing Import reservation report information, or a combination of the above. The method of claim 50, claim 74 or any of the claims herein, wherein the output includes the established import reservation report information, the modified import reservation report information, the search result including the import reservation report information, and the deletion of the import reservation report information. One of the import reservation report information, or a combination of the above. The method of claim 50, or any of the claims of the present invention, wherein the administrator input includes a command for establishing a broadcast communication, modifying a broadcast communication, searching for a broadcast communication, deleting a broadcast communication, observing a broadcast communication, or One of the above combinations. The method of claim 50, claim 76 or any of the claims herein, wherein the output comprises an established broadcast communication, a modified broadcast communication, a search result including a broadcast communication, a deletion of a broadcast communication, a broadcast One of the communications is displayed, or a combination of one of the above. The method of claim 50 or any of the claims of the present invention, wherein the manager input includes a command for establishing gate activity information, modifying gate activity information, searching for gate activity information, deleting gate activity information, and observing gate activity information, Or a combination of one of the above. The method of claim 50, claim 78, or any of the claims herein, wherein the output includes established gate activity information, modified gate activity information, a search result including gate activity information, one of gate activity information deletion, and gate activity One of the information is displayed, or a combination of one of the above. The method of claim 50, wherein the administrator input includes a command for establishing an advertisement check information, modifying an announcement check information, searching for an announcement check information, deleting an announcement check information, and observing an announcement check information. Or a combination of one of the above. The method of claim 50, claim 80, or any of the claims of the present invention, wherein the output includes an established notification check information, a modified notification check information, a search result including the notification check information, one of the notification check information deletion, and an advertisement check. One of the information is displayed, or a combination of one of the above. The method of claim 50, or any of the claims herein, wherein the manager input includes a command for establishing exchange and inspection report information, modifying exchange and inspection report information, searching for exchange and inspection report information, deleting exchanges, and verifying Report information, observation exchange and inspection report information, or a combination of the above. The method of claim 50, claim 82, or any of the claims herein, wherein the output includes an exchange and inspection report information, a modified exchange and inspection report information, a search result including exchange and inspection report information, exchange and inspection One of the report information is deleted, exchanged, and one of the report information is displayed, or a combination of the above. The method of claim 50, wherein the manager input includes a command for establishing gate resolution information, modifying gate resolution information, searching for gate resolution information, deleting gate resolution information, and observing gate resolution information, Or a combination of one of the above. The method of claim 50, claim 84 or any of the claims herein, wherein the output includes established gate resolution information, modified gate resolution information, a search result including gate resolution information, one of gate resolution information deletion, and gate resolution One of the information is displayed, or a combination of one of the above. The method of claim 50, wherein the manager input includes a command for establishing traffic mitigation fee information, modifying traffic mitigation fee information, searching for traffic mitigation fee information, deleting traffic mitigation fee information, and observing Traffic mitigation fee information, or a combination of each of the above. The method of claim 50, claim 86, or any of the claims herein, wherein the output includes established traffic mitigation fee information, modified traffic mitigation fee Information, including a search result of traffic mitigation fee information, deletion of one of traffic mitigation fee information, one of traffic mitigation fee information, or a combination of the above. The method of claim 50 or any of the claims herein, wherein the manager input includes a command for establishing ship schedule information, modifying ship schedule information, searching for ship schedule information, deleting ship schedules Table information, observation of ship schedules, or a combination of the above. The method of claim 50, claim 88, or any of the claims herein, wherein the output includes information on established ship schedules, modified ship schedule information, a search result including ship schedule information, ship schedule One of the table information is deleted, one of the ship schedule information is displayed, or one of the above is combined. The method of claim 50, or any of the claims of the present invention, wherein the manager input includes a command for establishing a hub/ship company action information, modifying a hub/ship company action information, searching for a hub/ship company action Information, delete the movement information of the distribution station/ship company, observe the movement information of the distribution station/ship company, or a combination of the above. The method of claim 50, claim 90, or any of the claims of the present invention, wherein the output includes information about the established dispatching station/ship company action information, the modified dispatching station/ship company action information, and the information of the dispatching station/ship company action information. Search results, deletion of one of the movement information of the terminal/ship company, display of one of the movement information of the terminal/ship company, or a combination of the above. The method of claim 50 or any of the claims herein, wherein the manager loses The input includes a command for establishing website statistics, modifying website statistics, searching for website statistics, deleting website statistics, observing website statistics, or a combination of the above. The method of claim 50, claim 92, or any of the claims herein, wherein the output includes one of the established website statistical information, the modified website statistical information, a search result including the website statistical information, and one of the website statistical information. Delete, one of the website statistics information, or a combination of each of the above. A method of requesting item 1, requesting item 20, requesting item 25, requesting item 40, requesting item 46, requesting item 49, requesting item 50, or any of the claims herein, the method further comprising: processing to be associated with a TOS type A TOS data format data; the data is converted into a TOS agnostic data format to create TOS agnostic data; and processed using the TOS unknown data. The method of claim 94, wherein the processing of the TOS agnostic material comprises: instantiating a first repository instance for a first TOS type; requesting the first data using the first repository instance Accessing a data source for a particular venue; constructing a commercial object using the first data; providing a TOS agnostic output based on the commercial object for processing and displaying to the user via the repository. The method of claim 94, wherein the conversion data comprises: performing a repository process, the performing the repository process comprising: constructing a repository instance corresponding to the TOS data format; processing the received information as The TOS formats the first data; and transmits the first data to the TOS environment. The method of claim 94, wherein the processing of the TOS agnostic material comprises: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. The method of claim 94, wherein the converting comprises: converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 98, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. A method of claim 94 or any of the claims herein, wherein the conversion comprises: Converting, by the transformation, the second container data in a second TOS data format at a second TOS to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and according to a storage A configuration of a shared commercial object/entity/command structure of the library instance; wherein the method further comprises providing the first data and the second data for processing in the TOS agnostic data format via a user interface while The repository will transmit the output in the original data format to the first TOS and the second TOS. The method of claim 96, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. A method of claim 101, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 102, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to implement an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or include a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. Further requesting the method of claim 96 or any of the claims herein Include: use the repository instance to obtain container data; and convert the container data into a TOS agnostic data format to create TOS agnostic container data. The method of claim 104, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving a The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 105, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 104, wherein the converting comprises: converting, by the transformation, the second container data in a second TOS data format at a second TOS into the TOS agnostic data format, the transformation involving Use of one or more repository instances and/or creation and construction of a common commercial object/entity/command structure according to a repository instance; wherein the method further comprises providing the first data and the second material for The TOS agnostic data format is processed via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. The method of claim 96 or any of the claims herein, wherein The TOS type determines that the repository type includes identifying a repository type associated with the TOS type in a repository type cache. The method of claim 108, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 1, request item 20, request item 25, request item 40, request item 46, request item 49, request item 50, or any of the request items herein, the method further comprising: responding to a request for information One of the TOS types corresponding to the collection station operating system retrieval data; constructing a first repository instance for the first TOS type; using the first repository instance to request the first data to access a data for a specific site Source: constructing a first commercial item using the first data; providing a first TOS agnostic output based on the commercial item for processing and displaying to the user via the repository. The method of claim 110 or any of the claims herein, further comprising: instantiating a first repository instance for a first TOS type; and requesting the first profile using the first repository instance for accessing A source of information for a particular site. Further requesting the method of claim 111 or any of the claims herein Including: instantiating a second repository instance for a second TOS type; requesting the second material using the second repository instance to access a data source for a specific site; constructing a second data using the second data a commercial object; providing a second TOS agnostic output based on the second commercial item for processing and displaying to the user via the repository. The method of claim 110, or any of the claims herein, further comprising: receiving a TOS formatted second material in response to the first material; processing the second data as the business object; and the method further comprising receiving the The second data is further processed. A method of claim 110, or any of the claims herein, wherein the TOS environment processes the first data to generate TOS agnostic output data. The method of claim 110 or any of the claims herein, further comprising: receiving the TOS formatted second material in response to the first data; processing the second data; and transmitting the second data to the TOS environment. The method of claim 110 or any of the claims herein, further comprising: converting a second TOS data at a second TOS via transformation The formatted second container data is converted to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object according to a repository instance; wherein the method further comprises Providing the first data and the second data for processing in the TOS agnostic data format via a user interface, and transmitting the output in the original data format to the first TOS and the second TOS via the repository . The method of claim 1, request item 20, request item 25, request item 40, request item 46, request item 49, request item 50, or any of the request items herein, the method further comprising: searching based on a cached venue list The information of the venue of the collection and distribution station; determining, according to the information of the venue of the collection and collection station, the connection operation system of the collection station and the connection information to the site of the collection and distribution station; determining whether an existing repository instance corresponds to the site of the collection and distribution station; determining the site corresponding to the collection and distribution station After one of the storage libraries does not exist, a repository instance is created for the collection station site and the corresponding collection and distribution station operating system; and the repository instance is returned. The method of claim 117, or any of the claims of the present invention, wherein the determining that the collection station operating system comprises determining a relationship between the cache attribute data in the retrieved venue information and a corresponding TOS type. The method of claim 118 or any of the claims herein, wherein the determining The relationship between the cache attribute data and the TOS type includes determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 119, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to perform an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or include a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. The method of claim 117, or any of the claims of the present invention, wherein determining that the collection station operating system comprises identifying a repository type associated with the TOS type in a repository type cache memory, the TOS type being associated with the retrieved collection Station site information is received together. The method of claim 121, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 121, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to implement an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or contain a TOS type attribute of interest and/or The TOS type of interest is named in a sub-namespace. The method of requesting item 1, requesting item 20, requesting item 25, requesting item 40, requesting item 46, requesting item 49, requesting item 50, or any of the claims herein, the method further comprising: receiving information indicative of a first commercial item The first commercial item includes a plurality of commercial properties and associated functions in a collection unit operating system (TOS) agnostic data format; determining a collection station and corresponding TOS based on the received information; performing repository processing, Performing the repository processing includes: constructing or retrieving a repository instance corresponding to the determined collection and distribution station, the TOS: processing the received information into a TOS formatted first material; and transmitting the first data to the determined location Distribution station. The method of claim 124 or any of the claims herein, further comprising: processing via one or more computing devices utilizing a model-view-controller (MVC) design pattern, the processing comprising: receiving and processing The user request associated with the received information; and constructing the response and sending the response to the user concerned with the material transmitted to the determined collection and delivery station. The method of claim 124 or any of the claims herein, wherein: the performing the repository processing further comprises: Receiving a TOS formatted second material in response to the first material; processing the second data as the business object; and the method further comprising processing the business object based on the received second material. The method of claim 124, wherein the performing the repository processing further comprises: receiving the TOS formatted second material in response to the first material; processing the second data as the business object; The second data is transmitted to the determined distribution station data service. A method of claim 124 or any of the claims herein, wherein the information comprises a set of station identifiers and requests. A method of claim 124, or any of the claims herein, wherein each repository instance is coupled to one of a plurality of TOS types associated with the repository instance. The method of claim 1 or any of the claims herein, further comprising: processing data in a TOS format, the TOS data format being associated with a TOS type; converting the data to a TOS agnostic format; and using the TOS Agnostic data is processed. Such as request item 1, request item 130, or any of the methods of the request item herein, The processing includes: instantiating a first repository instance for a first TOS type; requesting the first profile using the first repository instance to access a data source for a specific venue; using the first The data constructs a commercial item; a TOS agnostic output is provided in accordance with the commercial item for processing and display to the user via the repository. The method of claim 1, the request item 130, or any of the claims of the present invention, wherein the conversion data comprises: performing a repository process, the performing the repository process comprising: constructing a repository instance corresponding to the TOS format; The information processing formats the first data for the TOS; and transmits the first data to the TOS environment. The method of claim 1, the request item 130, or any of the request items herein, wherein the processing comprises: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. The method of claim 1, the request item 130, or any of the claims herein, wherein the converting comprises: converting, by the transformation, the first container data in a first TOS format at a first TOS into a TOS agnostic format, The transformation involves the use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. A method of claim 1, claim 130, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 1, the request item 130, or any of the claims of the present invention, wherein the converting comprises: converting, by the transformation, the second container data in a second TOS format at a second TOS into the TOS agnostic format, Transforming a configuration involving the use and/or creation of one or more repository instances and a common commercial object according to a repository instance; wherein the method further comprises providing the first data and the second material for use via a The interface is processed in the TOS agnostic format, while the output in the original format is transmitted to the first TOS and the second TOS via the repository. The method of claim 1, further comprising initializing a repository, the initializing a repository comprising: receiving data including a TOS type; determining a repository type based on the TOS type; instantiating based on the repository type and the TOS type A repository instance. A method of claim 1, claim 137, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. A method of claim 1, claim 137, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining using at least one of a reflection operation, a helper attribute, and/or a convention The relationship. A computer-implemented method for processing information, the method comprising: providing information for displaying an interface to a user, the interface comprising system functionality and an input field for receiving a user input, the information Containing first information in a TOS data format associated with a TOS type; processing information related to the user input received via the interface to manage the functionality of the system, the process comprising converting the data to a TOS The unknowable data format creates a TOS unknowable data by instantiating a data access layer; using the data access layer to request the first data to access a data store; constructing a commercial object using the first data Providing a TOS agnostic output for processing and displaying to the user via the data access layer; and processing the TOS agnostic data to generate an output and/or a result, the output and / or the result is associated with processing and/or transmitting instructions within the system, processing and/or transmitting instructions to a computing device external to the system , or a combination of the two; Performing the system functionality in the system such that one of the results of the managed system functionality and/or one of the processed information is output; and/or processing, transmitting, and/or executing the output and/or results A combination of features. The method of claim 140 or any of the claims herein, wherein: the material access layer comprises a create, read, update, and delete (CRUD) method, transaction management, data parallelism, query function, or a combination of the foregoing And the method further includes processing the information using the data access layer to perform a CRUD function, a transaction management function, a data parallelism function, a query function, or a combination of the above. The method of claim 140, or any of the claims herein, wherein the data access layer is coupled to at least one layer of the data store in accordance with a dependent inversion principle (DIP). The method of claim 140 or any of the claims herein, wherein the data store comprises a service layer, the service layer comprising a repository, the repository comprising a plurality of repository instances. The method of claim 140 or any of the claims herein, wherein the data store comprises a database service layer, the database service layer providing access to the data in the data store. The method of claim 140, wherein the first information includes reservation information, online payment information, notification information, delay fee information, multiple tracking information, pre-installation information, administrative information, or One of the above combinations. The method of claim 140, wherein the conversion data comprises: performing a repository process, the performing the repository process comprising: constructing a repository instance corresponding to the TOS data format; processing the received information as The TOS formats the first data; and transmits the first data to the TOS environment. The method of claim 146 or any of the claims herein, wherein the performing the repository processing comprises: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. The method of claim 140, or any of the claims of the present invention, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 148, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material used to populate the constructed shared commercial object. The method of claim 140 or any of the claims herein, wherein the conversion Including: converting, by a transformation, a second container data in a second TOS data format at a second TOS into the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and A configuration of a shared commercial object/entity/command structure of a repository instance; wherein the method further comprises providing the first data and the second data for processing in the TOS agnostic data format via a user interface The output in the original data format is transmitted to the first TOS and the second TOS via the repository. A method of claim 147, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. A method of claim 151, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 152, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to implement an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or include a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. The method of claim 140, or any of the claims herein, further comprising: obtaining the container data using the data access layer; and converting the container data into a TOS agnostic data format to create TOS agnostic container data. The method of claim 154, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving a The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 155, or any of the claims herein, wherein the data access layer obtains TOS-specific data from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 154, or any of the claims of the present invention, wherein the converting comprises: converting, by the transformation, the second container data in a second TOS data format at a second TOS into the TOS agnostic data format, the transformation involving Use of one or more repository instances and/or creation and construction of a common commercial object/entity/command structure according to a repository instance; wherein the method further comprises providing the first data and the second material for The TOS agnostic data format is processed via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. The method of claim 140 or any of the claims herein, further comprising determining a repository type based on the TOS type by identifying a repository type associated with the TOS type in a repository type cache. The method of claim 158, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. A computer-implemented method for processing information, the method comprising: providing information for displaying an interface to a user, the interface comprising system functionality and an input field for receiving a user input, the information Containing first information in a TOS data format associated with a TOS type; processing information related to the user input received via the interface to manage the functionality of the system, the process comprising converting the data to a TOS The unknowable data format is used to create a TOS agnostic data by instantiating a first repository instance for a first TOS type, the first repository instance being obtained by a repository instance module, a preset a repository factory module, a TOS type attribute module, a report repository module, a service application registration module, a core registration module, a registration distribution station repository module, and a registration manager repository module a group, or a combination of one of the above, instantiated; using the first repository instance to request the first data to save Taking a data source for a particular site; constructing a commercial object using the first data; providing a TOS agnostic output based on the commercial object for processing and displaying to the user via the repository; and using the TOS The unknowable data is processed to produce an output and/or a result associated with: processing and/or transmitting instructions within the system, processing and/or transmitting the instructions to the outside of the system a computing device, or a combination of the two; performing system functionality in the system such that one of the results of the managed system functionality and/or one of the processed information is output; and/or processing Transmitting, and/or performing a combination of functions related to the output and/or result. The method of claim 160 or any of the claims herein, further comprising processing to determine a module to instantiate the first repository instance. The method of claim 161, or any of the claims herein, wherein the module is determined based on the first TOS type. The method of claim 160, wherein the first information includes reservation information, online payment information, announcement information, delay fee information, multiple tracking information, pre-installation information, administrative information, or the like One combination. A method of claim 160 or any of the claims herein, wherein the conversion The data includes: performing a repository process, where the performing the repository process comprises: constructing a repository instance corresponding to the TOS data format; processing the received information into a TOS formatted first data; and transmitting the first data to The TOS environment. The method of claim 160, wherein the performing the repository processing comprises: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. The method of claim 160, or any of the claims of the present invention, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 166, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material used to populate the constructed shared commercial object. The method of claim 160 or any of the claims herein, wherein the converting comprises: converting a second TOS data at a second TOS via transformation The formatted second container data is converted to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance; The method further includes providing the first data and the second data for processing in the TOS agnostic data format via a user interface, and transmitting the output in the original data format to the first TOS via the repository And the second TOS. The method of claim 164, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. The method of claim 169, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 170, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to implement an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or include a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. The method of claim 164 or any of the claims herein further comprising: Use the repository instance to obtain container data; and convert the container data into a TOS agnostic data format to create TOS agnostic container data. The method of claim 172, or any of the claims of the present invention, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving a The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. The method of claim 173, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 172, or any of the claims of the present invention, wherein the converting comprises: converting, by the transformation, the second container data in a second TOS data format at a second TOS into the TOS agnostic data format, the transformation involving Use of one or more repository instances and/or creation and construction of a common commercial object/entity/command structure according to a repository instance; wherein the method further comprises providing the first data and the second material for The TOS agnostic data format is processed via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. The method of claim 164, or any of the claims herein, wherein the repository type is determined to be included in a repository type cache based on the TOS type A type of repository associated with the TOS type is identified in the memory. The method of claim 176, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. A computer-implemented method for processing an announcement message, the method comprising: processing to instantiate a first repository instance for a first TOS type; processing to request the first data to be saved using the first repository instance Taking a data source for a specific site; performing processing to determine whether a TOS agnostic notification is triggered based on the first data and a condition; and when the TOS agnostic notification is triggered, processing to agnorate the TOS The notice is provided to a user, and the TOS agnostic notice provides information based on the first data. The method of claim 178 or any of the claims herein, further comprising receiving, by the user who customized the condition, a request. The method of claim 179, or any of the claims herein, wherein the request includes an availability request, a reservation status request, an entry gate request, an exit gate request, a binding valid request, a container ready reservation request, and a delay A request for a fee announcement, or a combination of the above. The method of claim 178 or any of the claims of the present invention, wherein the condition is defined by the first information, the first information including device inventory information, Prepare transaction information, appointment information, online payment information, announcement information, delay fee information, multiple tracking information, pre-installation information, administrative information, or a combination of the above. The method of claim 178, or any of the claims herein, wherein the determining, by the determining whether the TOS agnostic notification is triggered comprises: determining whether a container is available, determining whether a container is a current status of the reservation, determining whether a container has entered A gate determines whether a container has exited a gate, determines whether a container is in a delay alarm condition, determines whether a container has been released, determines whether a container that has been released returns to the current status, and determines whether a binding is Valid, or a combination of each of the above. The method of claim 178, or any of the claims herein, wherein processing to provide the TOS agnostic notification comprises transmitting an email, a text message, a fax, or a combination of the foregoing. The method of claim 178, or any of the claims herein, wherein the TOS agnostic announcement is a group announcement comprising information regarding one or more first materials, one or more conditions, or a combination of the foregoing . The method of claim 178, or any of the claims herein, further comprising: providing information for displaying an interface to a user, the interface comprising an announcement system functionality and an input field for receiving a first user input Transceiving information related to the user input received via the interface to manage the functionality of the notification system; Processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the system, processing and/or transmitting instructions to a calculation external to the system a device, or a combination of the two; performing system functionality in the system such that one of the results of the managed system functionality and/or one of the processed information is output; and/or processing, transmitting, and / or perform a combination of functions involving the output and / or results. The method of claim 185 or any of the claims herein, the method further comprising: processing data in a TOS data format associated with a TOS type; converting the data to a TOS agnostic data format to create TOS agnostic data And use the TOS unknown data for processing. The method of claim 186, wherein the conversion data comprises: performing a repository process, the performing the repository process comprising: constructing a repository instance corresponding to the TOS data format; processing the received information as TOS formats the first data; The first data is transmitted to the TOS environment. The method of claim 186, or any of the claims of the present invention, wherein the performing the repository processing comprises: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. The method of claim 186, or any of the claims of the present invention, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. A method of claim 189, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 186, or any of the claims of the present invention, wherein the converting comprises converting, by the transformation, a second container data in a second TOS data format at a second TOS into the TOS agnostic data format, the transformation involving Use of one or more repository instances and/or creation and construction of a common commercial object/entity/command structure according to a repository instance; wherein the method further includes providing information for the TOS via a user interface Agnostic data format processing, at the same time The repository will transmit the output in the original data format to the first TOS and the second TOS. A method of claim 187, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. The method of claim 192, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. The method of claim 193, or any of the claims herein, wherein the using the reflection operation comprises discovering a TOS type: the TOS type is configured to implement an interface that uses one of the control containers to reverse the assembly; In the namespace; and/or include a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. The method of claim 187, or any of the claims herein, further comprising: using the repository instance to obtain TOS-specific object data including container data, reservation data, gate activity data, or a combination of the foregoing; and the TOS The specific object data is converted into a TOS agnostic data format to create TOS agnostic object data. A method of claim 195 or any of the claims herein, wherein the conversion The converting, by transforming, the first TOS-specific object data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving the use and/or creation of a TOS-specific repository instance And the construction of a common commercial item according to a repository instance. A method of claim 196, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. The method of claim 195, wherein the converting comprises: converting, by the transform, the second TOS-specific object data in a second TOS data format at a second TOS into the TOS agnostic data format, The transformation involves the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance; wherein the method further includes providing information for use via a user interface Processing in the TOS agnostic data format, while transmitting the output in the original data format to the first TOS and the second TOS via the repository. A method of claim 187, or any of the claims herein, wherein determining the repository type based on the TOS type comprises identifying a repository type associated with the TOS type in a repository type cache. The method of claim 199, or any of the claims herein, wherein identifying the repository type associated with the TOS type comprises using at least one of a reflection operation, a helper attribute, and/or a convention to determine the relationship. The method of claim 178, or any of the claims herein, further comprising processing to generate an output and/or result related to performing status update functionality, the status update functionality being related to the first material. A system comprising: a computer storage containing data, including TOS specific data, TOS agnostic data, repository data, materials related to equipment inventory information, materials related to equipment transaction information, and reservations Information related to information, information relating to online payment information, information relating to information on notifications, information relating to information on delays, information relating to multiple tracking information, information relating to pre-installation information, and administrative information Relevant material, or a combination of one of the above; and a processor coupled to the computer storage and configured to perform processing associated with the method of performing any of the above claims. A system comprising: one or more servers, computing devices, and/or computer readable media, comprising instructions, embodying instructions, and/or being configured for processing instructions, the instructions being operative by one or more Executing for operating a reservation system and/or a collection station operating system, the instructions including instructions for performing method request items 1, 20, 25, 40, 46, 49, 50, 140, 160, One or more of the aspects set forth in one or more of 178 and/or otherwise disclosed herein. A system comprising: a server comprising or accessing one or more storage devices and/or one or more computer readable media, the one or more storage devices and/or one or more computer readable The media includes instructions, embody instructions, and/or is configured to process instructions that are executable by one or more processors for operating a reservation system and/or a sink system, the instructions including Instructions for performing the following: performing one or more of the aspects set forth in one or more of the method request items 1, 20, 25, 40, 46, 49, 50, 140, 160, 178 and/or otherwise disclosed herein step. A system comprising: one or more servers, computing devices, and/or computer readable media, comprising instructions, embodying instructions, and/or being configured for processing instructions, the instructions being operative by one or more Executing for operating a reservation system and/or a collection station operating system, the instructions including instructions for providing information for displaying an interface to a user, the interface including system functionality and Receiving an input field input by a user, the information including first information in a TOS data format associated with a TOS type; processing information related to the user input received via the interface to manage the system Functionality, the process involves converting the data into a TOS agnostic data format to create TOS agnostic data by: Instantiating a first repository instance for a first TOS type, the first repository instance is obtained by obtaining a repository instance module, a preset repository factory module, a TOS type attribute module, and a report a repository module, a service application registration module, a core registration module, a registration collection repository repository module, a registration manager repository module, or a combination of one of the above; a repository instance requesting first material to access a data source for a particular venue; constructing a commercial object using the first data; providing a TOS agnostic output based on the commercial object for processing via the repository And displaying to the user; and processing using the TOS agnostic data to generate an output and/or a result associated with: processing and/or transmitting instructions within the system, Processing and/or transmitting instructions to a computing device external to the system, or a combination of the two; performing system functionality in the system such that the functionality of the managed system is generated Outputting one result and/or one of the processed information; and/or processing, transmitting, and/or performing a combination of functions related to the output and/or result. A system as claimed in claim 205, or any of the claims herein, wherein the instructions further comprise instructions for processing to determine a module to instantiate the first repository instance. A system of claim 206 or any of the claims herein, wherein the module is determined based on the first TOS type. The system of claim 205 or any of the claims herein, wherein the first information includes reservation information, online payment information, announcement information, delay fee information, multiple tracking information, pre-installation information, administrative information, or the like One combination. A system of claim 205, or any of the claims herein, wherein the instructions for performing processing for converting material include instructions for performing a repository process, the performing the repository process comprising: constructing the corresponding a repository instance of the TOS data format; processing the received information as a TOS formatted first data; and transmitting the first data to the TOS environment. A system as claimed in claim 205, or any of the claims herein, wherein the instructions for performing repository processing include instructions for: determining a repository type based on the TOS type; based on the repository type and the TOS type instance A repository instance. A system as claimed in claim 205, or any of the claims herein, wherein the instructions for performing processing for converting include instructions for: converting a first TOS data at a first TOS via a transform The formatted first container data is converted into a TOS agnostic data format that involves the use and/or creation of a TOS specific repository instance and the construction of a common commercial object based on a repository instance. A system of claim 211 or any of the claims herein, wherein the repository instance retrieves TOS-specific material from a TOS-specific data source, the TOS-specific material used to populate the constructed shared commercial object. A system as claimed in claim 205, or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a second TOS in a second TOS data format via a transform Converting the second container data to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance; The first data and the second data are used for processing in the TOS agnostic data format via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. A system of claim 209 or any of the claims herein, wherein the instructions for performing processing for determining the repository type based on the TOS type include identifying the TOS in a repository type cache memory A type of instruction related to a repository type. A system of claim 214 or any of the claims herein, wherein the process for identifying the repository type associated with the TOS type is performed The instructions of the instructions include instructions for determining the relationship using at least one of a reflection operation, a helper attribute, and/or a convention. A system of claim 215, or any of the claims herein, wherein the instructions for performing processing for using the reflective operation comprise instructions for discovering a TOS type: the TOS type is configured to implement a control container One of the reversed mating interfaces; included in a namespace of interest; and/or containing a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. A system as claimed in claim 209, or any of the claims herein, wherein the instructions further comprise instructions for obtaining container data using the repository instance; and converting the container data to a TOS agnostic data format to create a TOS I don't know the container information. The system of claim 217 or any of the claims herein, wherein the converting comprises converting, by the transformation, the first container data in a first TOS data format at a first TOS into a TOS agnostic data format, the transformation involving a The use and/or creation of a TOS-specific repository instance and the construction of a common commercial object based on a repository instance. A system of claim 218 or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material used to populate the constructed shared commercial object. A system such as claim 217 or any of the claims herein, The instructions for processing the conversion include instructions for converting a second container data in a second TOS data format at a second TOS to the TOS agnostic data format via a transformation, the transformation A configuration involving the use and/or creation of one or more repository instances and a common commercial object/entity/command structure according to a repository instance; wherein the method further comprises providing the first data and the second data for use The TOS agnostic data format is processed via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. A system of claim 209 or any of the claims herein, wherein the instructions for performing processing for determining the repository type based on the TOS type include identifying the TOS in a repository type cache memory A type of instruction related to a repository type. A system of claim 2, or any of the claims herein, wherein the instructions for performing processing for identifying the repository type associated with the TOS type include for using a reflection operation, a helper attribute, and/or At least one of the conventions determines the instruction of the relationship. A system comprising: one or more servers, computing devices, and/or computer readable media, comprising instructions, embodying instructions, and/or being configured for processing instructions, the instructions being operative by one or more Executed for operating a reservation system and/or a collection station operating system, the instructions including An operation command: processing to instantiate a first repository instance for a first TOS type; processing to request the first material to access a data source for a particular venue using the first repository instance; Processing to determine whether a TOS agnostic notification is triggered based on the first data and a condition; and when the TOS agnostic notification is triggered, processing to provide the TOS agnostic notification to a user, the TOS agnostic notification Provide information based on the first data. A system as claimed in item 223 or any of the claims herein, further comprising instructions for performing processing for receiving a request by the user for customizing the condition. A system of claim 224 or any of the claims herein, wherein the request includes an availability request, a reservation status request, an entry gate request, an exit gate request, a binding valid request, a container ready reservation request, and a delay A request for a fee announcement, or a combination of the above. The system of claim 223 or any of the claims herein, wherein the condition is defined by the first information, the first information including device inventory information, device transaction information, reservation information, online payment information, notification information, delay fee information, Multiple tracking information, pre-installation information, administrative information, or a combination of the above. A system of claim 223 or any of the claims herein, wherein the processing is used to determine whether the TOS agnostic notification is triggered The order includes an instruction for determining whether a container is available, determining whether a container is a retaining status, determining whether a container has entered a gate, determining whether a container has exited a gate, and determining whether a container is in a In the case of the delay fee alarm, it is determined whether a container has been released, whether a container that has been released is returned to the current status of the reservation, whether a reservation is valid, or a combination of the above. A system of claim 223 or any of the claims herein, wherein the instructions for processing to provide the TOS agnostic announcement comprise instructions for transmitting an email, a text message, a fax, or a combination of the foregoing . A system as claimed in claim 223, or any claim herein, wherein the TOS agnostic announcement is a group announcement comprising one or more first materials, one or more conditions, or a combination of the foregoing News. A system of claim 223, or any of the claims herein, wherein the instructions further comprise instructions for providing information for displaying an interface to a user, the interface including annotating system functionality and for receiving a An input field input by the first user; processing information related to the user input received through the interface to manage the functionality of the notification system; and processing to generate an output and/or a result, the output and / or the result is associated with: processing and / or transmitting instructions within the system, processing the instructions And/or transmitted to a computing device external to the system, or a combination of the two; wherein the system functionality is performed in the system such that one of the results of the managed system functionality and/or the processed information is generated One of the outputs; and/or a combination of processing, transmitting, and/or performing functions related to the output and/or results. A system of claim 230 or any of the claims herein, wherein the instructions further comprise instructions for processing data in a TOS data format associated with a TOS type; converting the data to a TOS agnostic The data format is used to create TOS agnostic data; and the TOS agnostic data is used for processing. A system as claimed in claim 186, or any of the claims herein, wherein the instructions for performing processing for converting material include instructions for performing a repository process, the performing library processing comprising: constructing corresponding to the a repository instance of the TOS data format; processing the received information as a TOS formatted first data; and transmitting the first data to the TOS environment. A system as claimed in item 232 or any of the claims herein, wherein The instructions processed by the row repository include instructions for: determining a repository type based on the TOS type; instantiating a repository instance based on the repository type and the TOS type. A system of claim 232, or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a first TOS at a first TOS in a first TOS data format The first container data is converted into a TOS agnostic data format that involves the use and/or creation of a TOS specific repository instance and the construction of a common commercial object based on a repository instance. A system of claim 234, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. A system of claim 232, or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a second TOS at a second TOS in a second TOS data format Converting the second container data to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and construction of a common commercial object/entity/command structure according to a repository instance; providing information For processing in the TOS agnostic data format via a user interface, while the original data grid is used via the repository The output of the equation is transmitted to the first TOS and the second TOS. A system of claim 233, or any of the claims herein, wherein the instructions for performing processing for determining the repository type based on the TOS type include identifying the TOS in a repository type cache memory A type of instruction related to a repository type. A system of claim 237, or any of the claims herein, wherein the instructions for performing processing for identifying the repository type associated with the TOS type include for using a reflection operation, a helper attribute, and/or At least one of the conventions determines the instruction of the relationship. A system of claim 238, or any of the claims herein, wherein the instructions for performing processing for using the reflective operation comprise instructions for discovering a TOS type, the TOS type: being configured to implement a control container One of the reversed mating interfaces; included in a namespace of interest; and/or containing a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. The system of claim 233 or any of the claims herein, further comprising: using the repository instance to obtain TOS-specific object data including container data, reservation data, gate activity data, or a combination of the foregoing; and the TOS The specific object data is converted into a TOS agnostic data format to create TOS agnostic object data. A system as claimed in claim 240, or any of the claims herein, wherein the instructions for performing processing for converting include, for transforming, a first TOS specific to a first TOS data format at a first TOS via a transform The object data is converted into a TOS agnostic data format instruction that involves the use and/or creation of a TOS specific repository instance and the construction of a common commercial object based on a repository instance. A system of claim 241 or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. A system of claim 240 or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a second TOS at a second TOS in a second TOS data format The second TOS specific object data is converted to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance The method further includes providing data for processing in the TOS agnostic data format via a user interface, and transmitting the output in the original data format to the first TOS and the second TOS via the repository. A system of claim 233, or any of the claims herein, wherein the instructions for performing processing for determining the repository type based on the TOS type comprise identifying and identifying in a repository type cache memory The TOS type is associated with a repository type of instruction. A system of claim 244 or any of the claims herein, wherein the instructions for performing processing for identifying the repository type associated with the TOS type include for using a reflection operation, a helper attribute, and/or At least one of the conventions determines the instruction of the relationship. A system of claim 223 or any of the claims herein, wherein the instructions further comprise instructions for processing to generate an output and/or result related to performing state update functionality, the state update functionality and the first Information related. A system comprising: one or more servers, computing devices, and/or computer readable media, comprising instructions, embodying instructions, and/or being configured for processing instructions, the instructions being operative by one or more Executing for operating a reservation system and/or a collection station operating system, the instructions including instructions for providing information for displaying an interface to a user, the interface including system functionality and Receiving an input field input by a user, the information including first information in a TOS data format associated with a TOS type; processing information related to the user input received via the interface to manage the system Functionality, the process comprising converting the data into a TOS agnostic data format to create TOS agnostic data by instantiating a data access layer; Using the data access layer to request the first data to access a data store; constructing a commercial object using the first data; providing a TOS agnostic output according to the commercial object for processing and forwarding via the data access layer Displaying by the user; and processing using the TOS agnostic data to generate an output and/or a result associated with the operation of processing and/or transmitting instructions within the system Processing and/or transmitting to a computing device external to the system, or a combination of the two; performing system functionality in the system such that one of the results of the managed system functionality is generated and/or after the processing One of the information outputs; and/or a combination of processing, transmitting, and/or performing functions related to the output and/or results. A system of claim 247 or any of the claims herein, wherein: the material access layer includes a create, read, update, and delete (CRUD) method, transaction management, data parallelism, query functionality, or a combination of the foregoing And the instructions further include instructions for processing information using the data access layer to perform a CRUD function, a transaction management function, a data parallelism function, a query function, or a combination of the above. A system of claim 247 or any of the claims herein, wherein the data access layer is coupled to the data store in accordance with a dependent inversion principle (DIP) aspect At least one layer of the device. A system of claim 247 or any of the claims herein, wherein the data store comprises a service layer, the service layer comprising a repository, the repository comprising a plurality of repository instances. A system of claim 247 or any of the claims herein, wherein the data store comprises a database service layer, the database service layer providing access to the data in the data store. The system of claim 247 or any of the claims herein, wherein the first information includes reservation information, online payment information, announcement information, delay fee information, multiple tracking information, pre-installation information, administrative information, or the like One combination. A system of claim 247 or any of the claims herein, wherein the instructions for performing processing for converting material include instructions for performing a repository process, the performing the repository process comprising: constructing the corresponding a repository instance of the TOS data format; processing the received information as a TOS formatted first data; and transmitting the first data to the TOS environment. A system as claimed in claim 253, or any of the claims herein, wherein the instructions for performing repository processing include instructions for: determining a repository type based on the TOS type; based on the repository type and the TOS type instance a repository Example. A system of claim 247 or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a first TOS at a first TOS in a first TOS data format The first container data is converted into a TOS agnostic data format that involves the use and/or creation of a TOS specific repository instance and the construction of a common commercial object based on a repository instance. A system of claim 255, or any of the claims herein, wherein the repository instance obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. A system of claim 247, or any of the claims herein, wherein the instructions for performing processing for converting include instructions for translating a second TOS in a second TOS data format via a transform Converting the second container data to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance; The first data and the second data are used for processing in the TOS agnostic data format via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. A system such as claim 254 or any of the claims herein, The instructions for determining the processing of the repository type based on the TOS type include instructions for identifying a repository type associated with the TOS type in a repository type cache. A system of claim 258 or any of the claims herein, wherein the instructions for performing processing for identifying the repository type associated with the TOS type include for using a reflection operation, a helper attribute, and/or At least one of the conventions determines the instruction of the relationship. A system of claim 152, or any of the claims herein, wherein the instructions for performing processing for using the reflective operation comprise instructions for discovering a TOS type: the TOS type is configured to implement a control container One of the reversed mating interfaces; included in a namespace of interest; and/or containing a TOS type attribute of interest and/or included in a sub-namespace named after a TOS type of interest. A system of claim 247, or any of the claims herein, wherein the instructions further comprise instructions for performing processing for obtaining container data using the material access layer; and converting the container data to a TOS Know the data format to create TOS agnostic container information. The system of claim 261 or any of the claims herein, wherein the instructions for performing processing for converting include converting, by transforming, the first container data in a first TOS data format at a first TOS For a TOS agnostic data format instruction, the transformation involves a TOS The use and/or creation of a particular repository instance and the construction of a common commercial object based on a repository instance. A system of claim 262 or any of the claims herein, wherein the material access layer obtains TOS-specific material from a TOS-specific data source, the TOS-specific material being used to populate the constructed shared commercial object. A system of claim 261 or any of the claims herein, wherein the instructions for performing processing for converting include instructions for converting a second TOS in a second TOS data format via a transform Converting the second container data to the TOS agnostic data format, the transformation involving the use and/or creation of one or more repository instances and the construction of a common commercial object/entity/command structure according to a repository instance; The first data and the second data are used for processing in the TOS agnostic data format via a user interface, and the output in the original data format is transmitted to the first TOS and the second TOS via the repository. A system as claimed in claim 247, or any of the claims herein, wherein the instructions further comprise means for performing, based on the TOS, identifying a repository type associated with the TOS type in a repository type cache memory The type determines the instruction of a repository type of processing. A system of claim 265 or any of the claims herein, wherein the instructions for performing processing for identifying the repository type associated with the TOS type include using a reflection operation, a helper attribute, and / or at least one of the conventions to determine the instruction of the relationship. A computer-implemented method for processing information, the information relating to a reservation system for a collection station operating system, the method comprising: providing information for displaying a mobile interface to a user on a mobile device, The action interface includes a reservation function and an input field for receiving a user input, the information includes first information, the first information includes action input reservation information; and processing is received via the action interface and is related to the user input Information to manage the subscription functionality; and to process to produce an output and/or a result associated with the operation of processing and/or transmitting instructions within the reservation system, the instructions Processing and/or transmitting to a computing device external to the reservation system, or a combination of the two; performing the reservation functionality via the reservation system such that one of the results of the managed reservation functionality is generated and/or the processing One of the post-information outputs; and/or a combination of processing, transmitting, and/or performing functions related to the output and/or results. The method of claim 267, or any of the claims herein, wherein the subscription functionality comprises login page functionality, distribution site login page functionality, menu functionality, login page functionality, gate query functionality, import query functionality, appointments Ask for functionality, appointment details functionality, appointment modification functionality, appointment deletion functionality, appointment setup functionality, appointments State functionality, message functionality, location functionality, directional functionality, contact functionality, and general information functionality. A computer-implemented method for processing information, the information relating to a reservation system for a collection station operating system, the method comprising: providing information for displaying an interface to a user, the interface including reservation functionality and And an input field for receiving a user input, the information includes first information, the first information includes dual mobile reservation information; processing information related to the user input received through the interface to manage the reservation function And processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the reservation system, processing and/or transmitting the instructions to the appointment a computing device external to the system, or a combination of the two; performing the subscription functionality via the subscription system such that one of the results of the managed subscription functionality and/or one of the processed information is output; and Or a combination of processing, transmitting, and/or performing functions related to the output and/or results. A method of claim 269, or any of the claims herein, wherein the subscription functionality comprises processing a dual mobile subscription for a combination of one of an inbound mobile type and an outbound mobile type. The method of claim 269 or any of the claims herein, wherein the dual Mobile booking information includes container and SSCO information. The method of claim 269, or any of the claims herein, wherein the dual mobile subscription information comprises a double vacant movement for two appointments of different mobile types simultaneously. The method of claim 269, or any of the claims herein, wherein the dual mobile subscription information comprises a single incoming mobile subscription and a single outgoing mobile subscription that can be paired to form a dual mobile subscription. The method of claim 269, or any of the claims herein, wherein the collection station operating system subscription functionality comprises verifying the dual mobile subscription information. The method of claim 269, or any of the claims herein, wherein the collection station operating system reservation functionality comprises pairing a single appointment to create a dual entry appointment and unpairing a dual movement to create a single appointment. In the method of claim 269 or any of the claims herein, wherein the unpaired dual mobile subscription comprises a UTN and an appointment date/time from the paired dual mobile subscription to each of the unpaired subscriptions. The method of claim 269, or any of the claims herein, wherein the deletion of the dual mobile subscription information causes a dual mobile subscription to be unpaired. The method of claim 269, or any of the claims herein, wherein the deletion of the dual mobile subscription information comprises an incoming mobile, outgoing mobile, and mobile type. A method of claim 267, claim 269, or any of the claims herein, wherein the processing to generate an output and/or a result comprises converting the TOS specific data to a TOS agnostic format to create a TOS. Know the information and handle the TOS unknowable information. A system comprising: one or more servers, computing devices, and/or computer readable media, comprising instructions, embodying instructions, and/or being configured for processing instructions, the instructions being operative by one or more Executing for operating a reservation system and/or a collection station operating system, the instructions including instructions for processing information for use in the mobile device from a reservation system for a collection station operating system Displaying, the information includes first information, the first information includes action input reservation information; providing a mobile interface, the action interface receiving user input associated with the subscription functionality; processing the received via the mobile interface Entering relevant information to manage the subscription functionality, the processor processes to generate an output and/or a result associated with the operation of processing and/or transmitting within the reservation system An instruction to process and/or transmit an instruction to a computing device external to the reservation system, or a combination of the two; the execution of the pre-via via the reservation system The functionality is such that one of the results of the managed subscription functionality and/or one of the processed information is output; and/or a combination of processing, transmitting, and/or performing functions related to the output and/or results. A system as claimed in claim 280, or any of the claims herein, wherein the process is agnostic to the Dash Station Operating System (TOS). The system of claim 280, or any of the claims herein, wherein the user input includes a command for establishing an import container reservation, modifying an import container reservation, searching for an import container reservation, deleting an import container reservation, observing one Import container reservations, or a combination of each of the above. The system of claim 280, or any of the claims herein, wherein the output comprises an established import container reservation, a modified import container reservation, a search result including an import container reservation, an import container reservation deletion, an import One of the container reservations is displayed, or a combination of one of the above. A system as claimed in claim 280, or any of the claims herein, wherein the subscription functionality comprises login page functionality, distribution site login page functionality, menu functionality, login page functionality, gate query functionality, import query functionality, appointments Ask for functionality, appointment detail functionality, appointment modification functionality, appointment deletion functionality, appointment setup functionality, subscription state functionality, message functionality, location functionality, orientation functionality, contact functionality, general information functionality , or a combination of one of the above. A system of claim 280, or any of the claims herein, wherein the generated output and/or result provides reduced operating cost, accelerated throughput, preferred device utilization, or a combination of the foregoing, from improved gate efficiency.