Issuu on Google+

1 Trademark Next Generation (TMNG) Target Architectural Overview The TMNG target architecture is a standard N-tier architecture that is comprised of these primary tiers: 1. 2. 3. 4. 5. 6.

UI and Front End Web Server (FE-WS) User Management Core USPTO Infrastructure Trademark Business Services Enterprise Application Support Data Storage

Figure 1 Overall Tiered Architecture


Figure 1shows these tiers as they are to be represented in the new TMNG system. 1.1

The UI and FE-WS Tier

This tier represents the front end web server and the associated web pages that it delivers form the primary tier that faces all users and the outside world. The FE-WS will provide a set of Representational State Transfer (ReST) services that deliver all of the functionality to the user front ends. The ReST services will adhere to a well defined interface definition. TMNG will build out a set of web pages and AJAX-like components that will communicate with these ReST services. The ReST services provide all of the functionality that must be delivered to all business roles. The AJAX-like components provide the TMNG interface that allows users to perform normal TMNG functions in a coherent fashion. External entities are permitted to build their own ReST service consumers/applications. In the diagram above this tier is represented as residing in the the DMZ or De-Militarized Zone and delivering web pages and/or ReST services to external users. Authentication and authorization on some level is required for all TMNG users. Users not explicitly logging in will be treated as default users. The ReST services are “permissioned” based on user roles so only users with appropriate credentials have access to more private information. The actual authentication and authorization is managed in the next tier down. 1.2

User Management

User management involves all of the necessary components to: 1. Allow for Single Sign On (SSO), authentication, and roles based authorization for all facets of TMNG 2. Provide a customizable user experience (Customer Relationship Management – really user preferences) 3. Allow collaboration between users. The SSO/Authentication/Authorization is, perhaps, the most important functionality provided by this tier. All access through the FE-WS will be authorized through this layer. The ReST service URLs may be protected in this tier based on the key words that appear within portions of the URLs. This is often referred to as course-grained authorization, though it may in fact provide enough control for all TMNG needs (this is TBD). Currently it is envisioned that authorization and authentication will take place using Spring Security in conjunction with Active Directory. SSO will “bolt on” as the SSO strategy within the USPTO becomes cleared. This approach requires nor custom security code within the business logic (ReST services or downstream business components). The nature of the CRM and collaboration tools, at this point, remains TBD.


1.3

Core USPTO Infrastructure

This layer provides generalized infrastructure services that that USPTO infrastructure group overall provides for all applications. The two components that we see providing some functionality that will be consumed within TMNG are the Enterprise Service Bus (ESB) and the generalized mailing service. The ESB will primarily be used to abstract URLs from the FE-WS. In this capacity, the ESB acts as a gateway. The ReST services in the FE-WS will make calls into the business logic tiers. Those calls will be specified by URL. The ESB allows us to expose a stable URL to the ReST services for specific business services. While the internal URLs associated with thos specific businesses services may change, the ESB will manage that change, without requiring any adjustments within the ReSTful layer. The mail service should be (TBD) provided centrally by the USPTO infrastructure team. Internal business services or FE-WS ReST services can use the mail service to “post” e-mail messages that are generated from within those services. Ideally, the business services will use the mail service as a notification mechanism both for internal and external e-mail.

1.4

Trademark Business Services

There are 4 main services identified as business services within the architecture: 1. 2. 3. 4.

Case Management Document Management Reporting Search

The core business services identified by the business architecture team and the internal TMNG group consisted of Docket Management, Case Management, Work Flow, Routing, Notification, Time Processing, Reporting, and Search. It seems that Routing, Docket Management, Case Management, and Work Flow are redundant services, and they should all be logically encompassed by Case Management on the business service level. Time processing and notification have some components that will be managed within Case Management and others that will be managed within the enterprise application support tier (The common components shown in the Enterprise Support Tier include the notification and Scheduler components – there’s not enough real estate to explicitly spell out all the common pieces). 1.4.1 Case Management As stated above, case management will include docket management, and workflow. At this point, we envision the case management service being broken into a couple of “sub-services.” These will provide the ability to manage groups/lists of items that might appear on a docket (simple docket management), the ability modify individual docket items, the ability to manage events associated with dockets or docket items (this includes scheduled/timed events), and the ability to notify users of actions that happen within cases (actions that happen to groups of items or individual items).


1.4.2 Document Management Within trademarks, documents typically refer to supporting artifacts for trademarks or trademark cases. In addition, there may be documents (TMEP, etc.) that are not explicitly connected with items that appear within a docket. The document management service provides the business level mechanism to manage all of these types of documents. 1.4.3 Reporting (To be written) 1.4.4 Search (To be written) 1.4.5 Vendor Lock-In Concerns The business services will primarily be leveraging components within the Enterprise Application Support Tier. Ideally all of these components would be Commerciallyavailable Off-The-Shelf (COTS) products. Where those products fall short, we will have to write custom code. However, the business service tier must never make direct calls to COTS product programming interfaces. More specifically, the business service tier must wrap all of the components within the Enterprise Application Support Tier with a “normalizing” interface. In this manner, the business tier remains vendor neutral. This should be considered as a mandatory practice within TMNG, otherwise the USPTO will ultimately be beholden to individual vendors, and the resulting systems will not be able to leverage new technology as it emerges. 1.5

Enterprise Application Support Tier

As shown in Figure 1, this tier includes: 1. 2. 3. 4. 5.

Common components CMS tools Case Management and Work Flow Products Search Engine products Reporting Products

All of these, with the exception of Common components have a fairly well defined meaning. Common components will include (but not be limited to): a scheduler, a notification mechanism (this may include a publish/subscribe if necessary – this would be a good place for internet publish/subscribe if we want that capability…), nonfunctional application support (logging, monitoring, etc.), and generalized data access support (typically, this is the isolation between the data layer and the object layer). Some or all of these may reside within the USPTO infrastructure tier. Whether or not that is the case is TBD. 1.6

Data Store Tier

This tier is responsible for the logical persistence of both the COTS vendor data and the application specific data. Every component within the logical data model should be


represented here. Of course, this is also a real, physical tier. The exact physical nature though is not relevant for this description. That is not to say that concerns like database replication, reliability, etc. don’t need to be addressed. 1.7

Mapping of Current State Functionality to the Logical TMNG Architecture

Figure 2 shows which tiers and components within the new architecture will be responsible for assuming the functionality that currently exists within the trademark

Figure 2 Map from the Current Functionality into the TMNG Architecture

systems. This is simply intended as a guideline both to help insure that we at least cover all of the current functionality, and to act as a sanity check for the future direction.


example document