Patent Application
20150347984
Appendices, labeled “Appendix 1” through “Appendix 5”, are attached hereto and incorporated by reference herein in their entirety. This application also includes and hereby incorporates by reference the computer program appendix materials submitted herewith on compact disc (CD) as well as the Transmittal Letter regarding the CD materials, which lists the files on each compact disc. The incorporated computer program materials are contained on one compact disc, and a duplicate copy is also provided per 37 CFR 1.77(b)(5), thus two (2) discs are submitted herewith (labeled “Copy 1” and “Copy 2”, respectively).
The process of importing and exporting containers and goods at a port involves multiple parties and requires significant communication and coordination. In addition, the parties involved must adhere to numerous regulations and guidelines.
Systems known as Terminal Operating Systems (TOS) have been developed to support this process at port terminals around the world. Many of the standard operating procedures related to activities at the terminal, such as import and export functions, have become a part of these TOS applications, although they are implemented differently.
However, aspects such as resource (equipment utilization and labor) planning and management, exception management, real-time exception management, TOS-agnostic software/platforms/components and other interrelated functionality are areas that have not been adequately addressed by existing Terminal Operating Systems.
The shipping industry, as briefly described in
For example, a Trucking Company may schedule a pick-up a container and make an appointment that includes specific counts and types of containers. For each container, attributes such as dimensions, etc. are specified. When an entity associated with such container (e.g., driver etc.) comes to the terminal to process or deliver the container, system uses information pre-entered by the entity while making an appointment. Attributes of one or more containers may not match the specified attributes of the appointment. In this scenario, such entity typically will not be allowed to process or deliver the container until the information matches the container.
In the past, issues such as the one described above required a significant amount of 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 with the desired handling of the container(s).
The accompanying drawings, which constitute a part of this specification, illustrate various implementations and features of the present inventions and together with the description, help explain aspects of the innovations herein. In the drawings:
FIGS. 28A1-28A4 and 28B-28E are diagrams of exemplary Appointment user interfaces consistent with one or more aspects of the innovations herein.
Reference will now be made in detail to various implementations, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a sufficient understanding of the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that implementations subject matter may be practiced without such specific details. Moreover, the particular implementations described herein are provided by way of example, and should not be used to limit the scope of the invention to particular embodiments. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the innovations herein.
In accordance with aspects of the present inventions, various computer hardware, software, user interface (UI) and/or communications features may be utilized or involved in novel ways to provide the innovative systems and methods herein. According to certain embodiments, for example, an illustrative implementation may comprise a set of computer network based applications and machine readable instructions that interface with a Terminal's TOS (Terminal Operating System). In some embodiments, implementations herein are capable of providing real-time access to information and tools for business parties including SSCOs, trucking companies, brokers, consignees, etc. to update that information, e.g., via such interface. Consistent with the present disclosure, some implementations may drive operational efficiencies and/or improve customer service. Some additional beneficial characteristics of various implementations may include, for example, one or more of the following: minimizing cargo movement problems at the terminal; improving terminal operators' ability to successfully service SSCOs and carriers; removing terminals from the role of broker between trucking and steamship companies; eliminating reliance on phone, fax and other non-electronic instructions to the terminal; delivering real-time, accurate information carriers can use to quickly pass through terminal gates; preventing terminal/gate congestion; and/or expedited trouble resolution resulting in improved turn-times for entities transferring freight/cargo.
Various implementations herein have the capability of minimizing communication and can streamline various aspects of the processes. Further, some implementations may also accomplish benefits herein by interfacing with other applications, such as an associated tracking application. Here, for example such application may facilitate logistical information sharing and communication flow among members of the shipping industry.
As a function of these systems, methods and features herein, inventions herein possess capabilities and yield abilities to give terminals network-based visibility and functionality from a variety of places at any time. For example, via features and functionality associated with the present systems and methods, implementations herein may allow trucking company to be informed when a container is ready for pick up, processed by driver, or missed reserved time slot, etc. In addition, the trucking company may be presented quick links to access, review and update their data related to the container.
Additionally, system and methods of some implementations may provide user access to real-time vessel schedules, import and export container information, gate activity, and/or user account information generated from a TOS. The terminal administrators can set up terminal-specific configuration and information; perform user account management and setup for automatic send of emails or faxes to users.
Referring to
According to some of the present systems and methods, innovative layered architecture(s) herein are capable of providing separation of concerns and factoring of code, which in some implementations may also provide the ability to update or enhance existing features and add new features without interfering with other parts of the applications and/or the ability to split out layers into separate physical tiers to improve scalability by adding more computing resources with increase of usages. Splitting the source code into layers may allow for separate layers of the code to be edited/added/deleted/etc. separately from one another, so that some elements may be changed without affecting other elements of the system. According to an example of present systems and methods, as set forth in one illustrative implementation shown in
In some embodiments, the business logic in present systems and methods may be represented by a domain model of the domain layer 303 which may involve or be a conceptual model that represents the various business domain(s) of the system. Here, for example, such domain model may mingle data and process, have multivalued attributes and a complex web of associations, and/or utilize inheritance features. The domain layer 303 may include the domain model and may define the interaction between elements of the domain model.
As shown in
Different terminal operating systems may use different data persisting technologies and may require different methods to access persisted data, addressed herein. For example, such access might entail access to relational databases from different vendors (Oracle, MS Sql, MySql, etc.), or such access might be access to the end point of WS*—compliant web services. Implementations designed to be TOS agnostic may have to switch data access method(s) with minimum impact at business logic layer and presentation layer.
According to further implementations, systems and methods herein may be designed or configured to be loosely coupled as a function of Dependency Inversion Principal (DIP) aspects. In some embodiments, such Dependency Inversion Principal aspects may state that high-level features (e.g., Business logic layer information or processing) may not depend on a lower level class (e.g., Data access layer). For example, classes in Business logic layer may instead always depend on abstractions of their required classes in the Data access layer. Thus, the Data access layer may be easily replaceable with abstractions or other data using different architecture and technology.
Here, the attached Appendices/computer program (CD) materials illustrate specific aspects and interrelations of the features described above, below and elsewhere herein.
In certain, other implementations, the Presentation layer may include or involve components of a Model-View Controller (MVC) framework, e.g. as set forth in
Model. The model 302 may contain or represent the data (e.g., view model or domain model) with which the user works. The model 302 may manage the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and respond to instructions to change state (usually from the controller).
View. The view 310 manages the display of information. Views may be utilized to render some part of the model 302 as a user interface (“UI”).
Controller. The controller 306 interprets the mouse and keyboard inputs from the user 204, informing the model 302 and/or the view 310 to change as appropriate.
Exemplary details of such MVC framework are found in
Presentation layer also includes logics 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 may define an application's boundary with a layer that establishes a set of available operations and coordinates the application's response in each operation. In some embodiments, the service layer will include the service contracts and operation contracts that are used to define the service interfaces that will exposed at the service boundary. Data contracts are also defined to pass in and out of the service.
Further, various systems and methods herein may implement the WCF [Windows Communication Foundation] service from Microsoft or similar services. However, service boundaries may be explicit, which includes or involves hiding all the details of the implementation behind the service boundary. This may include revealing or dictating what particular technology was used.
In connection with the above, as set forth in more detail in connection with
In some implementations, the service layer 222 may be compiled into a separate class assembly and hosted in a service host environment. Here, for example, the application layer 214 will only know about and have access to this layer. Whenever a request is received by the service layer 222, the request may be dispatched to the business logic layer and the business logic layer may perform the requested task. In such implementation(s), if any database support is needed by the business logic layer, the business logic layer may always go through the data access layer.
Referring again to
In one example instantiation, the invention may implement a WCF (Windows Communication Foundation) service 216, a framework for building service-oriented applications. However, in such instantiation(s), the service boundaries may be explicit, which means hiding all the details of the implementation behind the service boundary 222. This includes revealing or dictating what particular technology was used.
In another example, the service layer 222 is compiled into a separate class assembly and hosted in a service host environment. The application layer 214 only knows about and has access to this layer. Whenever a request is received by the service layer 222, the request may be dispatched to the repository 226, and the business logic layer may handle the request. If any database support is needed by the repository 226, the repository 226 may access the data access layer 250.
Referring again to
According to one illustrative TOS web portal 514 implementation, the domain model may be configured to look like the database design with mostly one domain object for each database table. Further, here, because the behavior of the business is subject to change, it is important to be able to modify, build, and test this layer easily. As such, minimum coupling features from the domain model to other layers in the system may be implemented.
Entities.
Implementations of such TOS web portal 514 may define business object as an entity, such as Bill of Lading, Container, Equipment, Booking, Release, Appointment, Demurrage, Payment, Vessel Schedule, Notifications, etc. Each entity may represent some meaningful individual in business domain. These objects mimic the data in business and objects that capture the rules the business uses. Inheritance, compositions, aggregation relationships are defined among those entities.
Referring once again to
Repository.
Referring once again to
A similar process may occur for each of the remaining requests 2-7, with differences in which web portal instance, service and repository are accessed. For example, a user at device 403 requests an export container list (#2) for a Terminal B that operates using a Terminal Operating System B different from the Terminal Operating System A. The request 2 for the export container list is routed to the export service 421 of the web portal instance 417. A GetExportContainerList method is called to an export repository of the TOS B repository 427. This export repository retrieves the requested export container list from the web portal service TOS B 431 via a network 447. The web portal instance A 417 returns the export container list 403 to the device 403.
A user at device 407 may input an update for a bill of lading (B/L) status for a Terminal C using a Terminal Operating System C. The update is input in a TOS agnostic data format. The update is transmitted to the import service 437 of the web portal instance B 433. An update B/L method is called by the import service 437 to the import repository of the TOS C repository 443. Within the TOS C repository 443, the import repository maps the user input of the B/L update status into the TOS C data format and transmits the update to the TOS C API 445. In response, the TOS C API 445 may transmit an acknowledgement or other reply to the TOS C repository 443. The TOS C repository 443 transforms any data in the TOS C format into the TOS agnostic format and returns the relevant information to the device 407. Taking one more example, a user at device 413 inputs a request for booking list information for the Terminal C that operates using a TOS C that is different from TOS A and TOS B. The request is forwarded to an export service 439 of the web portal instance B 433. The export service 439 calls a GetBookingList method to the export repository of the TOS C repository 443.
Referring to
In certain instances of the system and method here, the TOS web portal 514 may be a module-based application and may include a collection of modules that can be added and removed independently. Each module may be defined as a .NET assembly (dynamic link library assembly) within the TOS web portal 514. Further, a module can be responsible for exposing business logic to a client which is any entity that uses the module.
If a user desires to modify a module implementation, changes may be constrained to that module only. Such module-based architecture allows modules and clients to evolve separately. New versions of the existing module can be deployed without affecting existing client applications. Also new version of the existing client application can be deployed without affecting existing modules.
According to some implementations herein, development of modules in such TOS web portal implementations may have one or more of the following characteristics, some of which are depicted in
Referring to
Further, also referring to
Some implementations or instantiations of the system and methods disclosed herein may include a TOS Agnostic design. That is, the system is configured so that operation may occur without ‘care’ for various processing as to which TOS it is dealing with. In the context of the frameworks set forth above, for example, such implementations may include configuration(s) as a Repository—Pattern. The repository pattern is used to enable Terminal Operating System (TOS) independence. Each TOS may utilize its own unique database schema.
According to implementations herein, such repository locator 1008 may centralize distributed repository lookups, provide a centralized point of control, and may act as a cache that eliminates redundant lookups. Again, an exemplary TOS independent repository locator is shown in
The design and architecture of some of the examples of the system disclosed here, enable the present TOS Web Portal implementations 514 to be an add-on to any existing TOS as opposed to being integrated with a single TOS. This approach allows the present innovations and functionality to be incorporated into any existing TOS through a web-service API layer. Interfaces to other TOS's can be accomplished without the need to re-design or re-architect the TOS Web Portal implementations herein.
Systems and methods herein may also be configured using concepts and rules of Object-Oriented Programming. Here, for example, some implementations may utilize objects—data structures consisting of data fields and methods—that are defined along with abstractions of business processes for Terminal Operation. Such implementations utilizing object-oriented features and/or programming may provide many benefits, such as in one or more areas of reusability, extensibility, decoupling, maintainability, and/or reducing complexities, among others.
Reusability.
Some illustrative object-oriented implementations with reusability features may be configured with classes, which can be used by several applications. For example, such systems and methods may define common business model as objects and represent them using classes, such as Container, Vessel, Port, Partner, Appointment, Demurrage, Payment, Notification etc. Illustrative constructs, here, may include configurations such as seen in Insert X1: Reusability Code Example:
In the object-oriented approach, we build classes, which can be used by several applications. smartWeb defines common business model as objects and represent them using classes, such as Container, Vessel, Port, Partner, Appointment, Demurrage, Payment, Notification, etc.
Here, such constructs and definitions of objects may be reused throughout the application many times. Furthermore, the same object may be used to extend existing features or add new feature of the application. Accordingly, applications may be modified using working objects and thus code does not need to be written from scratch. Such reuse of objects reduces the effort of recreating them as well as reduces the chances of introducing errors. This not only saves development time but also improves the robustness of such applications.
Further, various OOP's programming functions and modules can be reused. For example, the following, Insert X2: Table Example may be used to call a method in service. The same function may also be used throughout application since the method is defined OOP practices.
These definitions of objects may be reused throughout the application. Furthermore, the same object may be used to extend existing features or add new feature of the application. Applications may be modified using working objects, rather than by writing code from scratch. The reuse of objects reduces the effort of recreating them as well as reduces the chances of introducing errors. This not only saves development time but also improves the robustness of the application.
In OOP's programing functions and modules can be reused. The following method may be used to call a method in service. The same function is used throughout the application in this example, since the method is defined OOP practices.
Extensibility.
To illustrate such features, see Insert X3. Assume Trucker is the salient Partner. Here, then, implementations may define a trucker by inheriting Partner. Via such aspects implementations may eliminate redundant code and extend the use of existing classes.
Trucker is a Partner. Thus, we define a trucker by inheriting Partner. Through this we can eliminate redundant code and extend the use of existing classes.
Decoupling.
With regard to decoupling, systems and methods may be configured to decouple modules using an interface instead of using the implementation. In some implementations, for example Insert X4, a Repository object may be defined to satisfy interfaces. Such decoupling of interface from implementation enabling the application to be TOS agnostic; illustrative configurations, here, may be structured as follows.
OOP practices in smartWeb may decouple modules using an interface instead of using the implementation. For example, Repository object is defined to satisfy interfaces. This decoupling of interface from implementation allows for the application to be TOS agnostic.
Maintainability.
Via use of objects and various OOP features herein, functions defined in such implementations may have very simple return values and parameters compared to those in existing systems. The following table show some illustrative examples as seen in Insert X5:
Using objects, functions defined herein may have very simple return values and parameters. For example.
Reducing Complexity/Complexities.
Here, a given problem in business can be viewed as a collection of difference objects. Each object may represent a business entity and may have all relevant business properties and processes as properties and methods. This abstraction may reduce the complexity of a problem and make it easy to manage. For example, in Insert X6, EquipmentControlEditModel object abstracts all business properties and processes relevant to managing containers or chassis in terminal.
A given problem in business can be viewed as a collection of difference objects. Each object may represent a business entity and may have all relevant business properties and processes as properties and methods. This abstraction may reduce the complexity of a problem and make it easy to manage.
For example, EquipmentControlEditModel object abstracts all business properties and processes relevant to managing containers or chassis in terminal.
This modularity makes an object to be maintained independently of other objects. Objects may be independent of each other and may be maintained separately. Modifications may be made in an object without affecting functionalities of other objects
Embodiments of the present TOS Web Portal systems and methods may have one or more of the following security implementations: authentication to authenticate users; authorization to decide which operations the user may execute and which resources the user may access; confidentiality to help ensure protection of sensitive data disclosure; and integrity to protect from changes, user data transmitted between client and server.
In certain example implementations of the system and methods, authentication may be found in different methods. Examples of these may be, inter alia, Windows Authentication (user signed into windows), Forms Authentication (using a web page to sign in), Passport Authentication (using Microsoft's Passport, also known as Live Id these days, to authenticate) etc.
Forms Authentication may allow use from the internet and restrict use to approved customers. Further, Forms authentication can be a token-based system. For example, when users log in, they may receive a token with basic user information. This information may be stored in an encrypted cookie that is attached to the response so it is automatically submitted on each subsequent request.
Further, system and methods herein may employ an authorization model. For example, implementations may be configured to use a permission-based security model. Such a model may have pre-defined roles such as those that perform similar functions as “Groups” or “Types” of existing systems. In some embodiments, however, implementations may require permissions for each action that needs security validation, such as:
According to these implementations, a role may be defined by a set of permissions that are allowed to the owner of the role. Users can have multiple roles and then will have all permissions belong to each role. Such features allow users to have different roles for a steamship company in a site, or have the same role for all steamship companies for the site or one role for all steamship companies and all sites.
Further, implementations may have pre-defined role(s) and custom role(s). Here, for example, pre-defined role examples may include, User Admin, Gate Clerk, High Volume User, Appointment Admin, Super Admin, SSCO User, Terminal User, and possibly others. Custom Role may allow a user to have customized role (a set of permissions). An admin module of the TOS Web Portal systems herein may provide tool(s) to assign permissions to a user that will be persisted as a new role, such as ABCD-Admin, XYZ-Bob, etc. Further, these custom roles can be reused. In still other implementations involving security, ASP.NET security framework can have a standardized user accounts system that supports all common user account tasks, including registering, managing passwords, and setting personal preferences.
According to additional embodiments herein, there may be other functional areas that may be implemented, including one or more of:
Finally, with respect to some implementations, systems and methods herein involving the present TOS Web Portal features may use SSL (Security Sockets Layer) in all modules.
Implementations herein may involve the layered architecture set forth above. A layer refers to a logical separation, such as a introducing a different assembly in the same process space. Layering provides separation of concerns and better factoring of code, which gives us maintainability and scalability. According to various implementations herein, there may be 4 layers in the present TOS Web Portal systems and methods—Presentation, Service, Business Logic and Data Access layers.
Business logics layer/aspects herein may be represented by a domain model which may be a conceptual model that represents the TOS Web Portal′ business domain. A domain model mingles data and process, has multi-valued attributes and a complex web of associations, and may use inheritance, for example. Further, the data access layer may be the layer that is solely responsible for talking to the data store and persisting and retrieving business objects. The layer may include the create, read, update and delete methods, transaction management, data concurrency, and/or a querying mechanism to enable the business logic layer to retrieve object for any given criteria.
Different Terminal Operating Systems may use different data persisting technologies and may require different method to access persisted data. For example, access to relational databases but from different vendors (Oracle, MS Sql, MySql, etc.) or it an access to the end point of WS*—compliant web services. For the system to be TOS agnostic, the system may switch data access method with minimum impact on business logic layer and presentation layer.
Repository-Pattern.
Repository pattern features and functionality herein may be used to make the application independent of Terminal Operating System (TOS). The repository may separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model, for example. The business logic may be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database or a Web service.
Further, in some implementations, a backing store for data can be a business service that is exposed by a line-of-business (LOB) application. Services are often expensive to invoke and benefit from caching strategies that are implemented within the repository. In this case, the logic first checks to see if the repository is in the cache. If it is not, the repository instance is created and placed into cache then utilized to retrieve the requested information.
Service Locator Pattern.
Service Locator pattern features and functionality herein may define a component that knows how to retrieve the services an application might need. The caller has no need to specify the concrete type; the caller may indicate an interface or an abstract type. The Service Locator pattern may hide the complexity of component lookup, handle the caching or pooling of instances and, in general, offer common provisioning for component lookup and creation.
A focus in Service Locator Pattern may be to achieve the lowest possible amount of coupling between components. The locator represents a centralized console that an application uses to obtain all the external dependencies it needs.
As such, present implementations may be designed to support multi-terminals with different Terminal Operating Systems. To support multi-terminals in TOS agnostic way, the TOS web interface application may involve processing to look up the repository that provides access to each of distributed terminal databases.
Turning back to overall aspects of the innovations herein, FIGS. 14A and 14B-1 show exemplary flow diagrams involving illustrative repository processing methods consistent with one or more aspects of the innovations herein.
Turning first to
In 1456, a service resolver module/processing layer may instantiate the retrieved/generated repository, for example by resolving a service associated with the cached attribute data. In 1460, the repository instance may be delivered. For example, the instance may be provided to the user who made the initial request for interaction.
Further, as set forth in more detail below, a variety of processing and modules may be utilized for different classes, such as GetRepositoryInstance, DefaultRepositoryFactory, TosTypeAttribute, ReportRepository, ServiceAppRegistry, CoreRegistrations, RegisterTerminalRepository, and RegisterAdminRepository.
With respect to exemplary Repository Factory processing, for example, a repository may have single constructor with dependencies defined as constructor parameters. A repository, however, may not be aware about how those components are created—it just may know what contracts implementation it should inject into the constructor. Further, the repository type may be resolved based on supplied TOS type. For this, IRepositoryFactory contract was introduced. Any implementation of this represents the actual component that returns the instance based on some condition.
Default one is DefaultRepositoryFactory that conveniently resolves particular repository type using reflection, helper attributes and a set of conventions. It uses the ReflectedRepositoryTypeCache utility class to save the known types until the application shutdown.
As shown in
Exemplary Module and Processing
i. RepositoryTypeCache
DefaultRepositoryFactory may be responsible to resolve the concrete repository type to be instantiated. It does that based on supplied Terminal TOS type, for example. For actual type discovery, it may use the set of conventions and helper attributes.
Internally, it may use reflection to discover types that:
As an example, consider two convenience subclasses for TosTypeAttribute: TOS1Attribute and TOS2Attribute. Those are just shortcuts to allow [TOS1] or [TOS2].
Report repository for TOS1 could be either marked with attribute or places into namespace (or both) but just putting into namespace is cleaner:
The types when discovered may be stored in a thread-safe dictionary by ReflectedRepositoryTypeCache. This eliminates the need for runtime reflection on every request so performance loss may be prevented. Lazy loading technique is leveraged on per-TOS-type basis in some examples, although other techniques could be used.
One example of the aforementioned process is illustrated in
To address the general service resolution issue and obtain the ability to follow the Dependency Inversion Principle, an IServiceResolver contract is introduced.
IServiceResolver may resolve any service for supplied type (be it an interface or concrete type) and any of its specific implementation may be capable of performing “constructor injection” which is the primary technique of Dependency Injection.
Note that IServiceResolver doesn't represent some particular infrastructural part and only works at .NET type level. ServiceResolver is very generic and is capable of resolving any kinds of program components.
Program components may not contain any initialization code for their dependencies. They may only receive configured instances through their constructors and may never care where those instances came from. This eliminates close coupling altogether. There may be only place in the application where all the components are wired up. It can be treated as the “Application Architecture Hub”. As one example: Get Report Repository for TOS 1 to process GetImportContainer request for a terminal using TOS 1 from User.
In one specific example of
The StructureMap library is used as a “backing” technology behind IServiceResolver. This may not introduce any dependency on StructureMap because of IServiceResolver design. Any other implementation of IServiceResolver could be easily supplied without changing a single line of code.
The repository concrete type may be configured in “IoC container registry”. Also, no one except container registry may be aware of configured concrete type for IRepositoryFactory. ServiceAppRegistry class is an “IoC container registry” using StructureMap and used to configure repositories and repository factories.
In some embodiments, such as that shown in the code below and illustrated in
A TOS 1 database 1408 may be read for appointment data 1410 and corresponding container data 1412 that may be provided in tables in a TOS 1 specific format. The data 1410 and 1412 may be read and transmitted over a network to TOS 1 repository instance component/processing 1406. A similar process may occur for each of TOS 2 repository instance component/processing 1416 and TOS 3 repository instance component/processing 1422. The TOS 2 data source 1414 may be stored in a file system where appointment/container data 1418 are stored in a TOS 2 specific format different from the TOS 1 format and TOS 3 format once they are read and transmitted to the TOS 2 repository instance component/processing 1416. The TOS 3 data source may be an API where appointment detail API and corresponding container detail API data are read and transmitted to the TOS 3 repository instance component/processing in a TOS 3 specific format. In
Each TOS repository instance component/processing 1406, 1416 and 1422 may perform processing to process/transform the data of a TOS specific format retrieved from a corresponding database into the business object format that is a TOS agnostic format. In
Conventionally, a user who wishes to access data of terminal sites using different Terminal Operating Systems may need to access an interface specific to the Terminal Operating System of that terminal site. However, consistent with aspects of the present innovations, requests for data are processed regardless of the Terminal Operating System used such that each user 1502, 1504 is able to access any desired terminal site. At step 1508, a request for data may be received for any or both Terminal A and Terminal B by the TOS agnostic system. For example, a user interface provides a list of terminals for a user to select. At step 1510, a TOS type may be determined based on the request. The system may determine correspondence between a selected terminal and the TOS associated with the terminal. Based on the determined TOS type, a repository instance may be constructed for the Terminal requesting data. The construction of the repository instance is discussed in greater detail below in
However, if no repository instance is located that corresponds to the appointment request 1730, then a create repository function 1736 may be called to generate a appointment repository 1738. Once created, the repository locator 1722 may call a get appointment data 1740 function to the repository 1738 to retrieve the requested appointment data from the data source 1728. The repository 1738 then may call a get appointment data 1742 function to the data source 1728 to obtain the requested appointment information. In response, the data source 1728 may return appointment entities 1744 in a format of the data source to the repository 1738. The repository 1738 then may perform processing on the appointment entities 1744 to map/convert/transform them into appointment business objects 1746 in a data source agnostic format.
The appointment objects 1746 are then transmitted from the repository 1738 to the repository locator 1722 which may process the appointment objects 1746 into appointment details 1748. The repository locator 1722 then may transmit the appointment details 1748 to the browser 1720 in response to the appointment request 1730. In this system, the browser needs not be compatible with the operating system or data format of the data source 1728 in order to request and receive information from the data source 1728 since the appointment entities 1744 are processed into appointment objects 1746 that are data source agnostic.
In some embodiments, the TOS agnostic system performs repository processing including instantiating a first repository instance for a first TOS type. For example, first data is requested using the first repository instance and a first database service to access a data source for a specific site. A first business object may be constructed using the first data and the first business object is presented to a user as a first TOS-agnostic output. A second repository instance may be instantiated for a second TOS type. Second data is requested using the second repository instance and a second database service to access a data source for a specific site. A second business object may be constructed using the second data and the second business object is presented to a user as second TOS-agnostic output. A third repository instance may instantiated as a web service that accesses third data from a third TOS type directly. A third business object may be constructed using the third data and the third business object is presented to a user as third TOS-agnostic output.
In some embodiments, the TOS agnostic system performs repository processing including instantiating a repository instance for a TOS type. Data may be requested using the repository instance and a database service to access a plurality of data sources for a specific site. A first business object may be constructed using the data and the first business object is presented to a user as a TOS-agnostic output.
In some embodiments, the TOS agnostic system performs repository processing including instantiating a first repository instance for a first TOS type. For example, data is requested using the first repository instance and a first database service to access at least one data source for a specific site. A first business object may be constructed using the first data and the first business object is presented to a user as a first TOS-agnostic output. A second repository instance may be instantiated for a second TOS type. Second data is requested using the second repository instance and a second database service to access the at least one data source for the specific site. A second business object may be constructed using the second data and the second business object is presented to a user as second TOS-agnostic output.
In some embodiments, the TOS agnostic system performs repository processing including instantiating a first repository instance for a first TOS type. For example, data is requested using the first repository instance and a first database service to access at least one data source for a specific site. A first business object may be constructed using the first data and the first business object is presented to a user as a first TOS-agnostic output. A second repository instance may be instantiated for a second TOS type. Second data is requested using the second repository instance and a second database service to access at least one data source for a specific site. A second business object may be constructed using the second data and the second business object is presented to a user as second TOS-agnostic output. A third repository instance may instantiated as a web service that accesses third data from a third TOS type directly. A third business object may be constructed using the third data and the third business object is presented to a user as third TOS-agnostic output.
PA.Tos.smartWeb.WebUI at step 1910 represents a server component that may be built based on MS ASP.NET MVC framework. This component may be designed based on a Model-View-Controller (MVC) design pattern and may be responsible to receive and process user requests and construct and send responses to users. Next, PA.Tos.smartWeb.Service 1912 may be a service component that receives user requests from the Controller in PA.Tos.smartWeb.WebUI component. The service component may call methods in repositories to process user requests. The service component may retrieve data from repository, send data to repository to update data source, process business logic, and construct responses and return responses to Controller in PA.Tos.smartWeb.WebUI component. PA.Tos.smartWeb.Repositories 1914 may be a server component that implements Repository Locator which instantiates Repository instance for a terminal and TOS type depending on the user request.
PA.Tos.smartWeb.Repository.Database2 1924 may be a Repository instance for a specific database of a TOS. The Repository instance may know a type of the database, how to communicate with the database, where is the database, etc. Repository instance may construct business entities from data specific to TOS type or convert any information in business entities to data be used in TOS specific database.
PA.Tos.smartWeb.Repository.WebService 1926 may be a Repository instance used to retrieve or send data to TOS data source using Web Service. The Repository instance may know a type of web service, service contract, data contract, operation contract, how to communicate, where is the service access, etc. Repository instance may construct business entities from data specific to TOS type or convert any information in business entities to data be used in TOS specific data source.
Next, the GetAppointment method is defined in the appointment service to call the GetAppointment method of the appointment repository to request the appointment information corresponding to container number CNTR123456 of Terminal A. GetAppointment method accesses the appointment database and obtains the requested appointment information as appointment entities. The appointment entities are then stored in the appointment repository as appointment objects. For instance, the appointment entities retrieved from the Appointment database as raw data that are converted/translated into an appointment business object. The appointment objects 2136 are then returned to the appointment service.
Further, GetContainer is an internal method call to retrieve container information related to the requested appointment. Similar to the GetApptRepository method, the appointment service executes a GetTosLookUpRepository method to the repository factory to obtain container information corresponding to the appointment information requested by the user. GetInstance method requests a TosLookUp repository instance for the Terminal A. The GetContainer method implemented by the appointment service requests the container data related to the appointment information from the Tos lookup repository. The tos lookup repository retrieves data related to the container corresponding to the container number from the Terminal A database using the GetContainer method. In response, the Terminal A database transmits the requested data as container entities. The appointment entities and container entities are provided in the format of the Terminal A operating system incompatible with the format of other Terminal Operating Systems. Therefore, the tos lookup repository converts/translates the raw container data of the Terminal A into a container object to be added to the container repository. Once the appointment object and corresponding container object are returned to the appointment service, then the appointment and container objects collection are returned to the TOS Agnostic service. The TOS Agnostic service processes the business object data and displays appointment and container objects to the user via a web-based user interface including mobile devices and personal computers, as shown in more detail in connection with
With regard to certain features and functionality herein, the TOS-Agnostic computer code contained in the compact disks submitted in application Ser. No. 13/987,447, filed Jul. 24, 2013, is hereby incorporated herein by reference if/as needed with regard to sub (dependent) TOS-Agnostic features circumscribed therein.
In addition to the basic architectural features set forth above, the service layer may serve as a baseline for integration for/between various illustrative components that may be associated with the TOS interfaces/Terminal Operating Systems herein, e.g., other web applications and Terminal Operating Systems like M21, with respect to which various implementations herein may communicate. Here, for example, the present disclosure and Appendices herein shows how various functionality and information is passed and processed between web applications and a TOS (e.g., M21) via or throughout the service layer. For example, computer program code associated with M21 helping illustrate such features is contained in the “TOS Data Access Library” of the attached compact disc.
With regard to Equipment Interchange Report (EIR) features, generating EIR may be a data and business logic-intensive process. Many data are collected from one or more TOS databases, such as an M21 database, and archived database(s). Those data are manipulated in various process and applied business logic to be presented in printed format. Further, gate-activity modules in disparate systems or web applications may implement such processes and maintain them separately. In some implementations, ReportService functionality may be utilized to provide with all data for EIR to be used for presentation but hide details of business logic and data access processes. This improves the maintainability and extensibility of the application.
Here, it is specifically reiterated that the features described above and below should also be understood in connection with the associated computer code appendices and Appendices 1-4 submitted herewith. Certain features and functionality shown and described at one level of detail herein are provided in greater detail via such appendices. Further, many of the systems and processes described above, as well as other features and functions, may be employed with, supported by, and/or interact with various user interfaces. In one aspect, the systems and methods provided herein include multiple interfaces, e.g., accessible via internet connection and/or other network connection. In some embodiments, an interface combines the functionalities of a summary report and status update, which allows a user to access, review and update statuses of various elements in the shipping process.
Any information that can be reviewed and updated includes but is not limited to information relating to: Appointments (see, e.g.,
It should be noted that any reference to a menu or drop down menu can include any number of data entry fields, and is not limited to drop down menus. Free text boxes can be used, auto populated text entry boxes, radio button selection, or any number of menu selection options can be used. Various specific illustrations herein are for exemplary purposes only.
The systems and methods herein also allow for various interfacing with other applications such as VRU/IVR (Voice Response Unit/Interactive Voice Response) and the VoyagerTrack system. However, any network-based device can be used to access the system.
The appointment system 2204 may include and/or involve one or more computers and may have its own appointment database 2208. The appointment system 2204 may maintain appointment data in the appointment database 2208. The appointment system 2204 may also be in communication with one or more TOS data repositories. In the example of
The appointment system 2204 may make it possible for users to use one appointment system 2204 for different terminals using different TOS 2224, 2228 in the same geographic area. Moreover, users may view and manage multiple terminals in the one appointment system 2204. For example,
Notification Agent
Notification Agent may be an application for evaluating notification requests and performing other background processing tasks. It may run in the background of the other processes described herein and may evaluates the following notification requests based on scheduled jobs, for example: Availability Request, On Hold Request, Enter Gate Request, Exit Gate Request, Booking Valid Requests, Container Ready for Appointment Request, Demurrage Notification Request, or a combination thereof.
After evaluation of each request to determine whether the request is satisfied by looking in the various database tables, the Notification Agent may set the Request Status value, which may be used to send a notification to a user. A Customer Service Manager in the Notification Agent may group together all notifications of a single user and send the notifications by emails, Faxes, or text messages, for example.
As shown in
The Request Evaluators 2330 may check the status of a container as per the Notification Request stored in database. If the current conditions of the container match the request conditions, the request will have been considered as Satisfied or Completed. For example, for the Availability case, the Request may be satisfied when the container becomes Available. The request may become Invalid if the current condition is such that the condition requested cannot be achieved. In the Availability case, for example, if the container is found to be Inland before it is detected as Available, then the corresponding request becomes Invalid. After Evaluation, the requests may be updated with the changed status. If there are any errors during evaluation of a request, is the request may be marked as such and re-evaluated during the next cycle.
The TMF Release requests may be created implicitly when the user registers for Availability requests or specifically in the “Register All” or in the “Customize Requests” pages in the UI. The TMF Release evaluator may check in the TOS tables for release status and update the request as satisfied. The TMF status may become Released or go back to a TMF Hold status, for example.
The evaluators inherit from the base class, which may contain processing logic common to all the evaluators. This common logic may call methods in the subclasses for specific logic.
The Container Notification Senders may group all the notifications of a user in a single email, Fax, or text message and send the message. If any error occurs during the sending of the message, an attempt may be made to send the message in the next cycle. The request may be marked as Sent after successful sending.
The TMF Notification sender may combine the TMF Release and Reversal Emails in a single message and send it.
The timer interval evaluation period and some settings may be read from the configuration file.
The timer interval evaluation period may be read from the config file. The settings may be stored as part of UserPreferences stored in the ADMIN database in the USER_SITE_CONFIG table.
Trouble Notification may send details of Trouble Info to all users who have registered for Trouble notifications. The notification may be sent based on users whose truckers are associated with the trouble transactions. Container Notifications may be sent on a per request basis as requested by user, though they may be grouped at sending time.
This notification may be sent by a container ready for appointment evaluator/sender module 2366 when a container becomes ready for making an appointment. Due to various import container related reasons a container may not be ready for making appointments. In such a case the user may request that a notification be sent when the container becomes ready. All notifications of a user may be grouped together in a single message. This notification may apply to Import Appointments only in some embodiments.
This notification may be sent by an appointment canceled evaluator/sender module 2362 when an appointment gets cancelled due to limits being cancelled or modified in Set Limits. In Set Limits, if the Appointment Admin deletes slots which have appointments made, then these appointments may be marked as being cancelled. This evaluator may check all such appointments and send messages to users whose appointments got cancelled. All notifications of a user may be grouped together in a single email. All types of appointments could get cancelled.
When the user makes an Empty In Appointment for a container that has a status of “Requires Authorization”, the status of the appointment will be “Pending”. In this case a message may be sent by an SCCO authorization request sender module 2364 to the SSCO requesting Return Authorization for the container. The SSCO may authorize the container return by performing operations that update the TOS table xxxxx. This message may be sent only if the SSCO has allowed the sending of the email for this purpose in some embodiments.
This notification may be sent by a trucker authorization warning sender module 2368 to the user who made the appointment. When it is detected that the SSCO has not authorized the return of the Empty container and the appointment is less than 2 hours away, this notification may be generated and sent. The timer interval evaluation period and some settings may be read from the config file. Some other settings related to these notifications are stored in the database.
As shown in
TOS may set the appointment status to Initiated for all Appointment types when a transaction starts. The above updater modules may ignore all “Pseduo” appointments, which are those created by TOS. They may process appointments which are created from Web/VRU. The CREATED_FROM field may be used for this purpose.
The container snapshot creator module 2377 may create container statistics related to occupancy, or user having kept the appointments etc. These may be displayed in the Set Limits screens, and the Limits Reports. The data may be updated in the APPT LIMITS table.
The hidden container checker module 2379 may unhideEmpty-In containers which have valid Dual appointments. Users may hide containers in the Empty-In Return Checker page. Only those containers which do not have any appointments may be hidden. An Empty In appointments may have an Import appointment as a dual. This dual appointment may be made in the Imports appointments module. This process may check all the hidden containers for any Imports appointments, and if any hidden containers are found to have an Imports appointments, then they may be marked as Unhidden. These containers may show in the Empty In Checker page when the user does a query that returns the container.
The timer interval evaluation period and some settings may be read from the config file. The various other settings related to these notifications may be stored in the SITE_CONFIG table.
According to implementations herein, a truck company profile is provided for a truck line company authorized to receive and deliver equipment to the terminal. Each truck line company may include a plurality of trucks.
According to some implementations, in order to enter the NOLA terminal, each truck is required to have an RFID tag. This RFID tag is required to support the Call Forward and Gate processes. The RFID tag is registered with the truck company and the management of these tags. Terminal Administrators may create RFID tags in batches and assign a predetermined number of batches to different trucking companies. Truck Company Administrators may manage the RFIDs and assign them to individual trucks. Maintenance of RFID tags is done by a RFID registration page.
According to some implementations, truck companies have a defined list of trucks which are authorized to receive and deliver equipment to the terminal. Each truck has unique truck number that is known as UTN. Each truck line has assigned to it a UTN range. A truck company administrator or terminal administrator may then assign an RFID to UTN. Assignment of RFID and UTN is performed via a truck maintenance screen.
For instance, in
In some embodiments, the TOS agnostic system performs repository processing including instantiating a first repository instance for a first TOS type. First data is requested using the first repository instance and a first database service to access at least one data source for a specific site. A first business object may be constructed using the first data and the first business object is presented to a user as a first TOS-agnostic output. A second repository instance may be instantiated for a second TOS type. Second data is requested using the second repository instance and a second database service to access at least one data source for a specific site. A second business object may be constructed using the second data and the second business object is presented to a user as second TOS-agnostic output. A third repository instance may instantiated as a web service that accesses third data from a third TOS type directly. A third business object may be constructed using the third data and the third business object is presented to a user as third TOS-agnostic output. The business objects may include appointments in multiple terminals using different TOSs.
In some embodiments, the TOS agnostic system performs repository processing including instantiating a first repository instance for a first TOS type. First data is requested using the first repository instance and a first database service to access at least one data source for a specific site. A first business object may be constructed using the first data and the first business object is presented to a user as a first TOS-agnostic output. A second repository instance may be instantiated for a second TOS type. Second data is requested using the second repository instance and a second database service to access at least one data source for a specific site. A second business object may be constructed using the second data and the second business object is presented to a user as second TOS-agnostic output. A third repository instance may instantiated as a web service that accesses third data from a third TOS type directly. A third business object may be constructed using the third data and the third business object is presented to a user as third TOS-agnostic output. The business objects may include import reports in multiple terminals using different TOSs.
For example, a method of processing information involving terminal operating systems may comprise some or all of the following actions. Information may be provided for display, to a user, of an interface comprising terminal operating system appointment functionality and an input field to receive a user input, the information comprising first information that includes container information and second information that includes appointment information. Information related to the user input, received via the interface, may be processed to manage the terminal operating system appointment functionality. Processing may be performed to generate an output/result to transmit instructions within the system, to a third party, or a combination thereof; execute the terminal operating system appointment functionality in the system such that an output of a result of the managed terminal operating system appointment functionality is produced; or a combination thereof. The user input may comprise a command to establish a truck container appointment, modify a truck container appointment, search truck container appointments, delete a truck container appointment, view a truck container appointment, or a combination thereof. The truck container appointment may comprise an import appointment, an export booking appointment, an empty in-container appointment, or a combination thereof. The output may comprise an established truck container appointment, a modified truck container appointment, a search result including a truck container appointment, a deletion of a truck container appointment, a display of a truck container appointment, or a combination thereof. The truck container appointment may comprise an import appointment, an export booking appointment, an empty in-container appointment, or a combination thereof. Performing processing to generate an output/result may comprise retrieving container information, appointment information, or a combination thereof from a repository, a data source, or a combination thereof. Performing processing to generate an output/result may comprise validating a container. Performing processing to generate an output/result may comprise saving information related to an appointment in a repository, a data source, or a combination thereof. The output may comprise container information, appointment information, validation information, save confirmation, or a combination thereof.
For example, a method of processing information involving terminal operating systems may comprise some or all of the following actions. Information may be provided for display, to a user, of an interface comprising terminal operating system appointment functionality and an input field to receive a user input, the information comprising first information that includes container information. Information related to the user input, received via the interface, may be processed to manage the terminal operating system appointment functionality. Processing may be performed to generate an output/result to transmit instructions within the system, to a third party, or a combination thereof; execute the terminal operating system appointment functionality in the system such that an output of a result of the managed terminal operating system appointment functionality is produced; or a combination thereof. The user input may comprise a command to establish a truck container import report, modify a truck container import report, search truck container import reports, delete a truck container import report, view a truck container import report, or a combination thereof. The truck container import report may comprise container information, appointment information, availability information, or a combination thereof. The output may comprise an established truck container import report, a modified truck container import report, a search result including a truck container import report, a deletion of a truck container import report, a display of a truck container import report, or a combination thereof. Performing processing to generate an output/result may comprise retrieving container information, appointment information, or a combination thereof from a repository, a data source, or a combination thereof. Performing processing to generate an output/result may comprise calculating an availability. The output may comprise container information, appointment information, availability information, or a combination thereof.
For example, a method of processing information involving terminal operating systems may comprise some or all of the following actions. Information may be provided for display, to a user, of an interface comprising terminal operating system notification functionality and an input field to receive a user input, the information comprising first information that includes notification information related to a truck container. Information related to the user input, received via the interface, may be processed to manage the terminal operating system notification functionality. Processing may be performed to generate an output/result to transmit instructions within the system, to a third party, or a combination thereof; execute the terminal operating system notification functionality in the system such that an output of a result of the managed terminal operating system notification functionality is produced; or a combination thereof.
The user input may comprise a command to register an import availability/hold status, modify an import availability/hold status, search import availability/hold statuses, delete an import availability/hold status, view an import availability/hold status, or a combination thereof. The output may comprise a registered import availability/hold status, a modified import availability/hold status, a search result including an import availability/hold status, a deletion of an import availability/hold status, a display of an import availability/hold status, or a combination thereof.
The user input may comprise a command to register a traffic migration fee release/release reversal notification, modify a traffic migration fee release/release reversal notification, search traffic migration fee releases/release reversal notifications, delete a traffic migration fee release/release reversal notification, view a traffic migration fee release/release reversal notification, or a combination thereof. The output may comprise a registered traffic migration fee release/release reversal notification, a modified traffic migration fee release/release reversal notification, a search result including a traffic migration fee release/release reversal notification, a deletion of a traffic migration fee release/release reversal notification, a display of a traffic migration fee release/release reversal notification, or a combination thereof.
The user input may comprise a command to register a demurrage notification, modify a demurrage notification, search demurrage notifications, delete a demurrage notification, view a demurrage notification, or a combination thereof. The output may comprise a registered demurrage notification, a modified demurrage notification, a search result including a demurrage notification, a deletion of a demurrage notification, a display of a demurrage notification, or a combination thereof.
The user input may comprise a command to register a booking valid notification, modify a booking valid notification, search booking valid notifications, delete a booking valid notification, view a booking valid notification, or a combination thereof. The output may comprise a registered booking valid notification, a modified booking valid notification, a search result including a booking valid notification, a deletion of a booking valid notification, a display of a booking valid notification, or a combination thereof.
The user input may comprise a command to register an exit gate notification, modify an exit gate notification, search exit gate notifications, delete an exit gate notification, view an exit gate notification, or a combination thereof. The output may comprise a registered exit gate notification, a modified exit gate notification, a search result including an exit gate notification, a deletion of an exit gate notification, a display of an exit gate notification, or a combination thereof.
The user input may comprise a command to register an enter gate notification, modify an enter gate notification, search enter gate notifications, delete an enter gate notification, view an enter gate notification, or a combination thereof. The output may comprise a registered enter gate notification, a modified enter gate notification, a search result including an enter gate notification, a deletion of an enter gate notification, a display of an enter gate notification, or a combination thereof.
The user input may comprise a command to register a standing notification, modify a standing notification, search standing notifications, delete a standing notification, view a standing notification, or a combination thereof. The output may comprise a registered standing notification, a modified standing notification, a search result including a standing notification, a deletion of a standing notification, a display of a standing notification, or a combination thereof.
In some implementations, a user makes a request to create an appointment repository instance for particular TOS will and appointment data will be modified against data in the TOS. Some of the repository methods for dual appointments may include the following exemplary code:
As illustrated in
For empty out, an empty out appointment is created 2422E. A determination is then made whether booking information is available 2424E. If not, then booking information from the TOS is retrieved 2420E. If booking information is available, 2424E, then the UTN information is the same as for the In move 2426E. Similarly, the limit and time slot is the same as the In move 2428E. Size, type, and chassis information are then input 2430E. The information is sent to the appointment data source 2416E.
As illustrated in
In
A user 2402I, 2404I and 2406I provide information to create RFIDs for terminal 1 or terminal 2 2408I. The user may be a terminal administrator for any of a plurality of terminals. An RFID repository instance is constructed connecting to appointment data source 2410I. Data is received and an RFID object is constructed for each terminal and data is transmitted 2412I. Existing data for the RFID from the appointment database is requested 2414I. Data on RFID registration is displayed 2416I.
A user 2402J, 2404J and 2406J provides information to create truck line terminal 1 or 2 2408J. The user may be a truck company manager for different truck companies for any of a plurality of terminals. A truck company repository instance is constructed connecting to appointment data source 2410J. Data is received and a truck line object is constructed for each truck line and data is transmitted 2412I Existing data for the truck line from the appointment database is requested 2414J. Data on a truck company profile is displayed 2416J.
In particular, in
For booking inquiries, an initial validation processing is performed to determine if the status of the booking is valid, booking not found or past booking (where ship/cargo departed). If the status of the booking is not found in the TOS, then a dispatcher (e.g., trucking company) is notified to reach out to the steamship company to determine why the booking information is not present in the TOS. This feature prevents users from contacting the port terminal directly, so as avoid a step previously undertaken. Furthermore, the validation process performed prevents the setting of an invalid appointment where, for example, a truck arrives to deliver cargo when a ship has already departed.
If a bill of lading is valid, then appointment details 2539 will appear for a user to make an appointment. A bill of lading inquiry will return one of a valid bill of lading, bill of lading not found or all containers delivered on bill. If a valid status is returned, then a user can make an appointment to pick up cargo. A first validation process is performed to provide one of the three statuses discussed above. Then, for a valid status, a second validation process is performed. A user is able to make the appointment, and review freight status, customs status, and other hold information. A hold status may indicate hold or released. If a hold is in place, the user may still make an appointment and returns a pending status, not active/completed status. If a user makes the appointment while under a hold, the system may automatically advance the status/processing once the hold is lifted so as to automatically switch the status from pending to active. Under a pending status, a notification is processed and includes reason for the pending/hold status. Then, when the status switches to active, another notification is generated to a user that indicates the next available steps (e.g., deliver or pickup cargo).
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 the bill of lading information corresponding to BOL number BK123456 of Terminal A. FindBOL method 2576 accesses the Terminal A database and obtains the requested bill of lading information from the Terminal A database as BOL entities 2578. The BOL entities 2578 are then stored in the BOL repository 2572 as bill of lading objects 2560. For instance, the BOL entities 2578 retrieved from the Terminal A as raw data that are converted/translated into a bill of lading business object 2560. The bill of lading objects 2560 are then returned to the import service 2544.
Further, GetContainer 2562 is an internal method call to retrieve container information related to the requested bill of lading. Similar to the GetBOLRepository method, the import service 2544 executes a GetContainer method 2568 to the repository factory 2554 to obtain container information corresponding to the bill of lading information requested by the user. GetInstance method 2564N requests a container repository 2580 instance for the Terminal A. The GetContainers method 2568 implemented by the import service 2544 requests the container data related to the bill of lading information from the container repository 2580. The container repository 2580 retrieves data related to import containers corresponding to the bill of lading number from the Terminal A database using the GetContainers method 2584. In response, the Terminal A database transmits the requested data as container entities 2586. The BOL entities 2578 and container entities 2586 are provided in the format of the Terminal A operating system incompatible with the format of other Terminal Operating Systems. Therefore, the container repository 2580 converts/translates the raw container data 2586 of the Terminal A into a container object 2570 to be added to the container repository 2580. Once the BOL object 2560 and corresponding container object 2570 are returned to the import service 2544, then the bill of lading and container objects collection 2546 are returned to the TOS Agnostic service 2534. The TOS Agnostic service 2534 processes the business object data 2546 and displays bill of lading and container objects 2548 to the user via a web-based user interface.
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 the EDO information corresponding to EDO number BK123456 of Terminal A. FindEDO method 2576N accesses the Terminal A database and obtains the requested EDO information from the Terminal A database as EDO entities 2578N. The EDO entities 2578N are then stored in the EDO repository 2572N as EDO objects 2560N. For instance, the EDO entities 2578N retrieved from the Terminal A as raw data that are converted/translated into a EDO business object 2560N. The EDO objects 2560N are then returned to the empty service 2544N.
Further, GetContainer 2562N is an internal method call to retrieve container information related to the requested EDO. Similar to the GetEDORepository method, the empty service 2544N executes a GetContainer method 2568N to the repository factory 2554N to obtain container information corresponding to the EDO information requested by the user. GetInstance method 2564N requests a container repository 2580N instance for the Terminal A. The GetContainers method 2568N implemented by the empty service 2544N requests the container data related to the EDO information from the container repository 2580N. The container repository 2580N retrieves data related to empty containers corresponding to the EDO number from the Terminal A database using the GetContainers method 2584N. In response, the Terminal A database transmits the requested data as container entities 2586N. The EDO entities 2578N and container entities 2586N are provided in the format of the Terminal A operating system incompatible with the format of other Terminal Operating Systems. Therefore, the container repository 2580N converts/translates the raw container data 2586N of the Terminal A into a container object 2570N to be added to the container repository 2580N. Once the EDO object 2560 and corresponding container object 2570N are returned to the empty service 2544N, then the EDO and container objects collection 2546N are returned to the TOS Agnostic service 2534N. The TOS Agnostic service 2534N processes the business object data 2546N and displays EDO and container objects 2548N to the user via a web-based user interface.
In
The pop-up windows and associated features shown in
Various Notification Configurations 2906 features, GUI options and functionality may be provided. Referring to
As a function of the administrator features and functionality performed via
In some implementations, the integration of the VoyagerTrack (VT) appointment system with the Terminal Operating System (TOS), Terminal Truck Queuing System and the Gate System facilitates the streamlining of truck traffic through the terminal by providing dispatchers/truck drivers with pre-arrival advice of their planned move and verification of a justified purpose for arriving at the terminal. Which is validated against the terminal operating system, allowing errors or missing information to be corrected before the truck is dispatched to the terminal. In addition, the integrated data can streamline gate operations by providing auto-gate capabilities. For example, by recognizing through Optical Character Recognition (OCR) and Weigh-In-Motion (WIM) this equipment data may be utilized to match the appointment equipment with the equipment arriving at the gate pedestals.
In some implementations, a VT Return Appointment Status API is provided to determine if the truck arriving at the terminal has a valid appointment and thereby has a justified purpose for arriving at the terminal. Upon the arrival of a truck to the terminal truckway, an API request will be issued to the appointment system for the current appointment status. The appointment system will receive RFID (Radio Frequency Identification) tag number and the arrival time of the truck. Utilizing this information, the appointment system will locate the best appointment matching the RFID and timeslot and return to the Terminal Truck Queuing System the status of the matching appointment. Additionally, the appointment system will send a notification to the truck driver via text and/or email message informing the trucker of the appointment status. The appointment status results include at least one of the following 4321: active appointment results in a Call Forward notification instructing the driver to proceed to the In Gate or the receipt of either a Pending Appointment or No Appointment notification 4319 in which the driver must contact dispatch for assistance. Once the dispatcher corrects the appointment 4323 the updated appointment status will be available for the driver either via a wall mount display or receipt of an updated notification via a text/email message 4321.
At the In gate pedestal the appointment equipment is matched 4415 with the previously captured OCR equipment data or equipment data manually entered by the gate clerk via pedestal cameras 4413. If the equipment data from the appointment does not match the receiving equipment then the truck is requested to exit the terminal 4417 otherwise the truck may proceed into the yard 4409.
In order to find the target appointment, a series of Matching Methods may be performed until a good target appointment match result is found. Once a good result is found, then no other Matching Methods need to be executed. These Matching Methods are listed in the order in which the routine will attempt to find the best target appointment. (i.e., start with Method 1, if appointment not found then continue to Method 2, 3, and 4 as needed). The only time the matching will return a result of No Appointment Found is if every method below fails to return a result. A set of exemplary, though non-limiting matching methods are described below.
According to a first, illustrative matching process, a UTN has an initiated appointment or In Yard Holding Area (IYHA) Single Out appointment. The first method may include plurality of parameters including Arrival Date/Time, RFID/UTN (Unique Truck Number), Location, Initiated Indicator, First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number), wherein Arrival Date/Time corresponds to utilizing the Truck Arrival Date matching only appointments with the same date, RFID/UTN corresponds to utilizing UTN or RFID numbers to find the UTN from the Truck Profile if provided (may be required), location corresponds to the current location of the Truck at the time the Get Target Appointment request, Initiated Indicator corresponds to yes, First Container corresponds to First Container not used, Second Container corresponds to second container not used, Chassis Number corresponds to not used, and Chassis LPN (License Plate Number) corresponds to not used.
The first matching process may include two parts including a Single Out and Initiated Appointments. For the first part 4611, the Single Out appointment is checked wherein only if location is IYHA, then best timeslot or candidate active or pending Single Out Move that match the same Date and UTN specified in the parameters are returned. This method is utilized to assign a pick-up move to a UTN if they are already on terminal and their previous pick up move was canceled. Once a truck is in the terminal yard their appointment is initiated. The second part of these method 4612 queries for ALL initiated appointments matching the date and UTN specified. If no Initiated Appointment is found, then continue to the second and third matching method until an Initiated Appointment is found. These additional steps are required for One-Time Visit trucks that do not have UTNs).
The following scenarios illustrate possible situations relevant to the first matching method. For instance, as a truck enters the OutGate pedestal, the gate system will query the appointment system for all its initiated appointments for status processing to either Complete or Cancel based on TOS Transaction status. If a driver is directed to IYHA due to a trouble ticket then this method will return its Initiated appointments for trouble processing within the gate system and TOS system. For an assignment of a new Single Out Appointment where a dual move at the in-gate where in-move is active and out-move is pending and must be canceled by the clerk at the Pre-Gate pedestal via the TOS. The gate system will send the appointment system the outbound appointments for cancellation in which appointment system will unpair and un-initiate the out-move appointment(s). The driver is instructed to go to IYHA to pick up his new out-move instruction. From the IYHA, if the UTN is requesting a new appointment then the dispatcher must have created the appointment as either a Slotted or Candidate Single Out appointment assigned to the same UTN for the first matching method to find it. In the unlikely event that there are multiple Single Out appointments for the same date and same UTN, then the timeslot logic will determine the best appointment.
According to a second, illustrative matching process, Container Equipment is provided by the Gate System. The second method may include plurality of parameters including Arrival Date/Time, RFID/UTN, Location, Initiated Indicator, First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number), wherein Arrival Date/Time corresponds to utilizing the Truck Arrival Date matching only appointments with the same date, RFID/UTN corresponds to utilizing UTN or RFID numbers to find the UTN from the Truck Profile if provided (optional), location corresponds to the current location of the Truck at the time the Get Target Appointment request, wherein if Initiated Indicator corresponds to yes, then Initiated Appointments are included, and if no, then Initiated Appointments are excluded, First Container corresponds to First Container required, Second Container corresponds to second container optional and use if available, Chassis Number corresponds to not used, and Chassis LPN (License Plate Number) corresponds to not used.
The second matching process is executed only if the gate system sends a good OCR read or gate clerk entered Container number. The container number is the most important equipment match so once an appointment is found matching with the same container, then that result is returned and the matching process stops. If the UTN specified then it MUST match the appointment to qualify as a target appointment. In the unlikely event that multiple appointments for the same container are found, then the timeslot logic should narrow it down to the closest appointment for that UTN.
If the Initiated Indicator is yes 4621 for All Initiated Candidate and Slotted appointments, then utilizes the date, and other available equipment data, such as the RFID/UTN and Container number search appointment system for initiated appointments that match the equipment data specified. If the UTN specified then it MUST match the appointment to qualify as a target appointment. On the other hand, if the Initiated Indicator is no 4622 then search appointment system for Active/Pending (Single In, Dual In), if the UTN is specified then it must match the appointment to qualify as a target appointment. As for a tie breaker, if more than one appointment is found with the same container number specified or if 2-20's through the OCR matches with two different target appointments (i.e., one container matched one appointment and the other container number matches another), then the Timeslot logic will be utilized to further reduce the result set. For the final Tie-Breaker, the earliest Appointment ID is used assuming that the primary equipment appointment for a multi-equipment appointment would be entered first.
The following scenarios illustrate possible situations relevant to the second matching method. For InGate, as a truck enters the In Gate Pedestal the gate system will query the appointment system for all target appointments that are active and pending for In Gate Processing utilizing all equipment data available (either via OCR data or entered by clerk). Here, the Initiated Indicator is no. For IYHA Trouble, if a one-time visit driver (i.e., Truck has no UTN number but has a Container number) is directed to IYHA due to a trouble ticket where TOS transaction is in Yard. Here, the Initiated Indicator is yes. This method will query for Initiated appointments utilizing the clerk entered Container Information searching the appointment system. For IYHA OOG (Out of Gauge) InGate, the OOG cargo that cannot be processed via the In Gate Portals, the cargo is directed to IYHA for InGate Processing utilizing equipment data manually entered by the clerk. Here, the Initiated Indicator is no.
According to a third, illustrative matching process, Chassis Equipment is provided by Gate System. The third method may include plurality of parameters including Arrival Date/Time, RFID/UTN, Location, Initiated Indicator, First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number), wherein Arrival Date/Time corresponds to utilizing the Truck Arrival Date matching only appointments with the same date, RFID/UTN corresponds to utilizing UTN or RFID numbers to find the UTN from the Truck Profile if provided (optional), location corresponds to the current location of the Truck at the time the Get Target Appointment request, wherein if Initiated Indicator corresponds to yes, then only Initiated Appointments are included, and if no, then Initiated Appointments are excluded, wherein First Container and Second Container are optional and not used, Chassis Number is utilized if available, and Chassis LPN (License Plate Number) is utilized if available.
In some implementations, the third matching method may include the following steps. If the Initiated Indicator is yes for All Initiated Candidate and Slotted appointments, then utilizing the Date, and other available equipment data, RFID/UTN and Chassis number search the appointment system for initiated appointments that match the equipment data specified 4631. If UTN is specified it must be utilized in the matching. If No appointments are found, utilize the Chassis number, then attempt to find an Initiated target appointment with the Chassis LPN if Owned Chassis Flag is yes 4632. If Owned Chassis Flag is no, then do not use the LPN in matching. If the Initiated Indicator is no 4633, then utilize the date and other available equipment data such that the RFID/UTN and Chassis number to search the appointment system for only Active or Pending Primary Candidate & Slotted Appointments. If UTN is specified it must be utilized in the matching. If the Owned Chassis Flag is no 4634, then utilize Single In and Dual In Moves only (No Out Moves). If the Owned Chassis Flag is Yes and no Container data was provided by the gate system, then utilize Single In, Dual In, and Single Out Moves. If the Owned Chassis Flag is Yes and Container data was provided by the gate system, then utilize Single In and Dual In (no Out Moves).
If No appointments are found utilizing the Chassis number, attempt to find an Active or Pending Primary Candidate & Slotted Appointment for Single In, Single Out, or Dual In target appointment with the Chassis LPN if Owned Chassis Flag is yes and Container data was not provided by the Gate System 4635. If the Owned Chassis Flag is Yes and Container data was provided by the gate system, then utilize Single In and Dual In (no Out Moves). If the Owned Chassis Flag is No, do not use LPN matching. As for a tie breaker, if more than one appointment is found with the same Chassis/LPN specified, then the Timeslot logic will be utilized to further reduce the result set. For the final tie-breaker, use the earliest Appointment ID assuming primary equipment appointment for a multi-equipment appointment would be entered first. If no match results then continue to a forth matching method.
This method is executed only if the above Container match did not return a result and the gate system sends a good OCR read or gate clerk entered Chassis/LPN data. When multiple appointment(s) are found matching with the same chassis/LPN then the timeslot logic should narrow it down to the closest appointment.
The following scenarios illustrate possible situations relevant to the third matching method. For instance, as a truck enters the InGate pedestal, the gate system will query appointment system for all its target active and pending appointments for the InGate Processing utilizing all equipment data available (either via OCR or clerk entered). Here, the initiated indicator is no.
As a one-time visit truck (i.e., Truck has no UTN number) enters the OutGate pedestal the gate system will send the Chassis equipment information (either via OCR data or entered by clerk) to query the appointment system for all its Initiated appointments for status processing to either Complete or Cancelled based on TOS Truck Transaction status. Here, the Initiated Indicator is yes.
If a one-time visit driver (i.e., Truck has no UTN number) is directed to IYHA due to a trouble ticket, then this method will query for its Initiated appointments utilizing the clerk entered Chassis Information for trouble processing within the gate system and TOS system. Here, the Initiated Indicator is yes.
According to a fourth, illustrative matching process, the RFID/UTN and no other Equipment data is provided by the Gate System. Only the UTN and date/time is utilized in the Bobtail Method 4640. The fourth matching method may be executed when all previous methods 1-3 have failed to return an appointment result.
The fourth process may include plurality of parameters including Arrival Date/Time, RFID/UTN, Location, Initiated Indicator, First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number), wherein Arrival Date/Time corresponds to utilizing the Truck Arrival Date matching only appointments with the same date, RFID/UTN corresponds to utilizing UTN or RFID numbers to find the UTN from the Truck Profile if provided (may be required), location corresponds to the current location of the Truck at the time the Get Target Appointment request, Initiated Indicator corresponds to no. First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number) are not used and should be blank.
The fourth matching process may include the following steps. Utilizing the RFID/UTN number and Arrival Date and Time search only Active and Pending Single Out Bobtail appointments will be searched within the appointment system. As for a tie breaker, if more than one appointment is found with the same UTN Bobtail specified, then the Timeslot logic will be utilized to further reduce the result set. For the final tie-breaker, use the earliest Appointment ID assuming primary equipment appointment for a multi-equipment appointment would be entered first. If no match results then continue to a forth matching method.
The following scenarios illustrate possible situations relevant to the fourth matching method. For instance, for call forwarding, as a truck enters terminal and all that is known by gate system is the RFID/UTN. Here, the Initiated Indicator is no. For InGate, Bob Tail In where all that is known is the RFID/UTN. Here, the Initiated Indicator is no.
According to a fifth, illustrative matching process, the RFID/UTN is provided by Gate System but no other Equipment data is required to be utilized in this matching algorithm. Only the UTN and date/time is required in the Timeslot Logic Method 4650. The fifth matching method may be executed when all previous methods 1-4 have failed to return an appointment result.
The fifth process may include plurality of parameters including Arrival Date/Time, RFID/UTN, Location, Initiated Indicator, First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number), wherein Arrival Date/Time corresponds to utilizing the Truck Arrival Date matching only appointments with the same date, RFID/UTN corresponds to utilizing UTN or RFID numbers to find the UTN from the Truck Profile if provided (may be required), location corresponds to the current location of the Truck at the time the Get Target Appointment request, Initiated Indicator corresponds to no. First Container, Second Container, Chassis Number, and Chassis LPN (License Plate Number) are optionally not used
The fifth matching process may include the following steps. Including the RFID/UTN number and Arrival Date and Time search only Active and Pending Primary Move Candidate and Slotted appointments including Single In, Single Out, Dual In Moves utilizing the Timeslot Logic described elsewhere below. If more than one appointment is found with the Timeslot logic, then the final Tie-Breaker will be the earliest Appointment ID, assuming that the primary equipment appointment for a multi-equipment appointment would be entered first by the dispatcher. If no appointments are returned after utilizing this last method, then return a message of No Appointment Found to the gate system. This method is executed only if the above methods found no match or no equipment data is available such as in the initial Call Forward process when only a UTN and date-time is known.
In some implementations, timeslot matching may be performed in order or precedence with the first matching method being first and if not successful, then moving onto methods 2, 3, 4, etc.
The following scenarios illustrate possible situations relevant to the fifth matching method. Any UTNs where no appointments where returned in the previous processes, 1-4.
The VoyagerTrack appointment system mobile application is a mobile webpage integrated into an appointment system and/or a Terminal Operating System (TOS) and/or other related systems providing users with the ability to retrieve information easily via any mobile browser, such as a smart phone or tablet device.
The mobile application may provide system users with the capability to create/update/delete appointments from a mobile device from almost anywhere, at any time and prior to actual arrival to the terminal. The application may also provide basic terminal information/rules/advisory, terminal location/directions, equipment availability and inventory summary, EIR viewing, and container inventory screen.
The mobile application processing through the TOS via the appointment system may assist in reducing congestion at the gate and streamlining gate transactions by decreasing gate trouble occurrences.
In various implementations as described herein, the various GUIs provided by the mobile interfaces are transmitted and processed by one or more servers, computing devices and/or computer-readable media that may be TOS agnostic systems. The actions performed by the system is provided to a mobile interface or any computing interface.
In some implementations of the invention, a system includes one or more servers, computing devices and/or computer-readable media processing instructions executable by one or more processors for managing an appointment system and/or terminal operating system. The instructions including instructions for processing information for display on the mobile device from an appointment system for a terminal operating system, the information including first information that includes mobile-input appointment information. A mobile interface is provided for receiving user input associated with appointment functionality. One or more processing devices process information related to the user input, received via the mobile interface, to manage the appointment functionality, the processor performing processing to generate an output and/or a result associated with: processing and/or transmitting instructions within the appointment system, to a computing device external to the appointment system, or a combination thereof; executing the appointment functionality via the appointment system such that an output of a result of the managed appointment functionality and/or the processed information is produced; and/or processing, transmitting and/or executing a combination of features involving the output and/or result.
Further, in certain implementations, the innovations herein may include or involve terminal operating system (TOS) agnostic processing. The user input may include a command to establish an import container appointment, modify an import container appointment, search import container appointments, delete an import container appointment, view an import container appointment, or a combination thereof. The output may include an established import container appointment, a modified import container appointment, a search result including an import container appointment, a deletion of an import container appointment, a display of an import container appointment, or a combination thereof. The appointment functionality may include landing page functionality, terminal landing page functionality, menu functionality, login page functionality, gate inquiry functionality, import inquiry functionality, appointment inquiry functionality, appointment details functionality, appointment modification functionality, appointment deletion functionality, appointment setup functionality, appointment status functionality, message functionality, location functionality, direction functionality, contact functionality, general information functionality, or a combination hereof. The generated output and/or result provides reduced operational costs from improved gate efficiency, accelerated throughput, better equipment utilization, or a combination thereof.
The innovations herein may be implemented via one or more components, systems, servers, appliances, other subcomponents, or distributed between such elements. When implemented as a system, such system may comprise, inter alia, components such as software modules, general-purpose CPU, RAM, etc. found in general-purpose computers, and/or FPGAs and/or ASICs found in more specialized computing devices. In implementations where the innovations reside on a server, such a server may include or involve components such as CPU, RAM, etc., such as those found in general-purpose computers.
Additionally, the innovations herein may be achieved via implementations with disparate or entirely different software, hardware and/or firmware components, beyond that set forth above. With regard to such other components (e.g., software, processing components, etc.) and/or computer-readable media associated with or embodying the present inventions, for example, aspects of the innovations herein may be implemented consistent with numerous general purpose or special purpose computing systems or configurations. Various exemplary computing systems, environments, and/or configurations that may be suitable for use with the innovations herein may include, but are not limited to: software or other components within or embodied on personal computers, servers or server computing devices such as routing/connectivity components, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, consumer electronic devices, network PCs, other existing computer platforms, distributed computing environments that include one or more of the above systems or devices, etc.
In some instances, aspects of the innovations herein may be achieved via or performed by logic and/or logic instructions including program modules, executed in association with such components or circuitry, for example. In general, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular instructions herein. The inventions may also be practiced in the context of distributed software, computer, or circuit settings where circuitry is connected via communication buses, circuitry or links. In distributed settings, control/instructions may occur from both local and remote computer storage media including memory storage devices.
Innovative software, circuitry and components herein may also include and/or utilize one or more type of computer readable media. Computer readable media can be any available media that is resident on, associable with, or can be accessed by such circuits and/or computing components. By way of example, and not limitation, computer readable media may comprise computer storage media and other media. Computer readable media herein, however, does not encompass/include transitory media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and can accessed by computing component. Communication media may comprise computer readable instructions, data structures, program modules or other data constituting the functionality herein, embodied in non-transitory format. Further, communication media may include wired media such as a wired network or direct-wired connection, embodied tangibly. Combinations of the any of the above are also included within the scope of computer readable media.
In the present description, the terms component, module, device, etc. may refer to any type of logical or functional software elements, circuits, blocks and/or processes that may be implemented in a variety of ways. For example, the functions of various circuits and/or blocks can be combined with one another into any other number of modules. Each module may even be implemented as a software program stored on a tangible memory (e.g., random access memory, read only memory, CD-ROM memory, hard disk drive, etc.) to be read by a central processing unit to implement the functions of the innovations herein. Or, the modules can comprise programming instructions transmitted to a general purpose computer or to processing/graphics hardware via a transmission. Also, the modules can be implemented as hardware logic circuitry implementing the functions encompassed by the innovations herein. Finally, the modules can be implemented using special purpose instructions (SIMD instructions), field programmable logic arrays or mixtures of those or other suitable elements which provide the desired level performance and cost.
As disclosed herein, features consistent with the present inventions may be implemented via computer-hardware, software and/or firmware. For example, the systems and methods disclosed herein may be embodied in various forms including, for example, a data processor, such as a computer that also includes a database, digital electronic circuitry, firmware, software, or in combinations of them. Further, while some of the disclosed implementations describe specific hardware components, systems and methods consistent with the innovations herein may be implemented with any combination of hardware, software and/or firmware. Moreover, the above-noted features and other aspects and principles of the innovations herein may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various routines, processes and/or operations according to the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer, network, architecture, environment, or other apparatus, 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 teachings of the invention, or it may be more convenient to construct a specialized apparatus or system to perform the required methods and techniques.
Aspects of the method and system described herein, such as the logic, may also be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (“PLDs”), such as field programmable gate arrays (“FPGAs”), programmable array logic (“PAL”) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects include: memory devices, microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (“MOSFET”) technologies like complementary metal-oxide semiconductor (“CMOS”), bipolar technologies like emitter-coupled logic (“ECL”), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.
It should also be noted that the various logic and/or functions disclosed herein may be enabled using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) though computer readable media herein does not encompass/include transitory media.
Unless the context clearly requires otherwise, throughout the description, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
Although certain presently preferred implementations of the inventions have been specifically described herein, it will be apparent to those skilled in the art to which the inventions pertains that variations and modifications of the various implementations shown and described herein may be made without departing from the spirit and scope of the inventions. Accordingly, it is intended that the inventions be limited only to the extent required by the applicable rules of law.
This application claims benefit/priority of U.S. provisional patent application No. 61/965,458, filed Jan. 29, 2014, which is incorporated herein by reference in entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61965458 | Jan 2014 | US |
