Patent Grant
8401881
This application includes a computer program listing appendix submitted on a compact disc, the compact disc containing the files “Exhibit A.txt” (file created Feb. 8, 2011; file size of 316 kilobytes), “Exhibit C.txt” (file created Feb. 8, 2011; file size of 534 kilobytes), and “Exhibit D.txt” (file created Feb. 8, 2011; file size of 261 kilobytes), these files being incorporated herein by reference.
The invention disclosed and claimed in the parent cross referenced above relates generally to the field of an Internet enabled business-to-business intelligent communication link allowing a first business organization to have intelligent interaction with a second fully integrated business organization to facilitate the placing of orders or reservations for business services or goods, with the services or goods provider having a computer network linking multiple levels of its organization to provide for the smooth conduct of business between the two organizations. More particularly, this field relates to an Internet enabled automatic rental vehicle transaction system to facilitate the conduct of rental vehicle transactions between two multilevel business organizations, one of which provides such rental vehicle transaction services in an integrated manner through business enterprise software to a high volume user of such rental vehicle services wherein an Internet web portal is defined by the rental vehicle service provider which interconnects the two business organizations at multiple levels, providing a graphical user interface (GUI) for the transaction of large amounts of rental vehicle services automatically and virtually without human intervention upon entry. The invention of the present continuation-in-part application extends the functionality of the parent invention by providing an intelligent portal that is readily configurable to suit any particular customer and any particular provider data requirements or method of doing business. This added functionality allows the invention, for example, to provide the user with access to other suppliers in the same seamless and integrated manner. In other words, the user now has access to not just one integrated business but multiple businesses, some of which may but need not be, integrated businesses thereby extending the invention for use in a generic application to satisfy a users needs for a good or service not just from one vendor but all vendors connected to the invention.
Computer technology has been embraced by many businesses in order to handle their ever increasing order flow as well as to mitigate the increasing blizzard of paper required to be produced to document this business. A significant benefit which often drives the implementation of technology is its further advantage in increasing productivity to thereby allow fewer people to handle greater volumes of business. One such good example demonstrating the efficiencies and value to be gained by implementing technology is the business model developed and followed by the assignee of the present invention. A rental car company at its heart, the assignee transacts an ever increasing number of time sensitive, relatively low dollar volume, vehicle rentals which in many instances require authorizations to be made in advance, reservations of vehicles from available geographic and vehicle type selections, monitoring of the rental as it progresses including possibly extending the rental under certain circumstances, communications between the various parties involved in the transaction to ensure ultimate customer satisfaction, and financial accounting for the transaction including generating invoices and processing them for payment. While a significant portion of the vehicle rental business involves rental for leisure, business travel, etc., another significant business relationship has developed with insurance companies and the like in what has been termed as the replacement car rental service business. In this business, a vehicle insurance company may have many thousands of policyholders who are eligible to be involved in accidents, and other dislocations of use, requiring that a vehicle be rented for that customer's use while his own vehicle be made ready again for use. Thus, for this business segment, a multi-tiered business organization such as a vehicle insurance company represents a significant customer for repetitive vehicle rental services. To conduct this business in an orderly, time efficient and cost efficient manner, it is necessary that this insurance company has as its business partner a vehicle rental company which is itself multi-tiered, such as the assignee of the present invention. This is because the needs, both geographically and in volume, are significant which require the dedication of a significant amount of resources. To satisfy these needs and to respond to other business growth, in its embrace of technology the assignee hereof has succeeded in developing an in-house computer system and related software which has integrated its business internally. This business integration has been massive and company-wide as is needed to integrate a company having a central office with literally thousands of individual branches located nationally, and even now internationally, with hundreds of thousands of vehicles available for rental. Furthermore, other business partners including other service providers such as vehicle repair shops have also been given access to this system to allow for input of information relating to progress of vehicle repair, extension of rental time, etc. as the rental progresses. This integrated business computer network and software generally includes a mainframe server at the heart of a wide area network (WAN) which facilitates the transfer of vehicle rental information and orders company-wide. This integrated business model is most efficient and needed in order to satisfy the vehicle rental service needs of a vehicle insurance company which itself may be national or even international in scope.
As a first step in extending the integration of technology into this business model, the present assignee has previously developed and implemented a computer system which has provided improved communication capabilities between the two business partners. This system generally comprised a second mainframe computer linked to the first mainframe of the integrated business network, with dedicated access lines being provided from this second mainframe to various levels of the multilevel business organization comprising the insurance company. In effect, with this additional mainframe and dedicated pipeline access, various individuals at the insurance company were permitted to directly interact with the integrated business computer network of the vehicle rental company as well as other selected service providers such as body shops where wrecked vehicles were being repaired. The implementation of this system provided a great step forward over the people intensive business activity previously required in order to handle the large number of transactions encountered in this business relationship. Historically, the replacement car market engendered large numbers of telephone calls being placed between the insurance company, the rental company, and the body shop where vehicle repair was being performed in order to authorize the rental, select and secure the desired replacement vehicle to be provided, monitor the progress of the repair work so that scheduling of the rental vehicle could be controlled, extending the vehicle rental in the event of delays in repair, authorizing various activities involved in the rental process including upgrades of vehicles or other charges for services, and subsequent billing of the rental service and processing the billing to the insurance company for payment.
While the implementation of this system was successful and represented a tremendous step forward in automating the business relationship between the insurance company and the vehicle rental company, it did have certain limitations. For example, a specific communication link had to be established between the rental vehicle company and the particular users at the insurance company designated to have access to this system. Thus, special attention and some modicum of expense was required to establish these “pipelines” and maintain them. Still another aspect to the system implemented was that it was not “browser” based nor did it provide graphical user interface (GUI) menus. Thus, each user had to be specifically trained in the particular “language” used by the system and learn to work with specific menus nested in a specific manner as well as codes for entering commands which were not similar to other computer software programs. This software design thus necessarily required additional training in order to insure that users could gain the full measure of advantage provided by the system and in order to minimize the opportunity for erroneous information or incorrect reservations from being entered or otherwise confusing the business transactions. Furthermore, user efficiency was not immediate and required skill beyond that ordinarily found in casual computer users, as we are all becoming in this computer age. Still another disadvantage to the system was that access was required to a designated entry point in the system in order for a person authorized to be on the system to work with it. As the nature of the insurance and replacement car business requires extreme mobility at multiple levels of both business partners, this represents a limitation to the usefulness and time efficiency with which various business functions could be performed. Therefore, while implementation of the second mainframe allowing for pipeline connections at various levels of the multi-tiered insurance company was a significant step forward in automating the business relationship between the two business partners, significant limitations to this solution were readily apparent to the users thereof.
In the parent application cross-referenced above, the inventors herein have succeeded in designing and developing a means for substantially enhancing the business to business communication link between these two businesses which provide significant advantages over its prior embodiment. More particularly, the inventors have succeeded in replacing the dedicated pipeline access of the existing system with a web portal allowing Internet access to the mainframe with a browser based graphical user interface (GUI) presentation. This also made the system more readily accessible to smaller business partners as the expense of the “pipeline” was eliminated. The parent invention offers several important technical advantages over the previous system. First of all, by taking advantage of the ubiquitous nature of the Internet, the ultimate in portability and connectivity for this system is now provided in a business environment where mobility and connectivity are at a premium. In other words, a claims adjuster, body shop, or any other business employee authorized to have access to the system may gain access at any site offering Internet access. In present day technology that includes many mobile devices and appliances which are Internet enabled. As technology advances, it is conceivable that this access will extend to permit “24/7” access by any authorized person at any geographic location. This is a marked improvement providing immediate benefit and advantage over the dedicated pipeline access of the prior art system.
A second major advantage of the parent invention is its graphical user interface. The inventors have taken full advantage of this browser based GUI to streamline and organize the presentation of information to a user to actually guide him as he interacts in doing his business. One such example is customized design of the menus such that the user is guided and directed to answer only those questions required to be answered in order to conduct the particular transaction being addressed, and further to present choices to the user for his selection to minimize the need for the user to rely on his own memory or to be familiar with complicated and specialized codes to enter data or request transaction activity. With the recent and continuing explosion of the Internet, more people are becoming familiar with browser programs and their operation through their own daily activities in their personal lives. This familiarity paves the way for easier training and quicker orientation of a new user to the present invention. For large business organizations communicating at multiple levels, this significant advantage cannot be minimized as there are large numbers of people who must be continuously trained due to the growth of the organizations, as well as the replacement of employees due to the inevitable attrition. Thus, the parent invention provides an immediate increase in worker productivity, and makes that improved efficiency available to many more workers who are not particularly skilled otherwise in computer usage.
Still another advantage provided by the parent invention is through the implementation of additional functionalities which are engendered by the browser/GUI interface. As the system is continuously used, and feedback is continuously monitored and analyzed, additional features that add value through providing management information as well as by speeding transaction activity over the system may be implemented. For example, several of these features include the ability of a user to create an on demand report for transaction activity including summaries of transactions handled by a particular user or group of users which might either be open or closed. Another example of additional functionality which improves the efficiency of a user is the ability to create a repair facility call back list which allows a user to sort existing open vehicle rental reservations by repair facility (body shop) and date such that a user is presented with the list of open reservations at a particular repair facility which can be readily handled in a single telephone call while at the same time having the system on line to implement any needed changes such as extensions of reservations, etc. Additional functionality has also been provided to speed the processing of invoicing which of course also speeds their payment and cash receipts. For example, it was found that even despite the built-in error checking and correction facilities provided to the users of the system, a repetitive pattern of mistakes involving incorrect claim numbers was discovered. To speed the processing of these, an additional functionality was provided as an “electronic audit” known as invoice return which returns an invoice to a particular adjuster upon detection of an incorrect claim number for his human intervention and correction of the claim number. In this manner, problem invoices exhibiting one of the most common problems encountered may be readily handled within the system and in an efficient manner, instead of manually as before.
The parent invention also has as a significant advantage the ability to be further customized to meet the individual business partners' needs and desires as well as to provide additional functionality by offering additional features which become desirable upon accumulation of user data based on user experience. Furthermore, once implemented, they are immediately available system wide. While this allows for consistent usage, it is limited in the sense that all of the system users are forced to use the same menus, data definitions, etc. This is not seen as a limitation for the one-to-one business application intended to be primarily addressed by the parent invention.
Still another advantage of the parent invention is that the graphical user interface incorporates point and click interaction, using buttons and tabs to present or conceal data for the user's attention or inattention as the case may be, and provide a much more robust interaction capability through the creation of menu designs that allow for access to the most commonly needed features from any point in the menu architecture. This is to be contrasted with the prior system which consisted of a main frame character based interface while the parent invention with its GUI interface allows a user to point and click to navigate and to make selections by pull down selection, thereby reducing errors. As users become more experienced with the system, and their confidence level grows, they are much more likely to become bored and aggravated with the rigid structure of the prior system requiring them to follow along a certain menu architecture in order to complete certain tasks. On the other hand, the parent invention generally increases the interest of the user in using the system. These advantages of the parent invention over the prior interface promote employee productivity by allowing a user more control over his work which is critical in achieving savings in human resources to operate the system which is one of its main goals.
The present invention extends the parent invention and expands its capabilities and functionalities. With the present invention, a user may not only have access to its business partner, but also one or more competitors of its business partner through the same Internet portal. In this way, at least two needs are satisfied. First, the user can have access to a variety of providers to choose from where business needs or desires require. This allows the user to use a single portal and not have to sign on to a number of different portals, even should they be available. Furthermore, the user isn't troubled to learn how to access and use different portals even should they be available. Presently, not all providers are operating an Internet portal for offering their services, so by allowing business competitors to be accessible through the same portal, independent development of other portals is forestalled. This is a benefit to the operator of the main portal as it creates and maintains a competitive advantage by handling all of the order flow which creates a data base of useful information for marketing purposes. Although initially the portal services might be offered for no additional cost to a competitor, eventually a fee might be charged which would at least partially offset the cost for owning and operating the portal.
The design of the portal is elegant and offers great flexibility for customizing not only the menus for presentation to the user, but also in the design of the data base entries needed or desired by the user and/or the competitive provider. For example, some users might not know or care about the features of a vehicle rented and so those data entries may not be provided space on the menu for the user to fill in. The data base as handled by the networked computer system then need not keep track of that data for that customer. This feature is readily accommodated by the data base programming and is conveniently implemented.
In still another aspect of the present invention, the web portal has the capability to accommodate the varying data requirements also of the various competitive providers, but also the level of their sophistication as evidenced in their respective computer systems and interface facilities. For example, the web portal may be configured to communicate the users order to the competitive provider via email, phone, or even through a connection directly to an integrated computer system having the same or substantially the same inter-operability as the integrated computer system of the assignee hereof. This capability extends to accommodating and matching the competing data requirements of the user and the competitive providers, and having the flexibility to design and implement menus that readily meet these competing needs. Furthermore, the present invention allows for changes to be implemented by simple re-programming of the web portal which minimizes the effort and enhances the “user friendly” aspect to the present invention.
Not only are these “global” improvements made available with the present invention, there are other more particularized improvements that add functionality within the operating framework of the parent invention. For example, one such improvement is the ability to “virtually” assign work groups within the user so that, for example, multiple adjusters might be made into a team with a shared work load so that all of the team members have access to the same pool of work, such as the placing of reservations for the same group of drivers. With this “virtual team” assignment capability, work groups may be readily re-assigned to match changing work loads without worrying about re-configuring hardware or internal network connections. This can be a very valuable feature to accommodate staffing issues over geographical distances that can be nation-wide, with access through the web portal to reservation facilities which are themselves nation-wide.
Still another feature is the ability to customize an individual users authorization limits. As can be appreciated, one of the mixed blessings of providing enhanced functionality to the individual user's of any integrated computer system is that it places great power in the hands of the user which at the same time creates the potential for abuse. There have been well publicized instances of “rogue” employees making financial decisions or placing instructions which have far reaching financial consequences well beyond the intended authority of an employee, with disastrous results. With the present invention, one feature is the ability to limit the financial commitments that a user may make during any pre-selected time period. For example, the users profile may limit his ability to make only a certain dollar limit of vehicle reservations over any certain number of work days. In this way, added safe guards may be conveniently provided, monitored by reporting capabilities, and changes as circumstances warrant, all with simple programming changes at the web portal.
There are still other features that are provided by the present invention that find their genesis in the different approach taken over the parent invention and owing to the inherent increased flexibility of using a web based programming for the web portal to interface between the user and the providers on the web server and eliminating the need for any custom software on the user's terminal. The details of these are to be found and described in the detailed description of the preferred embodiment below. Examples include the ability to send confirmatory communications to the user that the reservation has been received and entered into the providers system for fulfillment, custom report design including the capability to save and re-generate the custom report upon user command, increased flexibility to process and pay invoices, etc.
While the principal advantages and features of the invention have been discussed above, a greater understanding of the invention including a fuller description of its other advantages and features may be attained by referring to the drawings and the detailed description of the preferred embodiment which follow.
The overall system architecture for the parent invention 20 is best shown in
It should be noted that the particular computer configuration chosen as the preferred embodiment of the parent invention may itself be subject to wide variation. Furthermore, the term “mainframe” as used herein refers solely to a computer which can provide large scale processing of large numbers of transactions in a timely enough manner to suit the particular business application. Preferably, as is presently used by the assignee hereof, an IBM AS/400 mainframe computer is used as each of computers 32, 38. However, as is well known in the art, computer technology is subject to rapid change and it is difficult if not impossible to predict how these computer systems may evolve as technology advances in this art. For example, it is not beyond the realm of possibility that in the not so distant future a network of computers would provide the processing power to conduct these business operations as presently handled by “mainframe” computers. Thus, the term “mainframe” is not used in a limiting sense but merely to indicate that it is descriptive of a computer suited to handle the processing needs for a large scale business application.
It should also be noted that the communication link 46 extending between the server 42 and each of the branch offices 44 may have alternative configurations. For example, in some applications access over the Internet may itself be adequate, recognizing the vagaries of Internet service availability, reliability, and processing speed. Alternatively, this communication link 46 could well be a dedicated pipeline providing broadband service connection full time with back up connections to ensure continuous communication between a particular branch office or groups of branch offices and the service providers business operations computer system 36. Some branch offices might even be served through satellite links. Indeed, it is even possible that a mixture of these wide variations of service level be present within a single organization's structure depending upon communication link cost and availability balanced against service needs. It should merely be noted for present purposes that this communication link 46 serves as the electronic umbilical cord through which branch offices 44 communicate with the business computer system 36 of the present invention.
Attached hereto as exhibits are functional descriptions of the software programs resident on the computers comprising the two computer systems 32, 38 which implement the parent invention. More particularly, attached hereto as Exhibit A is a functional description of the software to implement the integrated business functions resident on the AS/400 or mainframe computer 38. Attached hereto as Exhibits B and C are related flow diagrams (see
As a further example of the flow of data and the functional advantages provided by the parent invention, reference is made to
The last phase of the process involves closing the transaction. During this phase of the transaction, the contract is indicated as being closed and invoiced, the services purchaser can approve invoices, reject invoices, and also remit invoices. Such invoice remittance may also include the actual transfer of funds through an electronic funds transfer medium, or otherwise as previously arranged between the business partners.
It should be understood that this is a streamlined description of the handling of a transaction, and by no means is exhaustive. For example, much more functionality is available to the user including accessing the data base to generate production reports regarding status of open or closed reservations, preparing action item lists to allow a user to organize and prioritize his work, obtaining information available in the system from having been entered by others which would otherwise require phone conversations which are inefficient and occupy still another person's time. A more detailed explanation of the functionality provided is found in the exhibits.
In summary, the parent invention creates almost an illusion that the services purchaser, and the great number of users at various levels of the multi-tier purchaser users, are actually part of the services provider organization in that immediate online access is provided to significant data which enable the user to make reservations for services, monitor those services as they are being provided, communicate with those providing the services, obtain information relating to the status of services as they are being provided, and close transactions, all by interacting with the services provider business organization over that user's PC and without human interaction required by the business providers personnel. By way of contra-distinction, for many years business has been conducted on a human level by customers picking up the telephone and calling services providers and talking to their human counterparts in order to convey information, place orders, monitor orders, including obtaining information as to status, canceling orders, questioning invoices and paying invoices, along with a myriad of other related interactions. Not only did the conduct of business in this manner entail significant amounts of human resources at both ends of the transaction, but it also led to inefficiencies, mistakes and delays all of which increase the cost of doing business and contribute to an increased risk of services being rendered in an unsatisfactory manner in many instances to the end user. The parent invention has taken the preexisting solution of providing electronic communication between the business partners to another level by “web enabling” this system for improved connectivity, improved usability, reduced training, enhanced mobility, and other advantages as described herein.
A schematic diagram of the present invention is shown in
The next layer of architecture 68 is noted in the figure as the “Enterprise private network” and is comprised of a plurality of servers 70 network connected with a network connection 72. Again, although the choice of hardware is not considered critical by the inventors hereof, Sun Microsystem's server/work station hardware is preferably used to provide the platform for running the application software for processing the various rental vehicle transactions, as will now be explained. Attached hereto as Exhibit E are a series of functional design specifications for the ARMS/WEB application software resident on servers 70 and which provide the detailed description of the operational features of the software and system. With these functional design specifications for the individual modules, it would be readily apparent to those of ordinary skill in the art that programmers of ordinary skill would be able to write software to execute these functional specifications without using inventive effort. Furthermore, the details of this implementation are not considered to provide any aspect of the best mode for carrying out the invention which is defined by the claims below.
Generally, the ARMS/WEB application software permits a user to sign on and, when recognized, provides the series of menus presenting choices for the user to indicate the parameters for his reservation. A plethora of information is provided and accessible to the user through the various menus provided from which the user selects and enters data to process the reservation. An important feature of the ARMS/WEB application software is that it provides the user the opportunity to select to place his vehicle rental reservation not only with the integrated business computer system represented by the third level of architecture 74, described below, but also to route the reservation information back through the first architectural level 50 and into the Internet 54 for transmission to a competitive service provider 76. Although the interconnection is depicted in
With the present invention, the Internet portal provided by the AMRS/WEB network configured servers 70 provide an Internet portal for communication with not only the integrated computer enabled business system of the resident services provider, but also a portal for placing reservations to other competitive services provider 76. Thus, the user 52 enjoys the capability of accessing multiple service providers for competitive services through a single Internet connection using a single set of protocols, menus, etc. for the conduct of this business activity. Furthermore, the software configured network of servers 70 is readily configured in Web Logic to adapt to changing user requirements, data requirements, unique competitive service provider requirements, and other upgrades or modifications in a convenient manner by simply modifying the software resident therein. No special browser software of other interface software is required by the user and any special interconnecting software or server/hardware requirements may be satisfied as between the service providers such that the user is presented with a seamless interconnection. As the present invention is configured and works well with the integrated business and computer systems as disclosed herein, it is anticipated that such interconnection and usability may be readily translated to any other such integrated computer system as might be found in other competitive service providers, as would be apparent to those of ordinary skill in the art. Thus, with the present invention, a user is provided with Internet access through a single portal to a plurality of service providers and, to the extent possible, to their integrated computer business systems.
Various changes and modifications to the preferred embodiment as explained herein would be envisioned by those of skill in the art. Examples of these changes and modifications include the utilization of computer systems configured in any one of a myriad of ways using present technology alone. For example, mobile computers are presently available and wireless technology could be used to extend the integrated business network of the services provider, as well as match the mobility needed by the various users connected to and using the present invention. The particular software, and various aspects and features of its design, have been adapted for particular application to the vehicle rental business. Of course, computer software applications satisfying other business needs would necessarily require adaptation to their particular business models. Thus, it is envisioned by the inventors herein that the various software programs described herein would be matched to the particular business application to which the invention is utilized. These and other aspects of the preferred embodiment should not be viewed as limiting and instead be considered merely as illustrative of an example of the practical implementation of the present invention. These changes and modifications should be considered as part of the invention and the invention should be considered as limited only by the scope of the claims appended hereto and their legal equivalents.
Exhibit A
See the file “Exhibit A.txt” submitted on the incorporated compact disc.
Exhibit B
See
Exhibit C
See the file “Exhibit C.txt” submitted on the incorporated compact disc.
Exhibit D
See the file “Exhibit D.txt” submitted on the incorporated compact disc.
Exhibit E
1. Extend Rental Use Case
1.1 Application Overview
The following is a document used to illustrate the process for how the USER will extend a previously authorized rental using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case will describe how the USER will extend a previously authorized rental. The rental company (via an Authorization Request), the RENTAL ADMINISTRATOR (via a Customer Search), or Reporting (via the Callback feature) can initiate this use case.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “Extend Rental”.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 View Rental Notebook
1.5.3.2 Display Confirmation
1.5.3.3 Update USER Profile
1.5.3.4 Validate Changes
1.5.3.5 Change Customer File
1.5.3.6 Update ARMS/Web Database
1.8.1 MA-16 Reassign USER/Office (Transfer)
1.8.2 MA-08 View Car Class
1.8.3 MA-15 Terminate Rental
1.8.4 MA-04 Send Message
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Extend Rental Detail
This screen (see
2.1.1 Screen Layout—Extend Rental Detail—see
2.1.3 Extend Rental Detail
additional
2.1.4 Screen Function Definition
2.1.4.1 Skip
2.1.4.2 Process
2.1.4.3 Notebook
2.1.4.4 Set Last Date
2.1.4.5 Transfer File
2.1.4.6 Change or Add
2.1.4.7 Top of Page
2.1.4.8 View Car Class
2.1.4.9 Extend Rental
When clicked, the system will validate the input and accept the extension AND the changes made to the customer file. The ARMS/Web database will be updated. The use case will then end and the USER will return to the process from which they came.
1. Review List Action Items Use Case
1.1 Application Overview
The following is a document used to illustrate the process for how the USER would view and/or select any outstanding action items assigned to them using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case describes how the USER would view and/or select any outstanding action items assigned to them.
1.3 Use Case Actors
The following actors will interact with this use case.
The Flow of Events will include the necessary steps for a USER to review and assign outstanding action items.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 Handle for a Different User
1.5.3.2 Re-Sort Action Items List
1.5.3.3 No Items Found
None
1.7 Special Requirements
1.7.1 Sort Request
An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.
1.8.1 MA-12-Extend Rental
1.8.2 MA-10-Authorize Request
1.8.3 Invoicing—BI-01-Handle Unapproved Invoices & BI-02 Pay Approved Invoices & BI-03 Reject an Invoice
1.8.4 MA-19—View Customer File (Message)
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Action Items
This screen (see
2.1.1 Screen Layout—Action Items—see
2.1.2 Action Items—Summary
2.1.3 Screen Function Definition
2.1.3.1 Renter's Name
1. Assign a Request Use Case
1.1 Application Overview
The following is a document used to illustrate the process for assigning the unassigned authorization requests to the appropriate user. The assignments will be made using the ARMS Web 3.0 system. The intent for this release of the ARMS Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case describes the process of how a USER will review unassigned authorization request and assign them to a USER for further handling.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “Assign an Action Item”.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 Cancel Use Case
1.5.3.2 Modify a Request
1.5.3.3 Select a Different Office
If the use case is successful, the system will change the request type from an unassigned authorization request to direct bill. If the user has authority to authorize this request, the system will change the request to Authorized status and assign the adjuster picked in Step 5 of the basic flow.
If the use case is unsuccessful, the system state will remain unchanged.
1.7 Special Requirements
None
1.8 Extension Points
1.8.1 MA-04 Send Message
1.8.2 MA-10 Authorize a Request
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Action Items—Unassigned
This screen (see
2.1.1 Screen Layout—Action Items—Unassigned (ARMS Web 2.0)—see
2.1.2 Action Items—Unassigned
Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.2.1 <<Previous
2.1.2.2 Process
2.1.2.3 Cancel
1. View Car Class Use Case
1.1 Application Overview
The following is a document used to illustrate the process for how the USER would view examples of automobiles that are part of each rental company car class using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case will allow the USER to view examples of automobiles that are part of each rental company car class. The USER will have the ability to select a car class and have the rate for the car class apply to the reservation/authorization.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 Select Alternate Car Class
1.5.3.2 Populate Car Class Rates
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.7.1 Modify Car Class Selection Results
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Car Class Detail Screen
This screen (see
2.1.1 Screen Layout—see
2.1.2 Car Class Details
2.1.3 Screen Function Definition
2.1.3.1 Select this Car Class
2.1.3.2 Previous
None.
1. Authorize Request Use Case
1.1 Application Overview
The following is a document used to illustrate the process for how a USER authorizes a direct bill request using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case describes how a USER authorizes a direct bill request.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “Authorize Request”.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 View Notebook
1.5.3.2 Add Notes to Customer File
1.5.3.3 Skip Customer File
1.5.3.4 Change Customer File
1.7.1 Requirements for Claim Type Authorizations (Insurance Users Only)
1.7.1.1 When the Claim Type Selected is ‘Insured’, ‘Theft’, or ‘Uninsured Motorist’
1.7.1.2 When the Claim Type Selected is ‘Claimant’ (Insurance Users Only)
1.7.1.3 Requirements for Editable Fields Based on Reservation/Ticket Status
1.8 Extension Points
An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.
1.8.1 MA-04 Send A Message
1.8.2 MA-07 Additional Charges
1.8.3 MA-16 Transfer Work
1.8.4 MA-08 View Car Class
1.8.5 MA-17 Cancel Authorization
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Authorize Rental Detail
This screen (see
2.1.1 Screen Layout—Authorize Rental Detail—see
2.1.2 Authorize Rental Detail
days @
2.1.3 Screen Function Definition
2.1.3.1 Skip
2.1.3.2 Process
2.1.3.3 Notebook
2.1.3.4 Set Last Date
2.1.3.5 Transfer File
2.1.3.6 Change or Add
2.1.3.7 Top of Page
2.1.3.8 View Car Class
1. Create Reservation Use Case
1.1 Application Overview
The following is a document used to illustrate the process for creating a reservation using ARMS Web 3.0. The intent for this release of the ARMS Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case will describe how a USER would create a rental reservation in the ARMS Web system. When creating a reservation, the USER is also creating an authorization for payment. The USER may also submit a reservation without authorizing payment.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events includes all steps necessary to create a reservation using the ARMS Web system.
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
Unauthorized Request Matches
Authorized Matches
1.5.3 Alternative Flows
1.5.3.1 Initial Reservation Information Invalid
1.5.3.2 Unauthorized Request/Authorized Request Search Matches
1.5.3.3 Reservation Information Invalid
1.5.3.4 Cancel Use Case
1.7.1 Requirements for Reference Number Formatting
1.7.2 Requirements for Finding Rental Location
1.7.3 Requirements for Routing a Reservation
1.7.4 Maintenance of Source Systems
An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below.
1.8.1 MA-10—Authorize Request
1.8.2 MA-19—View Customer File
1.8.3 MA-02—Find Rental Location
1.8.4 MA-04—Send Message
1.8.5 MA-07—Additional Charges
1.8.6 MA-08—View Car Classes
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Initial Reservation Screen
The Initial Reservation screen provides the user interface and functions to support Steps 2 through 4 of the Basic Flow. The information captured on this screen will allow the system to perform several background search activities, and help to better construct the Quick/Detailed Reservation screen. All information captured on the Initial Reservation screen is required to create a new reservation, and is reused later in the reservation creation process.
2.1.1 Screen Layout—see
2.1.2 Screen Field Definition
2.1.3 Screen Function Definition
2.1.3.1 Create Reservation
The Authorization Matches Found screen provides the functions to support the Unauthorized Request/Authorized Request Search Matches alternative flow.
2.2.1 Screen Layout—see
2.2.2 Screen Field Definition
2.2.4 Screen Function Definition
2.2.3.1 New Reservation
The Quick Reservation screen provides support for Step 9 of the Basic Flow.
IMPORTANT NOTE: This is the minimum allowable set of fields on the Quick Reservation screen. The Quick Reservation screen will also include any fields indicated as QUICK RESERVATION in the company/office profile! See the Detail Reservation screen for all available fields.
2.3.1 Screen Layout see
2.3.2 Screen Field Definition
2.3.3 Screen Function Definition
2.3.3.1 More Locations
2.3.3.2 Additional Charges
2.3.3.3 View Car Class
2.3.3.4 Select a Favorite Location
2.3.3.5 Confirm Reservation
2.3.3.6 Cancel
The Reservation Confirmation screen provides the user interface and functions to support Step 16 of the Basic Flow. This provides the USER with confirmation feedback on successful submission of the reservation.
2.4.1 Screen Layout—see
2.4.2 Screen Field Definition
2.4.3 Screen Function Definition
2.4.3.1 Return to Home Page
2.4.3.2 Change Reservation
1. Find a Rental Location Use Case
1.1 Application Overview
The following is a document used to illustrate the process of finding and selecting an alternate rental location for a reservation created using ARMS/Web 3.0. The intent for this release of the ARMS/Web application is to reach a much wider audience. This application will target a Multi-Vendor, Multi-Segment, and International customer base.
1.2 Brief Description
This use case describes the process of finding and selecting an alternate rental location for a reservation created in the ARMS/Web system. The USER will have the ability to select the location search criteria they want to use (i.e. phone number or postal code), select the rental company and select to either review a list of nearby rental company locations or have the system automatically determine a rental company location based on the location search criteria. (The USER will also have the ability to select an alternate location by using the ‘Favorite Locations’ functionality built into the Create Reservation screens.) This use case provides the mechanism to return rental company location information, including address, rental company, and phone number to create a new reservation or define a favorite location.
1.3 Use Case Actors
The following actors will interact with this use case:
The Flow of Events includes all steps necessary to select rental location search criteria and retrieve an alternate rental branch location (s).
1.5.1 Activity Diagram—see
1.5.2 Basic Flow
1.5.3 Alternative Flows
1.5.3.1 Search Criteria Entered is Invalid
1.5.3.2 No Rental Branch Locations Found
1.5.3.3 View a List of Rental Branch Locations
1.5.3.4 Use Case Cancellation
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.7.1 Requirements for Finding Rental Location
1.7.2 Maintenance of Source Systems
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Location Search Criteria Screen
This screen allows the USER to select/input the search criteria they want to use to find a rental location. This screen supports Steps 2 and 3 of the Basic Flow.
2.1.1 Screen Layout—see
2.1.2 Search for Rental Location
2.1.3 Screen Function Definition
2.1.3.1 Next
This screen allows the USER to review/select a rental location based on the search criteria entered on the Location Search Criteria screen. The screen will present 5 matching records at a time to the USER. The USER is given the option of viewing additional detail on a location or entering new search criteria. If there are more locations selected by the search, the USER will view the next locations (up to 5). This screen supports Step 4 of the Basic Flow.
2.2.1 Screen Layout—see
2.2.2 Screen Field Definition
2.2.3 Screen Function Definition
2.2.3.1 Select this Location
2.2.3.2 Next X of Y
2.2.3.3 Previous 5 of Y
2.2.3.4 Details/Map
2.2.3.5 Search Again
This screen allows the USER to view additional details for a given rental location. This screen supports the View Location Detail alternate flow.
2.3.1 Screen Layout—see
2.3.2 Screen Field Definition
2.3.3 Screen Function Definition
2.3.3.1 Select this Location
2.3.3.2 Previous
2.3.3.3 Enlarge Map
2.3.3.4 Reduce Map
2.3.3.5 Zoom In
2.3.3.6 Zoom Out
Issue Number: 307
Question: We have heard from the business that the search by name criteria needs to be better. Today we search by the first three letters of the last name. We need to know what criteria is the preferred method of search to be done.
For example: Do we search the entire last name and first name?
Status: 12 User Review
Resolution: 4-17-00, Sean O'Donnell—We have spoken to the Rental Redesign folks to find out how they are doing last/first name matching, and they are not planning to search by name in the new rental system (Telephone Number, Driver's License, and SSN only). They were going to have an ‘implied wildcard’ search by name, but it was taken out in USER review.
Issue Number: 310
Question: Do we want the ARMS/Web to have search available by phone, zip code/postal code, city and state. Current state only allows for phone number searches. Do we want to search other than phone number
For example: Do we want to search by phone number or zip code?
Status: Closed—Resolved
Resolution: 3-16-00, Jen Cavanaugh—Talking with Dave Smith. 3-22-00, Issue Mtg. Search by phone # & zip code only.
Issue Number: 311
Question: If a daily rental branch is closed, how do we want the system to work?Current state it defaults to Claims Connection. We need clarification on how this should work in the ARMS/Web environment.
3-17-00, Application Team—What do we want to see in the locator, do we want to see just open only or all? If no branch is open do we return to Claims Connection?
Status: Closed—Resolved
Resolution: 3-16-00, Jen Cavanaugh—Stan's team is going to get w/claims Connection to see how this process works after hours. From there we will make some business decisions 3-20-00, Jennifer Cavanaugh—Stan's team needs to research how ARMS & Retail Res Locator works & how they differ. Then we will re-review the question.
3-27-00, Sean—I talked with Trent Tinsley and Kim Devallance on this topic, which was EXTREMELY helpful. If the adjuster selects a closed branch, the system will route the ticket based on the type of service established in the insurance company profile:
Insurance companies that do NOT have 24-hour service, the reservation will be routed to the branch that was selected. The branch will do a callback in the morning when they re-open. Insurance companies that have 24-hour service have their reservations re-routed to Claims Connection (who will do a callback prior to 9 pm in any time zone unless otherwise specified by an adjuster) if the selected office is not open. This determination is made in the background after the adjuster submits the reservation. Claims connection will re-route the reservation to the appropriate branch when the customer is contacted.
Essentially, the way that location selection is handled today can/should be supported in the future version of ARMS/Web (location selection is implied through the F2—Rates function of ARMS/400). Please let me know if you have questions with regard to this issue update/resolution.
Issue Number: 374
Question: In the Create Reservation functional specification, we have stated that the system will pull a location and rates immediately for the USER. The issue arises when we have no location to retrieve, in cases that the ‘where needed’ search criteria is weak or we don't have a branch within 50 miles of the search area. In the current state, we show Claims Connection as if it were a branch in this situation. This can be somewhat confusing (to see the location of Hanley Road in St. Louis if you are in Delaware). In the future state, we think it may be a good idea to notify the USER that no location was found, and that the reservation would be handled by Claims Connection (see example message below). Any thoughts on this question . . .
Example Message:
A rental branch could not be found within 50 miles of 555-512-5000. Claims Connection will ensure your reservation is handled immediately. Please call 800-CLAIMSCONNECTION for additional assistance.
Status: Pending
Resolution: 5-8-00, Response from Sean O'Donnell: Dave liked the idea, and so did Kim. Have not heard from Randy on this one, though. Let me know if you need me to follow up, otherwise this will be written in to the specification for Finding a rental location.
1. Send Message Use Case
1.1 Brief Description
This use case describes the process of capturing messages and diary notes associated with a rental reservation/authorization. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization (MESSAGE in this document), or to store the note in the ARMS Web system without sending the message to Enterprise (DIARY NOTE in this document). All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.
NOTE: This is a sub-use case that must be accessed from another use case. For example, a USER may send a message while creating a reservation, maintaining an authorization, or completing an extension.
1.2 Use Case Actors
The following actors will interact with this use case. All actors are referred to as USER throughout this use case:
The Flow of Events includes all steps necessary to enter MESSAGES and DIARY NOTES.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Send Diary Note Only
1.4.3.2 Use Case Cancellation
1.6.1 Submit Message Responsibilities
None.
2. Screen Design
As noted in the Send Message Use Case, the Send Message function will be available on multiple screens throughout the system (e.g., Create Reservation, Extend Rental, Change Authorization). This section provides functional description of the screen container that is used on the multiple screens to support the Send Message use case.
2.1 Message Screen Container
The area of the screen under consideration is the container beginning with the Notebook heading. This is an example of how the message container might look on any given screen.
2.1.2 Message Screen Container
2.1.3 Screen Function Definition
Issue Number: 341
Question: Current state ARMS400 allows user to enter maximum of four lines of fifty characters. Current state ARMS has program limitation of ten lines of fifty characters. ARMS Web will be limited by current state ARMS. Should that be the planned maximum for ARMS Web or ??? One idea would be to have the number of lines/characters profiled. Then the size of the message box that is displayed to the user would be limited by this profiled amount.
Status: Closed—Resolved
Resolution: 3-30-00, Kim De Valiance—I think ten lines of fifty characters to be entered by any user at a time is more than enough. I don't really for see the need to profile this by company.
Issue Number: 342
Question: Current state allows message to be sent on unauthorized requests only if they have not been assigned to an adjuster. How should future state work? If we allow messages on assigned unauthorized requests, we must keep in mind that we are defaulting the Direct-Bill To percent at 100% on all auth. screens. When the adjuster submits the message, they MAY be unintentionally authorizing the request.
Status: Closed—Resolved
Resolution: 3-30-00, Kim De Valiance—Kim: we should never send an authorization to the branch if all the adjuster did was key in a message. The message will either appear in ECARS under res notes or callback notes, but should never appear to the branch as an authorization. We not only need to give the adjuster the ability to send a message, but they should be able to change info (such as claim number, claim type, etc.) before assigning the request to the adjuster, thereby enabling the adjuster to see the correct info when authorizing or denying a DB. We hear this request a lot from our customers.
1. Additional Charges Use Case
1.1 Brief Description
The Additional Charges use case will allow the USER to view, add, or modify/remove any additional charges that may be associated with a rental authorization. Additional Charges such as Collision/Damage Waiver (CDW), Mileage Charge, or any other rental related charge could be authorized by a USER through this function.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to view, add and modify additional charges associated with a rental authorization.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Additional Charges Invalid
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.6.1 Submit Additional Charges Responsibilities
1.6.2 Additional Charges Descriptions
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Additional Charges
This screen will allow the user to view, add, modify or remove additional charges associated with a reservation/authorization.
2.1.1 Screen Layout—see
2.1.2 Screen Field Definition
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Create More Surcharges
The Create More Surcharges screen function will allow the USER to select the hyperlink and have an additional Misc. Charge line added to the screen. For example, the Screen Layout above shows only one Misc. Charge box. If a USER were to click on the Create More Surcharges hyperlink, the screen would refresh and provide the user with two Misc. Charges boxes. The USER is not limited to the number of Misc. Charge boxes that can be added.
2.1.3.1.1 The Create More Surcharges screen function is invoked through clicking a hyperlink.
2.1.3.2 Process
The Process screen function allows the USER to save the additional charges that are being authorized and return to the active reservation or open ticket. The active reservation or open ticket will reflect that additional charges have been added.
2.1.3.2.1 The Process screen function is invoked through a button click or through an Enter keystroke.
2.1.3.3 Previous
The Previous screen function will allow the USER to return to the active reservation or open ticket without saving the updates to additional charges.
2.1.3.3.1 The Previous screen function is invoked through a button click.
3. Questions and Answers
None.
Functional Design Specification
View Car Class
Version 1.2
1. View Car Class Use Case
1.1 Brief Description
This use case will allow the USER to view examples of automobiles that are part of each Enterprise Car Class. The USER will have the ability to select a car class and have the rate for the car class apply to the reservation/authorization.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to view and/or select the car class to apply to a rental reservation.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
The Basic Flow of the View Car Class use case includes all of the required steps to view and/or select a car for a rental reservation. If a car class is selected, it will be used to populate rate information on a rental authorization.
1.4.3 Alternative Flows
1.4.3.1 Select Alternate Car Class
From Step 2 of the Basic Flow, the USER will have the ability to view an alternate car class. The car classes that will be available to view include:
If the USER selects an alternate car class, the system will refresh and present the details of the new car class.
1.4.3.2 Populate Car Class Rates
If a rental branch location has already been selected prior to entering this use case, the selection of a car class will populate the rates that apply to the selected car class on the active reservation or open ticket. This alternate flow returns the USER to Step 4 of the Basic Flow.
1.5 Post-Conditions
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.6.1 Modify Car Class Selection Results
The USER may change the results of this use case as part of the active reservation or open ticket.
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Car Class Detail Screen
This screen (see
2.1.1 Screen Layout—see
2.1.2 Car Class Details
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Select this Car Class
The Continue screen function will allow the USER to select the car class to apply to a reservation.
2.1.3.1.1 The Continue screen function is invoked through either a button click or through an Enter keystroke.
2.1.3.2 Previous
The Previous screen function allows the USER to return to the previous screen.
2.1.3.2.1 The Previous screen function is invoked through a button click.
3. Questions and Answers
None.
Functional Design Specification
Assign a Request
Version 1.1
1. Assign a Request Use Case
1.1 Brief Description
This use case describes the process of how a USER will review unassigned authorization request and assign them to an adjuster for further handling.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “Assign an Action Item”.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Cancel Use Case
The USER should be capable of leaving the use case at any point prior to assigning the reservation information to an ADJUSTER.
1.4.3.2 Modify a Request
Before step 6 of the basic flow, the USER should be able to make changes to the authorization.
1.4.3.3 Select a Different Office
Before step 6 of the basic flow, the USER should be able to select a different office for this authorization request. If a different office has been selected, the user cannot assign the file to a new adjuster. The new office must now assign the file.
1.5 Post-Conditions
If the use case is successful, the system will change the request type from an unassigned authorization request to direct bill. If the user has authority to authorize this request, the system will change the request to Authorized status and assign the adjuster picked in Step 5 of the basic flow.
If the use case is unsuccessful, the system state will remain unchanged.
1.6 Special Requirements
None.
1.7 Extension Points
1.7.1 MA-04 Send Message
The Send Message function will be used to allow the user to capture messages and diary notes associated with a rental reservation/authorization. The USER can elect to have the message sent to the Enterprise rental branch location responsible for the reservation/authorization. The USER may also send a message without assigning the file to an adjuster/office. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.
1.7.2 MA-10 Authorize a Request
The ADJUSTER may decide to enter into the full detail screen of the unassigned request, which would invoke the Authorize a Request case.
1.7.3 MA-17 Cancel Authorization
At any point prior to assigning the file to an ADJUSTER, the USER should have the ability to cancel the authorization. If the authorization is canceled, the ADJUSTER will be prompted to select a cancellation reason code from a drop down list along with having the option to enter additional comments.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Action Items—Unassigned
This screen will allow the USER to assign action items to a claims office or an adjuster or the USER may cancel an item. The USER may also change specified information in the Customer File through this screen.
2.1.1 Screen Layout—Action Items—Unassigned—see
2.1.2 Action Items—Unassigned
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 <<Previous
When clicked, the USER will be taken back to the previous screen.
2.1.3.2 Process
When clicked, the USER will be taken to the next item in the action item list or a detail of the completed action items. This button ends the use case.
2.1.3.3 Cancel
When clicked, the USER will be allowed to cancel the authorization. If this occurs, the rental becomes unauthorized and the rental is no longer the responsibility of the insurance company.
2.1.3.4 Last Action Message
After each action item in the USER's list has been completed, upon arriving at the next item there will be a confirmation message at the top of the screen. This message will be a hyperlink describing the last completed action. If the USER clicks on this link, the system will open the customer file, which will reflect all of the current information for the rental. The USER is then free to make additional changes or to simply view the file.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Address Line
4.1.2 City
4.1.3 Claim Type Code
4.1.4 Claim Type Description
4.1.5 Company Identifier
4.1.6 Date of Loss
4.1.7 Day Phone
4.1.8 External Organization Abbreviated Name
4.1.9 External Organization Identifier
4.1.10 First Name
4.1.11 First Name
4.1.12 Handled by Adjustor Code
4.1.13 Handled by Company Identifier
4.1.14 Handling for Adjustor Code
4.1.15 Handling for Company Identifier
4.1.16 Insurance Claim Number
4.1.17 Last Name
4.1.18 Last Name
4.1.19 Loss Type Description
4.1.20 Note
4.1.21 Renters Day Phone Extension
4.1.22 Renters Night Phone
4.1.23 Renters Night Phone Extension
4.1.23 State
4.1.24 Zip Code
5. Questions and Answers
Issue Number: 345
Question: Do we force the user to view the Rental Detail in order to change the unassigned adjuster to an adjuster who is authorized to handle?
Status: Closed—Resolved
Resolution: 4-12-00, Randy Haselhorst, we don't want to force them to look at the detail to assign a rental request to another user. They primarily look for claim number, claim type, renter name and possibly date of loss. If you can make the option you've described intuitive, that may work, but it doesn't sound that way to me.
4-12-00, Kim De Valiance, NO—This is a great feature, but I don't know if it is necessary. Some companies use this feature, while others wait for the phone call to authorize.
Issue Number: 346
Question: Should you be allowed to decline, authorize or extend an unassigned rental.
Status: Closed—Resolved
Resolution: 4-12-00, Randy Haselhorst—you can't “extend” until you've authorized. Decline could be an option, but we should probably think about that more to determine if we should. Current state does not have this but I have heard people ask for it. As far as authorizing, that again may be a good idea. I′d like to see Kim and Dave's ideas. 4-12-00, Kim De Valiance—Yes, we have heard this many, many times that will assigning a rental, the user should have the ability to do all these things (as long as the user has the proper authority).
Issue Number: 361
Question: Can we pass along an unassigned to another office?
Status: Pending
Resolution: Yes, if the request is an unassigned status, the USER can transfer it to another office.
Issue Number: 378
Question: Can we Exit the use case after Sending a Message and leave the request unassigned? Iteration 2 question.
Status: Closed—Resolved
Resolution: 6-23-00 Per Brian Weingart, —yes, after sending a message on an unassigned request, if we didn't assign an adjuster, it is still unassigned.
Issue Number: 413
Question: 6-23-00, Only one person can handle un-assigns—which is set up in the profile? Or can a multiple # of people handle the un-assigns? Does the Handling for drop down box allow for the selection of unassigned? How do we handle record locking? Per Jennifer, Sean is working on this issue.
Status: Pending
Resolution:
Issue Number: 414
Question: 6-23-00, If I select Unassigned from the action item list and only one exists do I go straight to the detail? Per Jennifer—Sean is working on this issue.
Status: Pending
Resolution:
Issue Number: 415
Question: 6-23-00, If I select Unassigned from the action item list and multiple exists I go straight to the detail. I go to a screen, which looks like action items, but list all of the unassigned. Per Jennifer—Sean is working on this issue.
Status: Pending
Resolution:
Functional Design Specification
Authorize a Request
Version 1.1
1. Authorize Request Use Case
1.1 Brief Description
This use case describes how a USER authorizes a direct bill request.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “Authorize Request”.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 View Notebook
At step 3 of the Basic Flow, the USER can select to view the transaction history (Notebook) by selecting the Go To Notebook link.
1.4.3.2 Add Notes to Customer File
At step 3 of the Basic Flow, the USER can add notes to the Customer File by typing in the appropriate notes field on the Customer File page.
1.4.3.3 Skip Customer File
At step 3 of the Basic Flow, the USER should have the ability to skip to the next action item by clicking the Skip button. After clicking the Skip button, the USER should be taken to the next action item on their current list without any changes to the file being skipped.
1.4.3.4 Change Customer File
At step 3 of the Basic Flow, the adjuster can make changes to the additional details of the Customer File. This is done by selecting the Add/Change link which will invoke an editable page with all *appropriate information editable.
1.5 Post-Conditions
1.6.1 Requirements for Claim Type Authorizations
The following are a set of requirements surrounding the type of authorized amounts that are allowable based on the Claim Type associated with a rental. These restrictions DO NOT APPLY to reservations that are submitted with a Direct Billing Percentage of zero (0).
1.6.1.1 When the Claim Type Selected is ‘Insured’, ‘Theft’, or ‘Uninsured Motorist’
1.6.1.1.1 The reservation/rental must always include an Authorized Rate or both Policy Daily and Maximum Limits as defined by the renter's insurance policy. Zero (0) is an acceptable Policy Daily Limit.
1.6.1.1.2 The reservation/rental must include an Authorized Rate or Policy Daily Limit if a Policy Maximum Limit is included. Zero (0) is an acceptable Policy Daily Limit.
1.6.1.2 When the Claim Type Selected is ‘Claimant’
1.6.1.2.1 The reservation/rental must always include an Authorized Rate.
1.6.1.2.2 The reservation/rental may not include a Policy Daily/Maximum Limits selection.
1.6.1.3 Requirements for Editable Fields Based on Reservation/Ticket Status
1.6.1.3.1 Depending on the status of the Customer File the adjuster may change the following fields:
If the Customer File is an Unauthorized Reservation, the adjuster can Reject the Authorization Request, Send a Message, and/or Transfer (Assign) the file to an adjuster.
1.6.1.3.2 If the status of the Customer File is an open ticket the following rules apply:
1.7 Extension Points
An extension point indicates a link between this use case and another use case.
Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.
1.7.1 MA-04 Send Message
The Send Message will be used to allow the USER to capture messages and diary notes associated with a rental reservation/authorization. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization, or to store the note in the ARMS Web system without sending the message to Enterprise. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.
1.7.2 MA-16 Transfer Work
(The Change Adjuster button invokes this use case).
The ADJUSTER may choose to transfer an authorization to a different adjuster in his/her office or transfer the authorization to another adjuster in a different office.
1.7.3 MA-08 View Car Class
The ADJUSTER may choose to view the car class. This button invokes the View Car Class use case.
1.7.4 MA-17 Cancel Authorization
The ADJUSTER may choose to deny the authorization. When the ADJUSTER selects the CANCEL button, it will invoke the Cancel Authorization use case to reject the authorization.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Authorize Rental Detail
This screen will allow the user to work the currently selected authorization request. The user may set the authorization amounts and policy coverage limits or may assign the request to another adjuster.
2.1.1 Screen Layout—Authorize Rental Detail—see
2.1.2 Authorize Rental Detail
days @
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Skip
When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.
2.1.3.2 Process
When clicked, the system will validate the input and accept the changes made to the customer file. The arms database will be updated and the data will be sent to the arms system. The use case will then end and the USER will return to the process from which they came.
2.1.3.3 Notebook
When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.
2.1.3.4 Transfer File
When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or adjuster currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the profiled start page, depending on the screen from which the USER began.
2.1.3.5 Change or Add
When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.
2.1.3.6 Top of Page
When clicked, the USER will be taken to the top of the current page.
2.1.3.7 View Car Class
When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Add Date
4.1.2 Address Line
4.1.3 Address Line
4.1.4 Address Line2
4.1.5 Bill to %
4.1.6 Branch
4.1.7 City
4.1.8 City
4.1.9 City
4.1.10 Claim Type Code
4.1.11 Claim Type Description
4.1.12 Company Identifier
4.1.13 Date of Loss
4.1.14 Day Phone
4.1.15 Dollars Per Day Covered
4.1.16 External Organization Abbreviated Name
4.1.17 External Organization Identifier
4.1.18 First Name
4.1.19 First Name
4.1.20 First Name
4.1.21 Group
4.1.22 Insurance Claim Number
4.1.23 Last Name
4.1.24 Last Name
4.1.25 Last Name
4.1.26 Loss Type Code
4.1.27 Loss Type Description
4.1.28 Max $ Covered
4.1.29 Note
4.1.30 Number of Days Authorized
4.1.31 Rental Location
4.1.32 Renter Email
4.1.33 Renter Make/Model
4.1.34 Renter Vehicle Year
4.1.35 Renters Day Phone Extension
4.1.36 Renters Night Phone
4.1.37 Renters Night Phone Extension
4.1.38 Repair Facility Name
4.1.39 Start Date
4.1.40 State
4.1.41 State
4.1.42 State
4.1.43 Status Description
4.1.44 Telephone Number
4.1.45 Telephone Number
4.1.46 Vehicle Class
4.1.47 Vehicle Rate
4.1.48 Zip Code
4.1.49 Zip Code
5. Questions and Answers
Issue Number: 419
Question: 6-23-00, When rejecting an authorization do we want a reason code? Per Jennifer—Mike, Brad and Craig is handling this.
Status: Pending
Resolution: 7-03-00—Brad Reel: In the ARMS Web V2.0 application reason codes will be collected for the following events: reject invoice, terminate authorization. Per a discussion with Randy Haselhorst, it would be worthwhile to collect a reason code for reject/cancel authorization. However, it is not critical for this release. If possible it should be incorporated.
07-03-00—Brad Reel: I am reassigning to Mike Slater to work with Neil Fitzgerald and determine whether or not to incorporate in V2.0, or wait until a later release.
Functional Design Specification
Change Customer File
Version 1.1
1. Change Customer File Use Case
1.1 Brief Description
The Change Authorization use case describes how the USER could change an authorization assigned to a reservation nor an open rental.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes to a Customer File.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 View Rental Notebook
At step 1, the USER may choose to view the history of a rental. The USER will be able to see the last five diary notes. The USER can also select to view the transaction history or add diary notes from the Extend Rental Detail.
1.4.3.2 Validate Changes
If the USER changes or adds information, which does not pass validation, an error message will notify the USER and return them to step 1 of the Basic Flow.
If an error is discovered in the validation of the reservation/rental information submitted by the USER (Step 3 of the Basic Flow), the system would present the USER with an error message and return them to the Detailed Reservation/Rental Display. If the error is specific to a data field within the form, the field should be highlighted and the error described.
1.4.3.3 Display Confirmation
After step 6, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional; therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.
1.4.3.4 Update USER Profile
During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.
1.5 Post-Conditions
1.7.1 MA-04 Send a Message
The Send Message will be used to allow the USER to capture messages and diary notes associated with extending a rental. The USER can elect to either have the message sent to the Enterprise rental branch location responsible for the reservation/authorization, or to store the note in the ARMS Web system without sending the message to Enterprise. All MESSAGES and DIARY NOTES captured must be related to a specific reservation/authorization.
1.7.2 MA-16 Reassign User or Office (the Transfer File Button Invokes this Use Case)
After the extend rental detail is displayed, the USER may choose to change the current office/USER. First, the USER would select to change the current office/USER. Second, the system would display a list of authorized offices/USERs. Third, the USER would select a new office/USER.
1.7.3 MA-15 Terminate a Rental (Set Last Day)
After the extend rental detail is displayed, the USER may choose to terminate the rental. If termination is selected, the USER must enter a reason for the termination of the rental. Termination means the insurance company is no longer willing to pay for the rental. This function (button) is only available for an open ticket. For reservation status, the USER should see the Cancel button.
1.7.4 MA-17 Cancel Authorization
Before step 5 of the Basic Flow, the USER should have the capability to cancel the authorization. Before the USER has made changes that have been updated in the database and sent to ARMS, the Cancel Authorization function (button) should be available for reservation status. However, the USER cannot perform the Cancel function on an open ticket. For an open ticket, the Termination (Set Last Day) function (button) is available.
1.7.5 MA-08 View Car Class
The View Car Class use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The car class selected by the USER should be applied to the reservation.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Change Rental Detail
This screen (see
2.1.1 Screen Layout—Change Rental Detail—see
2.1.2 Change Rental Detail
additional
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Skip
When clicked, the USER will be taken out of the use case without changing the current status of the request. Any changes made by clicking Change or Add and keying data in the bottom section will be saved.
2.1.3.2 Process
When clicked, the system will validate the input and accept the changes made to the customer file. The arms web database will be updated and the data will be sent to the arms system. The use case will then end and the USER will return to the process from which they came.
2.1.3.3 Notebook
When clicked, the USER will be taken to the Note Book section at the bottom of the screen to view all messages for this rental.
2.1.3.4 Set Last Day
When clicked, the system will terminate the rental. The USER will be prompted to enter a termination date for this rental. This coincides with the use case MA-15-Terminate Rental.
2.1.3.5 Transfer File
When clicked, the USER will be taken to the Transfer File screen. This screen allows the USER to change the office or adjuster currently assigned to the customer file. The required information in the Extend Rental/Customer File will be passed to the Transfer File screen. Upon completion of the transfer, the USER will then be returned to the next action item or the profiled start page, depending on the screen from which the USER began.
2.1.3.6 Change or Add
When clicked, the system will refresh the current screen and make all editable fields in the bottom section (outside the gray box area) input capable. The changes on the top of the screen will not be lost.
2.1.3.7 Top of Page
When clicked, the USER will be taken to the top of the current page.
2.1.3.8 View Car Class
When clicked, the USER will be taken to the View Car Class Use Case. No changes will be lost. Once the USER is finished with this use case, the USER will return to the Extend Rental Use Case.
2.1.3.9 Extend Rental (Checkbox)
When clicked and the process button is clicked, the system will validate the input and accept the extension AND any other changes made to the customer file. The arms web database will be updated and the data will be sent to the arms system. The use case will then end and the USER will proceed to the next action item. (If unchecked and the process button is clicked, only the changes to the screen will be saved. The extension will NOT be executed.)
2.1.3.10 Last Action Message
After each action item in the USER's list has been completed, upon arriving at the next item there will be a confirmation message at the top of the screen. This message will be a hyperlink describing the last completed action. If the USER clicks on this link, the system will open the customer file, which will reflect all of the current information for the rental. The USER is then free to make additional changes or to simply view the file.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Add Date
4.1.2 Address Line
4.1.3 Address Line
4.1.4 Address Line2
4.1.5 Branch
4.1.6 City
4.1.7 City
4.1.8 City
4.1.9 Claim Type Code
4.1.10 Claim Type Description
4.1.11 Company Identifier
4.1.12 Date of Loss
4.1.13 Day Phone
4.1.14 External Organization Abbreviated Name
4.1.15 External Organization Identifier
4.1.16 First Name
4.1.17 First Name
4.1.18 First Name
4.1.19 Group
4.1.20 Insurance Claim Number
4.1.21 Last Name
4.1.22 Last Name
4.1.23 Last Name
4.1.24 Loss Type Code
4.1.25 Loss Type Description
4.1.26 Message ECARS Indicator
4.1.27 Note
4.1.28 Number of Days Authorized
4.1.29 Rate Charged
4.1.30 Rental Location
4.1.31 Renter Email
4.1.32 Renter Make/Model
4.1.33 Renter Vehicle Year
4.1.34 Renters Day Phone Extension
4.1.35 Renters Night Phone
4.1.36 Renters Night Phone Extension
4.1.37 Repair Facility Name
4.1.38 Standard Message Description
4.1.39 Start Date
4.1.40 State
4.1.41 State
4.1.42 State
4.1.43 Status Description
4.1.44 Telephone Number
4.1.45 Telephone Number
4.1.46 Vehicle Class
4.1.47 Vehicle Rate
4.1.48 Zip Code
4.1.49 Zip Code
4.1.50 Zip Code
5. Questions and Answers
Issue Number: 368
Question: Can the Adjuster shorten the number of days authorized without terminating the rental.
Status: Closed—Resolved
Resolution: 5-3-00, Brian Weingart, Kim De Valiance—No. After a ticket is open and has been authorized, the only modification allowed to the number of days authorized comes in the form of a termination. For example, if an adjuster sent us ten days and on the fifth day, decided to only give us a total of six (thereby removing the authorization for four days) the adjuster would have to terminate that rental as of the sixth day.
Issue Number: 386
Question: Should the Date of Loss be editable in Change Authorization or does it depend on the state of the reservation/ticket.
Status: Closed—Resolved
Resolution: 6-23-00, Brian Weingart, —Since Date of Loss is considered Insurance company information, the adjuster owns this information. The Adjuster can change this in either a reservation or open ticket status. This is editable until the rental is considered closed.
Functional Design Specification
Terminate Rental
Version 1.0
1. Terminate Rental Use Case
1.1 Brief Description
The Terminate Rental use case describes how the USER would terminate a rental. This use case will allow the USER to inform Enterprise of the last day that the ADJUSTER will pay for a rental. In most cases, by providing a date in the future, Enterprise will receive an extension through the last day.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to terminate a rental.
14.1 Activity Diagram—see
14.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Previous
After step 3, the USER can abandon all changes, which result in the system state remaining unchanged. After clicking the “Previous” button, the USER will be returned to the screen from which they came.
1.4.3.2 Additional Comments
When terminating a rental, the USER must select a reason from the drop-down box to explain why the termination is taking place. As well, if further explanation is desired there is a comment box in which the USER may enter additional comments for more clarification. This section is optional, unless the USER selects “Other” from the reason code drop-down box. In this case, the comment box must be used.
1.4.3.3 Display Confirmation
After step 7, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional; therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.
1.4.3.4 Update User Profile
During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.
1.5 Post-Conditions
1.6.1 The termination date must be greater than or equal to the current date or the last day authorized. There is a business rule that ensures that an adjuster cannot take away already used rental days.
1.6.2 If the USER extends an authorization that has been terminated, the termination information is considered invalid.
1.6.3 It is mandatory that a USER select a termination reason from the drop-down list. If the USER selects “Other” from the drop-down list, a comment about the termination must be supplied.
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Terminate Rental
This screen (see
2.1.1 Screen Layout—Terminate Rental—see
2.1.2 Terminate Rental
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Previous
Will return the user to the detail screen from which they came. The system and the information on the detail screen will remain unchanged.
2.1.3.2 Process
When clicked, the system will complete the termination of the rental and notify the required parties.
2.1.3.2.1 The user must have selected a valid termination date that is greater than the current date.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Company Id
4.1.2 External Organization Abbreviated Name
4.1.3 External Organization Identifier
4.1.4 First Name
4.1.5 First Name
4.1.6 Insurance Claim Number
4.1.7 Last Name
4.1.8 Last Name
4.1.9 Note
4.1.10 Renter Email
4.1.11 Termination Date
5. Questions and Answers
Issue Number: 373
Question: How is the renter currently notified of a termination of the rental? Are they usually notified by the time the rental is terminated? How should this be represented on the screen? Should the checkbox say to notify the renter or that the renter has already been notified?
Status: Pending
Resolution:
Functional Design Specification
Transfer File
Version 0.6
1. Transfer File Use Case
1.1 Brief Description
The Transfer File use case describes how the user would assign one of their action items to another user/office.
1.2 Use Case Actors
The following actors will interact with this use case. Each of the actors can be defined generically as USER. The USER will use this use case to reassign action items to other USERS and/or offices.
The Flow of Events will include the necessary steps for a USER to reassign action items.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Change Office
After step 3 of the basic flow, the USER may choose to assign the action item to a new office. If the USER chooses a new office, the flow would return to step 2 of the basic flow. This should reflect possible recipients of the action item from that office.
1.4.3.2 Cancel Use Case
The USER may cancel the use case at any point prior to updating the ARMS Web Database. If the USER elects to cancel the use case, the customer file will not be transferred, however, any other changes that were made to the file will remain.
1.4.3.3 Display Confirmation
After step 7, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional, therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.
1.4.3.4 Update User Profile
During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.
1.5 Post-Conditions
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Transfer File
This screen (see
2.1.1 Screen Layout—Transfer File—see
2.1.2 Transfer File
2.1.3 Screen Function Definition
2.1.3.1 Cancel
When clicked, the USER will be returned to the screen/use case where they were prior to selecting Change Office/Adjuster (Transfer). Any changes made will be lost and the system will remain unchanged.
2.1.3.2 Process
When clicked, the system will be validated. If the validation passes, the update will be sent to the ARMS system and the USER will be returned to the screen/use case from which they came. If the validation fails, the USER will be returned to the current screen with error message(s) and the field in error highlighted.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 External Organization Abbreviated Name
4.1.2 External Organization Identifier
4.1.3 First Name
4.1.4 Last Name
Functional Design Specification
Cancel Authorization
Version 1.0
1. Cancel Authorization Use Case
1.1 Brief Description
This use case will describe how a USER would cancel an authorized reservation.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps to “Cancel Authorization”.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Previous
After step 3, the USER can abandon all changes, which result in the system state remaining unchanged. After clicking the “Previous” button, the USER will be returned to the screen from which they came.
1.4.3.2 Additional Comments
When canceling a rental, the USER must select a reason from the drop-down box to explain why the cancellation is taking place. As well, if further explanation is desired, there is a comment box in which the USER may enter additional comments for more clarification. This section is optional, unless the USER selects “Other” from the reason code drop-down box. In this case, the comment box must be used.
1.4.3.3 Display Confirmation
After step 6, the USER may wish to have a confirmation page displayed, indicating that some type of change has taken place. The confirmation page is completely optional, therefore, at anytime the USER wants to set their profile to bypass this screen, he/she may do so.
1.4.3.4 Update User Profile
During the confirmation process, the USER has the option of changing their profile setting to display or hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect the new requirements set by the USER.
1.5 Post-Conditions
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Cancel Direct Bill Authorization
This screen (see
2.1.1 Screen Layout—Cancel Direct Bill Authorization—see
2.1.2 Cancel Direct Bill Authorization
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Previous
When clicked, the user will be returned to the screen/use case where they were prior to selecting Cancel Reservation. Any changes made will be lost and the system will remain unchanged.
2.1.3.2 Process
When clicked, the system will update the message file with the comment record if entered and mark the current reservation authorization as cancel. The cancellation and the new message, if entered, will be forwarded to the ARMS system. The system returns the USER to the appropriate Action Items List screen.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Cancel Date
4.1.2 Cancellation Code
4.1.3 External Organization Abbreviated Name
4.1.4 First Name
4.1.5 Insurance Claim Number
4.1.6 Last Name
4.1.7 Note
4.1.8 Rental Location
5. Questions and Answers
Issue Number: 418
Question: Do we need a reason to cancel—have cancel page.
Status: Closed—Resolved
Resolution: 6-23-00, Per Neil, kill this page, it's not necessary.
Functional Design Specification
View Customer File
Version 1.0
1. Search and View Customer File
1.1 Brief Description
This use case describes the process that a USER would use to find and view information regarding a rental. In order to view the rental detail, one of two general conditions must be satisfied:
If these conditions are not met, the USER will be taken to the appropriate use case.
1.2 Use Case Actors
All actors will use the use case to View Rental Detail in the ARMS Web system. All of the following actors can be defined generically as a USER:
The Flow of Events includes all the steps necessary to View Rental Detail in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
The Basic Flow of the View Rental Detail use case includes all of the required activities for the USER to successfully find and view information regarding an open rental.
1.4.3 Alternative Flows
1.4.3.1 Search Again
After step 3 of the basic flow, the USER may decide that they would like to conduct another search. By entering new search criteria, they would return to step 2 with new criteria and the use case could continue.
1.4.3.2 Only One Match Found
At step 2 of the basic flow, if the system only finds one match, the system will advance to step 5 of the basic flow invoking the appropriate use case for modifications.
1.4.3.3 View Only
If the Customer File selected was in a state not allowing changes, the system would display the Customer File, however, not allowing the USER to modify any information within ARMS Web.
1.5 Post-Conditions
To successfully locate a customer file, the following criteria must be satisfied:
1.7.1.1 MA-10 Authorized a Request
If the customer file were an unauthorized reservation or ticket, the system would enter the Authorization use case to allow the USER to authorize this Customer File.
1.7.1.2 MA-12 Extend Rental
If the customer file were an authorized ticket or an action item of extension status, the system would enter the Extend Rental use case to allow the USER to extend this Customer File.
1.7.1.3 MA-13 Change Authorization
If the customer file were an authorized reservation or ticket not requiring any immediate action, the system would enter the Change Authorization use case to allow the USER to authorize this Customer File.
1.7.1.4 MA-07 Additional Charges
The Additional Charges use case will be used to add special charges to the reservation being created by the USER (e.g., CDW). Any Additional Charges captured should be returned and applied to the reservation. The existence of Additional Charges should be reflected on the reservation screen.
1.7.1.5 MA-08 View Car Class
The View Car Class use case will be used to allow the USER to view details about and select a car class to apply to a reservation. Details will include the average number of passengers and luggage items that can be served by a vehicle in the specific car class. The car class selected by the USER should be applied to the reservation.
1.7.1.6 Invoicing-BI-01-Handle Unapproved Invoices & BI-02 Pay Approved Invoices & BI-03 Reject an Invoice
At step 5, the USER may elect to view approved invoices, unapproved invoices, or rejected invoices. Upon completion of this process, the USER should be returned back to step 5 of the Basic Flow.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Find a Customer (Tab)
This screen will allow the USER to view the rental.
2.1.1 Find a Customer (Tab)—see
2.1.2 Customer (Tab)
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Search
When clicked, the will search for any records that match the criteria listed.
2.2 Customer File—Closed Items
This screen will allow the USER to view the rental when closed.
2.2.1 Screen Layout—Customer File—Closed Items—see
2.2.2 Customer File—Closed Items
to
(
to
(
to
(
to
2.2.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.2.3.1 Previous
When clicked, the USER will be taken back to the use case from where they came.
2.2.3.2 Printer Friendly Version
When clicked, the system will bring up a screen that only shows the particular invoice for which you clicked this button. The USER may print from this screen.
2.2.3.3 Top of Page
When clicked, the USER will be taken to the top of the current page.
2.3 Search Results
This screen will allow the USER To view the rental when closed.
2.3.1 Screen Layout—Search Results—see
2.3.2 Search Results
2.3.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.3.3.1 Search Again
When clicked, the system will re-search the database after the USER has entered new or additional criteria.
2.3.3.2 Top of Page
When clicked, the USER will be taken to the top of the current page.
2.3.3.3 View Next 10>>>
When clicked, the system will display the next 10 items that match the search criteria.
3. Application Operations
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Add Date
4.1.2 Address Line
4.1.3 Address Line
4.1.4 Address Line2
4.1.5 Bill to %
4.1.6 Bill to End Date
4.1.7 Bill to Start Date
4.1.8 Branch
4.1.9 City
4.1.10 City
4.1.11 City
4.1.12 Claim Type Code
4.1.13 Claim Type Description
4.1.14 Company Identifier
4.1.15 Date of Loss
4.1.16 Day Phone
4.1.17 Days Authorized-Detail
4.1.18 Dollars Per Day Covered
4.1.19 End Date
4.1.20 External Organization Identifier
4.1.21 Federal ID Number
4.1.22 First Name
4.1.23 First Name
4.1.24 First Name
4.1.25 Group
4.1.26 Insurance Claim Number
4.1.27 Invoice Number
4.1.28 Last AUT Day
4.1.29 Last Name
4.1.30 Last Name
4.1.31 Last Name
4.1.32 Loss Type Code
4.1.33 Loss Type Description
4.1.34 Max $ Covered
4.1.35 Message ECARS Indicator
4.1.36 Note
4.1.37 Number of Days Authorized
4.1.38 Rate Charged
4.1.39 Record Add Date
4.1.40 Rental Location
4.1.41 Renter Email
4.1.42 Renter Make/Model
4.1.43 Renter Vehicle Year
4.1.44 Renters Day Phone Extension
4.1.45 Renters Night Phone
4.1.46 Renters Night Phone Extension
4.1.47 Repair Facility Name
4.1.48 Standard Message Description
4.1.49 Start Date
4.1.50 State
4.1.51 State
4.1.52 State
4.1.53 Status Description
4.1.54 Telephone Number
4.1.55 Telephone Number
4.1.56 Total Amount Due
4.1.57 Total Amount Received
4.1.58 Total Ticket Charges
4.1.59 Transmission Code
4.1.60 Vehicle Class
4.1.61 Vehicle Rate
4.1.62 Zip Code
4.1.63 Zip Code
4.1.64 Zip Code
The Handle Unapproved Invoices use case describes how the Adjuster would review invoices and approve them for payment. The use case will then describe the processes the Adjuster will follow in the case where the Adjuster is the one that is actually paying the invoice.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps for an ADJUSTER to approve and pay invoices.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.2.1 Individual Payment List
1.4.2.2 Bulk Payment List
1.4.2.3 Pay a Single Invoice
1.4.3 Alternative Flows
1.4.3.1 Selected Action Item is Payment List
1.4.3.2 Reject an Invoice
1.4.3.3 View Customer File
1.4.3.4 Print a Single Invoice
1.4.3.5 Print an Invoice List
1.4.3.6 Skip Invoice
1.4.3.7 Payment by Processor
1.4.3.8 Amount Being Approved Exceeds USER'S Authorization Limits
1.4.3.9 Change Claim Number
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.6.1 ARMS Web Routes Invoices
1.6.2 Includes Tax and Surcharge Data Field
1.6.3 Data Fields to Assist with Future Releases or Customer Integration
An extension point indicates a link between this use case and another use case. Extension points associated with the use case are indicated below. Clicking on the extension point will open the related use case.
1.7.1 BI-03 Reject an Invoice
1.7.2 MA-19-View Rental Detail
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Invoicing—Individual Payment
This screen will allow the user to choose to view the invoice selected in the action items list. They will choose to either pay this invoice immediately (pay now), or choose to add it to a payment list for payment later in conjunction with all their other invoices. They may also choose to print the invoice from this page. They may also optionally choose to print the rental history. The user may choose to change the claim number. Finally the user may choose to skip this invoice and leave it until later for review.
2.11 Invoicing—Individual Payment—see
2.1.3 Screen Function Definition
2.1.3.1 Printer Friendly Page
2.1.3.2 Reject
2.1.3.3 Pay Now
2.1.3.4 Add to Payment List
2.1.3.5 Skip>>
2.1.3.6 Top of Page
2.1.3.7 Transfer File
2.1.3.8 Policy Information
This screen will allow the user to choose to view the invoice selected in the action items list. They may choose to approve the invoice payment. This will add the invoice to the PROCESSOR(S) that are responsible for paying the ADJUSTER'S invoices. The user may also choose to skip this invoice and leave it until later for review. They may choose to print the invoice from this page. They may also optionally choose to print the rental history. Finally, the user may choose to change the claim number.
2.2.1 Screen Layout—Invoicing Approval.shtml—see
2.2.2 Invoice Approval
2.2.3 Screen Function Definition
2.2.3.1 Printer Friendly Page
2.2.3.2 Reject
2.2.3.3 Approve for Payment
2.2.3.4 Skip>>
2.2.3.5 Top of Page
2.2.3.6 Transfer File
2.2.3.7 Policy Information
Policy Information will only be shown under the Authorized Section if the claim type is NOT claimant.
2.3 Individual Payment List
This screen provides the user with information on what the system expects them to do, and requests a check number that will be used to pay each invoice. The user may also choose to print the invoices, and optionally print the rental history in addition to the invoices. The user may choose not to process the payment list at this time, in which case the payment list will be added to the user's action items list.
2.3.1 Screen Layout—invoicingPymtList.shtml—see
2.3.2 Individual Payment List
2.3.3 Screen Function Definition
2.3.3.1 Printer Friendly Page
2.3.3.2 Confirm Payment
2.3.3.3 Pay Later
2.2.3.4 Top of Page
This screen provides the user with information on what the system expects them to do, and requests a check number that will be used to pay each invoice. The user may also choose to print the invoices, and optionally print the rental history in addition to the invoices. The user may choose not to process the payment list at this time, in which case the payment list will be added to the user's action items list.
2.4.1 Screen Layout—Bulk Payment List—see
2.4.2 Bulk Payment List
2.4.3 Screen Function Definition
2.4.3.1 Printer Friendly Page
2.4.3.2 Confirm Payment
2.4.3.3 Pay Later
2.4.3.4 Top of Page
This section will detail all the application operations that are part of this Functional Specification Document.
3.1 Get Unapproved Invoices (Adjuster Id)
The build unapproved invoice list operation finds all the invoices, that need approval, for the specified adjuster.
3.2 Approve Invoice (Invoice Number)
The approve invoice operation marks the specified invoice as approved. This invoice is now ready to be paid.
3.3 Get Approved Invoices (Adjuster Id)
The build approved invoice list operation finds all the approved invoices for the specified adjuster.
3.4 Get Invoice Detail (Invoice Number)
The build invoice detail operation gets the relevant invoice information for the specified invoice number.
3.5 Pay Invoice (Invoice Number, Check Number)
The pay invoice operation records the check number specified by the adjuster against the specified invoice and marks the invoice as paid.
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Accounting Name
4.1.2 Action Item Assigned Date
4.1.3 Action Item Complete Date
4.1.4 Action Item Effective Date
4.1.5 Action Item Status Code
4.1.6 Action Item Type Code
4.1.7 Action Item Type Description
4.1.8 Action Related Adjustor Code
4.1.9 Action Related Company Identifier
4.1.10 Address Line
4.1.11 Address Line2
4.1.12 Adjustor Code
4.1.13 ARMS Profile ID
4.1.14 ARMS Profile ID
4.1.15 Assigned to Adjustor Code
4.1.16 Assigned to Company Identifier
4.1.17 Bill to %
4.1.18 Bill to End Date
4.1.19 Bill to Start Date
4.1.20 Check Number
4.1.21 City
4.1.22 Claim Type Description
4.1.23 Company Identifier
4.1.24 Company Structure Level Code
4.1.25 Customer Transaction ID
4.1.26 Date of Loss
4.1.27 Dollars Per Day Covered
4.1.28 End Date
4.1.29 External Organization Abbreviated Name
4.1.30 External Organization Identifier
4.1.31 Federal ID Number
4.1.32 First Name
4.1.33 First Name
4.1.34 First Name
4.1.35 Handled by Adjustor Code
4.1.36 Handled by Company Identifier
4.1.37 Handling for Adjustor Code
4.1.38 Handling for Company Identifier
4.1.39 Insurance Claim Number
4.1.40 Insurance Claim Number
4.1.41 Invoice Number
4.1.42 Item Amount
4.1.43 Item Description
4.1.44 Item Quantity
4.1.45 Item Rate
4.1.46 Last Name
4.1.47 Last Name
4.1.48 Last Name
4.1.49 Loss Type Description
4.1.50 Max $ Covered
4.1.51 Note
4.1.52 Number of Days Authorized
4.1.53 Record Add Date
4.1.54 Related Office Identifier
4.1.55 Remittance Reference #
1.56 Request Time
4.1.57 Start Date
4.1.58 State
4.1.59 Status Code
4.1.60 Telephone Number
4.1.61 Total Amount Due
4.1.62 Total Amount Received
4.1.63 Total Billed to Others
4.1.64 Total Ticket Charges
4.1.65 Vehicle Rate
4.1.66 Zip Code
5. Questions and Answers
Issue Number: 256
Question: The calculation for authorized limit when displaying the invoice detail does not take bill to percent into account when all the following conditions are true:
In all other cases, the amount is multiplied by the bill to percent to get the authorized limit. Is this calculation correct?
Status: Pending
Resolution: 3-14-00, DSE-Need to follow up with author to get a further understanding of question.
3-23-00, Issue Mtg., Will get addressed in current state and fix.
Issue Number: 257
Question: This is a presentation issue. The adjuster name on the invoice detail screen will not show up in certain cases. This code is in the *INZSR sub routine and needs some investigation of scenarios to determine the exact flaw.
Status: Closed—Resolved
Resolution: 3-14-00, DSE-Need to follow up with author to get a further understanding of question.
The Pay Approved Invoices use case describes how the PROCESSOR would review and pay invoices in the ARMS Web system.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps for a PROCESSOR to review and pay invoices.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.2.1 Individual Pay
1.4.2.2 Bulk Pay
1.4.3 Alternative Flows
1.4.3.1 View Customer File
1.4.3.2 Return an Invoice
1.4.3.3 Print an Invoice List
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.6.1 ARMS Web Routes Invoices
1.6.2 Data Fields to Assist with Future Releases or Customer Integration
1.6.3 Claim Number is Editable on the Invoice
1.7.1 MA-19-View Customer File
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Invoicing—Individual Payment List
This screen will allow the user to enter a check number for each invoice and notify Enterprise that they have processed the payment.
2.1.1 Individual Payment List—see
2.1.2 Individual Payment List
2.1.3 Screen Function Definition
2.1.3.1 Printer Friendly Page
2.1.3.2 Confirm Payment
2.1.3.3 Pay Later
2.1.3.4 Return to Adjuster
2.1.3.5 Top of Page
This screen will allow the user to pick which functions that he/she may want to change.
2.2.1 Screen Layout—Bulk Payment List—see
2.2.2 Invoicing—Bulk Payment List
2.2.3 Screen Function Definition
2.2.3.1 Printer Friendly Page
2.2.3.2 Confirm Payment
2.2.3.3 Pay Later
2.2.3.4 Return to Adjuster
2.2.3.5 Top of Page
2.3.1 Screen Layout—returnBilling.shtml—see
2.3.2 Return Billing
2.3.3 Screen Function Definition
2.3.3.1 Cancel
2.3.3.2 Return to Adjuster
This section will detail all the application operations that are part of this Functional Specification Document.
3.1 Get Approved Invoices (Office Id)
The get approved invoices operation finds all the approved invoices for the specified office.
3.2 Get Invoice Detail (Invoice Number)
The get invoice detail operation gets the relevant invoice information for the specified invoice number.
3.3 Return Invoice to Approving Adjuster (Invoice Number, Reason Code)
The return invoice to approving adjuster operation marks the specified invoice so that the approving adjuster can review the invoice and re-approve it.
3.4 Pay Invoice (Invoice Number, Check Number)
The pay invoice operation records the check number specified by the adjuster against the specified invoice and marks the invoice as paid.
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Accounting Name
4.1.2 Action Item Complete Date
4.1.3 Action Item Effective Date
4.1.4 Action Item Status Code
4.1.5 Action Item Type Code
4.1.6 Action Item Type Description
4.1.7 Address Line
4.1.8 Address Line2
4.1.9 ARMS Profile ID
4.1.10 Assigned to Adjustor Code
4.1.11 Assigned to Company Identifier
4.1.12 Bill to %
4.1.13 Branch
4.1.14 Check Number
4.1.15 City
4.1.16 Claim Type Description
4.1.17 Company Identifier
4.1.18 Company Structure Level Code
4.1.19 Customer Transaction ID
4.1.20 Date of Loss
4.1.21 Dollars Per Day Covered
4.1.22 End Date
4.1.23 External Organization Abbreviated Name
4.1.24 External Organization Identifier
4.1.25 Federal ID Number
4.1.26 First Name
4.1.27 First Name
4.1.28 Group
4.1.29 Handled by Adjustor Code
4.1.30 Handled by Company Identifier
4.1.31 Handling for Adjustor Code
4.1.32 Handling for Company Identifier
4.1.33 Insurance Claim Number
4.1.34 Insurance Claim Number
4.1.35 Invoice Number
4.1.36 Item Amount
4.1.37 Item Description
4.1.38 Item Quantity
4.1.39 Item Rate
4.1.40 Last Name
4.1.41 Last Name
4.1.42 Loss Type Description
4.1.43 Max $ Covered
4.1.44 Note
4.1.45 Record Add Date
4.1.46 Related Office Identifier
4.1.47 Request Type
4.1.48 Standard Message Description
4.1.49 Start Date
4.1.50 State
4.1.51 Status Code
4.1.52 Telephone Number
4.1.53 Ticket Number
4.1.54 Total Amount Due
4.1.55 Total Amount Received
4.1.56 Total Billed to Others
4.1.57 Total Ticket Charges
4.1.58 Zip Code
5. Questions and Answers
None.
The Reject an Invoice use case describes how the ADJUSTER would reject an invoice to Enterprise in the ARMS Web system.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include the necessary steps for an ADJUSTER to reject invoices.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Cancel Rejection
1.4.3.2 No Reject Reason Given
1.4.3.3 Short Pay
The additional requirements of the business use case are included here. These are requirements not covered by the flow as they have been described in the sections above.
1.6.1 Invoices are Initially Auto Approved
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Reject Billing Reason
This screen will allow the user to begin the rejection process.
2.1.1 Screen Layout—Reject Billing Reason—see
2.1.2 Reject Billing—Reject Billing Reason
2.1.3 Screen Function Definition
2.1.3.1 Continue
2.1.3.2 Cancel
2.2.1 Screen Layout—Reject Billing Amount—see
2.2.2 Reject Billing—Reject Billing Amount
2.2.3 Screen Function Definition
2.2.3.1 Reject Invoice
2.2.3.2 Cancel
This section will detail all the application operations that are part of this Functional Specification Document.
3.1 Get Invoice Rejection Reasons (Company Id)
The get invoice rejection reasons gets the predefined rejection reasons for the company.
3.2 Reject Invoice (Invoice Number)
The reject invoice operation marks the specified invoice as rejected. The rejected invoice becomes an action item for the adjuster to handle.
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Accounting Name
4.1.2 Address Line
4.1.3 Address Line2
4.1.4 City
4.1.5 External Organization Abbreviated Name
4.1.6 First Name
4.1.7 First Name
4.1.8 Insurance Claim Number
4.1.9 Last Name
4.1.10 Last Name
4.1.11 Standard Message Description
4.1.12 State
4.1.13 Telephone Number
4.1.14 Total Amount Due
4.1.15 Zip Code
1. Callbacks
1.1 Brief Description
This use case describes the process that will perform repair facility callbacks in the ARMS Web system. USERs perform repair facility callbacks on each of the rental contracts that are set to expire in the near future (or have already expired), to proactively determine if rentals must be extended due to slippage in repair facility time estimates. The callback process in the ARMS Web system will retrieve each of the rental contracts that will expire in the user-defined period of time, and organize them by repair facility to allow the USER to make one phone call to inquire about the potentially multiple vehicles that the repair facility is responsible for.
1.2 Use Case Actors
All actors will use the use case to retrieve callback lists in the ARMS Web system. All of the following actors can be defined generically as a USER:
For the balance of this use case, all of the above actors will be referred to as USER.
1.3 Pre-Conditions
The Flow of Events includes all the steps necessary to retrieve and manage callbacks in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Change Last Authorized Date
1.4.3.2 Last Authorized Date Entered Invalid
None.
1.7 Extension Points
1.7.1 MA-12 Extend Authorization
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Repair Facility Callback Summary
This screen provides the USER with a repair facility callback summary, and supports Step 3 of the Basic Flow.
2.1.1 Screen Layout—see
1. Generate Personal Report
1.1 Brief Description
This use case describes how a USER would generate a report on their personal rental management activity. Personal reports allow the USER access to reporting on only their own rental management activity, which allows the USER to review their own performance and secures access to the rental management reports of others.
1.2 Use Case Actors
All actors will use the use case to generate personal reports in the ARMS Web system. All of the following actors can be defined generically as a USER:
The Flow of Events includes all the steps necessary to generate personal reports in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.3 Alternative Flows
1.4.3.1 Change Report View
1.4.3.2 Change Closed Ticket Date Range
1.4.3.3 Select Open Ticket from Open Ticket Detail Report
1.4.3.4 Select Closed Ticket from Closed Ticket Detail Report
1.4.3.5 Sort Report
1.4.3.6 Add/Edit Custom View
1.4.3.7 Select Download Report
At Step 3 of the Basic Flow, the USER will have the ability to download the current report view to a comma-delimited file. If the USER selects to download a comma-delimited version of the report, the system must publish a comma-delimited file that includes all of the data within the columns of the current report view. The comma-delimited file should include column headings for each of the columns of data provided to the USER. The comma-delimited file must also include report header information that includes:
The system should return the USER to the report view (Step 3 of the Basic Flow) once a report has been successfully downloaded.
1.5 Post-Conditions
The special requirements for this use case define all of the personal report ‘views’ that are available to the USER. This list of personal report views may be expanded at a later date to include additional information from the ARMS/400 reporting detail files, but only these views are anticipated for the initial release.
1.6.1 Open Ticket Detail View
The Open Ticket Detail View provides the USER with columns of data on all currently open tickets under their management. The Open Ticket Detail report will display the following information to the user:
Specific rules that must apply to the Open Ticket Detail report view are outlined in the sections below;
1.6.1.1 Data Columns in the Open Ticket Detail View should be presented in the order defined above. For example, renter name belongs in column 1 of the Open Ticket Detail report.
1.6.1.2 All numeric fields should have averages provided at the foot of each corresponding column. Numeric fields are indicated with an asterisk (*) in the list above.
1.6.1.3 The default sort for the Open Ticket Detail view must be by the Number of Days Behind field, with open tickets that are the farthest behind presented at the top of the list.
1.6.1.4 Any open tickets that have a value greater than zero (0) in the Number of Days Behind field should be highlighted to the USER.
1.6.1.5 The report must include a count of the total number of contracts in the list.
1.6.1.6 The report view must include report header information (in both screen and downloaded versions) that includes:
1.6.2 Closed Ticket Detail View
The Closed Ticket Detail View provides the USER with columns of data on closed ticket activity for the currently selected date range (the default date range is the current plus previous two (2) months). The Closed Ticket Detail report will display the following information to the user:
Specific rules that must apply to the Closed Ticket Detail report view are outlined in the sections below;
1.6.2.1 Data Columns in the Closed Ticket Detail View should be presented in the order defined above. For example, renter name belongs in column 1 of the Closed Ticket Detail report.
1.6.2.2 All numeric fields should have averages provided at the foot of each corresponding column. Numeric fields are indicated with an asterisk (*) in the list above.
1.6.2.3 The default sort for the Closed Ticket Detail view must be by the Claim Number field.
1.6.2.4 The report must include a count of the total number of contracts in the list.
1.6.2.5 The report view must include report header information (in both screen and downloaded versions) that includes:
1.6.3 Custom Report Views
The USER will have the ability to define their own custom report views through the RP-03 Add/Edit Custom View use case. These custom views are accessible from the Personal Reporting module of ARMS Web.
1.6.4 Report View Management
The system will present all of the records in a report result set on a single page, and the USER will scroll through the results to find specific records. Report views will not be presented in paging format (e.g., forcing the USER to review the Next 25 of 427 records).
1.7 Extension Points
This section describes the extension points of this use case.
1.7.1 MA-13 Change Authorization
If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report Alternative Flow on page 3 for additional detail). The USER will have the ability to make any changes or updates that their security level allows, and have the opportunity to return to this use case without making any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, the USER will be returned to Step 3 of the Basic Flow within this use case (be presented with the Open Ticket Detail report).
1.7.2 RP-03 Add/Edit Custom View
If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom View use case (see the Add/Edit Custom View Alternative Flow on page 4 for additional detail). The USER will define or modify their custom report layout and be returned to Step 2 of the Basic Flow within this use case.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Personal Report Template Screen
This screen provides the template to build personal report ‘views’, and supports Step 3 of the Basic Flow.
2.1.1 Screen Layout—see
2.1.2 Screen Field Definition
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Choose a Different Report
The ‘Choose a different report’ screen function provides the USER with a hyperlink to the View a Different Report section of the Personal Report Template screen. The ‘Choose a different report’ screen function must be at or near the header of the report.
2.1.3.2 Go to Report Averages
The ‘Go to Report Averages’ screen function provides the USER with a hyperlink to the bottom of the report to review the averages for each of the numeric columns in the report view. The ‘Go to Report Averages’ hyperlink must be at or near the header of the report.
2.1.3.3 Column Heading Sort
The ‘Column Heading Sort’ screen function allows the USER to click on any column heading and have the current report view sorted by the selected column. On initial selection of a column heading, the system will resort the report view by the column selected in ascending order. If the sorted column is selected by the USER, the system will resort the report in descending order.
2.1.3.4 Download this Report
The ‘Download this Report’ screen function allows the USER to click on a hyperlink and download a comma-delimited copy of the current report view. The downloaded copy must include:
2.1.3.5 View Report
The ‘View Report’ screen function allows the USER to submit a request for a different type and/or date range of the report view. The system will refresh the screen with updated report view information when this screen function is invoked.
2.1.3.6 Edit Custom View
The Edit Custom View screen function is available only in cases that the USER has a custom defined view active. If the USER selects the Edit Custom View hyperlink, the system will present the USER with the Add/Edit Custom View screen and pre-populate the screen with the custom view definition. This will allow the USER to edit the custom views that they have previously defined.
See
Functional Design Specification
Generate Management Report
Version 1.11
1. Generate Management Report
1.1 Brief Description
This use case describes how a USER would request and generate management reports using the on-line reporting functionality of ARMS Web. On-line management reports provide real-time access to open and closed ticket information, which provides the management team of our customers with a tool to effectively monitor rental management statistics. Using the on-line reporting functionality, USERs can request and receive summarized and detailed rental management reports on their Office, on Adjusters within an office, or on the Repair Facilities that are trading partners of a particular office.
NOTE: The on-line reporting functionality of ARMS Web provides ARMS ticket data only. ARMS and Non-ARMS reporting is available through the monthly L480 report.
1.2 Use Case Actors
All actors will use the use case to generate management reports in the ARMS Web system. All of the following actors can be defined generically as a USER:
For the balance of this use case, all of the above actors will be referred to as USER.
1.3 Pre-Conditions
The Flow of Events includes all the steps necessary to generate management reports in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
The Basic Flow of the Generate Management Report use case includes all of the required activities for the USER to successfully generate and view a management report using the on-line reporting functionality in ARMS Web.
1.4.3 Alternative Flows
The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided.
1.4.3.1 Change Report View
At Step 6 of the Basic Flow, the USER will have the ability to change the report ‘view’. (Report views are covered in more detail in Section 1.6 Special Requirements.) Report ‘views’ change the type of information that is presented to the USER, but maintains the same or similar scope.
If the USER selects to change the report view, the system will return to Step 5 of the Basic Flow and re-generate the report to build the requested view. NOTE: The USER may also change the Report By criteria to request a new report view (e.g., request a report by Adjuster, Office, or Repair Facility).
1.4.3.2 Change Closed Ticket Date Range
At Step 6 of the Basic Flow, if the current report view is a closed ticket report, the USER will have the ability to change the date range of the report. The available date range for closed ticket reporting will be a rolling 13-month period (to be expanded to 24-months in future releases) with the current month inclusive. The default date range that will be presented to the USER will be the current and previous two (2) months. The USER will have the ability to select Month/Year to begin and end the date range for the closed ticket report. The USER will not have the ability to select specific days within a month as part of the date range.
If the USER selects a new date range for the closed ticket report view, the system will return to Step 5 of the Basic Flow and re-generate the report to build the USERs closed ticket report for the selected date range.
This applies to both summary and detail views of closed ticket reports.
1.4.3.3 Select Summary Line Item from Open Ticket Summary Report
At Step 6 of the Basic Flow, if the current report view is an open ticket summary report, the USER will have the ability to select a report line item, which will trigger a request for a more detailed report for the selected item. For example, if the current view were an Open Ticket Summary for Adjusters within an office (Open Summary by Adjuster), the USER would have the ability to select an adjuster from the summarized report and review the Open Ticket Detail report for that adjuster. This ‘drill-down’ capability must be available for all report types (by Office, by Adjuster, by Repair Facility).
If the USER selects a line item from a summary report view, the system will return to Step 5 of the Basic Flow and generate the Open Ticket Detail report view for the selected item. From the Open Ticket Detail, the USER will have the ability to return to the Open Ticket Summary or to continue reviewing the Open Ticket Detail report views for each adjuster/repair facility within the office.
1.4.3.4 Select Open Ticket from Open Ticket Detail Report
At Step 6 of the Basic Flow, if the current report view is an open ticket detail report, the USER will have the ability to select a report line item to view the details of the open ticket customer file. When selected, the system will present the USER with the customer file that corresponds to the selected open ticket. The USER will be allowed to modify and submit changes to the customer file (as proscribed in use case MA-13 Change Authorization). Once activity on the customer file is complete, the USER should be returned to the open ticket detail report (Step 6 of the Basic Flow).
1.4.3.5 Select Summary Line Item from Closed Ticket Summary Report
At Step 6 of the Basic Flow, if the current report view is a closed ticket summary report, the USER will have the ability to select a report line item, which will trigger a request for a more detailed report for the selected item. For example, if the current view were a Closed Ticket Summary for Repair Facilities within an office (Closed Summary by Repair Facility), the USER would have the ability to select a repair facility name from the summarized report and review the Closed Ticket Detail report for that repair facility. This ‘drill-down’ capability must be available for all report types (by Office, by Adjuster, by Repair Facility).
If the USER selects a line item from a summary report view, the system will return to Step 5 of the Basic Flow and generate the Closed Ticket Detail report view for the selected item. From the Closed Ticket Detail, the USER will have the ability to return to the Closed Ticket Summary or to continue reviewing the Closed Ticket Detail report views for each adjuster/repair facility within the office.
1.4.3.6 Select Closed Ticket from Closed Ticket Detail Report
At Step 6 of the Basic Flow, if the current report view is a closed ticket detail report, the USER will have the ability to select a report line item to view the details of the closed ticket customer file. When selected, the system will present the USER with the closed customer file that corresponds to the selected closed ticket. The USER will be allowed to view/print the details of the closed ticket, but will not have the ability to modify or change the ticket information. From the closed customer file, the USER will be returned to the closed ticket detail report (Step 6 of the Basic Flow).
1.4.3.7 Sort Report
At Step 6 of the Basic Flow, the USER will have the ability to select any report column heading to have the report sorted by the selected column. If the USER selects a column heading, the system must sort the report by the selected column heading in ascending order. The USER will have the ability to toggle between ascending and descending sort order by re-selecting the currently sorted column. For example, if the USER wanted their report view to be sorted by Renter Name, clicking on the column would cause the report view to be sorted ascending by renter last name. If the USER would like to reverse the sort order to descending, selecting the column heading again would allow the report to be resorted descending by renter last name.
The system will return the USER to Step 6 of the Basic Flow on completion of this Alternative Flow, with the report view resorted according to the USER request.
1.4.3.8 Add/Edit Custom View
At Step 6 of the Basic Flow, the USER will have the ability to add or edit a custom report view. If the USER selects to add a report view, the system will extend to the RP-03 Add/Edit Custom View use case to define a new custom report layout.
If the USER is viewing a custom report, they will have the ability to edit the custom view by selecting an ‘edit’ option. When a user requests to edit a custom report layout, the system will extend to the RP-03 Add/Edit Custom View use case and pre-fill all corresponding fields with the currently selected parameters for the custom layout.
On completion of the use case extension, the USER will be returned to Step 5 of Basic Flow in this use case and be presented with the custom report layout that was defined/modified.
1.4.3.9 Select Download Report
At Step 6 of the Basic Flow, the USER will have the ability to download the current report view to a comma-delimited file. If the USER selects to download a comma-delimited version of the report, the system must publish a comma-delimited file that includes all of the data within the columns of the current report view. The comma-delimited file should include column headings for each of the columns of data provided to the USER. The comma-delimited file must also include report header information that includes:
The system should return the USER to the report view (Step 6 of the Basic Flow) once a report has been successfully downloaded.
1.5 Post-Conditions
The special requirements for this use case define all of the management report ‘views’ that are available to the USER. Management reports will be provided two USERs in two ways:
1.6.1 Standard Management Reporting Views
Standard management reporting views are views that have been defined by Enterprise based on the requests of customers. These views will be carried forward in to ARMS Web and are defined in this section.
The table below (see
1.6.1.1 All numeric fields should have averages provided at the foot of each corresponding column. Numeric fields are indicated with an asterisk (*) in the list above.
1.6.1.2 The default sort for the Open Ticket Detail views must be by the Number of Days Behind field, with open tickets that are the farthest behind presented at the top of the list.
1.6.1.3 The default sort for the Closed Ticket Detail views must be by Claim Number.
1.6.1.4 The default sort for the Open Ticket Summary views must be by Adjuster Name (if by Adjuster), Repair Facility Name (if by Repair Facility), or Office Name (if by Office)
1.6.1.5 The default sort for the Closed Ticket Summary views must be by Adjuster Name (if by Adjuster), Repair Facility Name (if by Repair Facility), or Month/Year (if by Office)
1.6.1.6 Any items in an Open Ticket Detail view that have a value greater than zero (0) in the Number of Days Behind field should be highlighted to the USER.
1.6.1.7 All report views must include a count of the total number of contracts listed.
1.6.1.8 The report view must include report header information (in both screen and downloaded versions) that includes:
1.6.2 Custom Management Reporting Views
Custom management reporting views allow the USER to define the fields that they would like to use to build their own report. The fields selected by the USER become the columns of the report, and the system will not limit the number of columns that a USER can request as part of the report. Custom reporting views are discussed at length in use case RP-03 Add/Edit Custom View.
1.6.3 Report View Management
The system will present all of the records in a report result set on a single page, and the USER will scroll through the results to find specific records. Report views will not be presented in paging format (e.g., forcing the USER to review the Next 25 of 427 records).
1.7 Extension Points
This section describes the extension points of this use case.
1.7.1 MA-13 Change Authorization
If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report Alternative Flow on page 4 for additional detail). The USER will have the ability to make any changes or updates that their security level allows, and have the opportunity to return to this use case without making any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, the USER will be returned to Step 6 of the Basic Flow within this use case.
1.7.2 RP-03 Add/Edit Custom View
If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom View use case (see the Add/Edit Custom View Alternative Flow on page 5 for additional detail). The USER will define or modify their custom report layout and be returned to Step 6 of the Basic Flow within this use case.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Management Report View Template
This screen provides the USER with a management report view template, and supports Step 6 of the Basic Flow.
2.1.1 Screen Layout—see
2.1.2 Screen Field Definition
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Choose a Different Report
The ‘Choose a different report’ screen function provides the USER with a hyperlink to the View a Different Report section of the Personal Report Template screen. The ‘Choose a different report’ screen function must be at or near the header of the report.
2.1.3.2 Go to Report Averages
The ‘Go to Report Averages’ screen function provides the USER with a hyperlink to the bottom of the report to review the averages for each of the numeric columns in the report view. The ‘Go to Report Averages’ hyperlink must be at or near the header of the report.
2.1.3.3 Column Heading Sort
The ‘Column Heading Sort’ screen function allows the USER to click on any column heading and have the current report view sorted by the selected column. On initial selection of a column heading, the system will resort the report view by the column selected in ascending order. If the sorted column is selected by the USER, the system will resort the report in descending order.
2.1.3.4 Previous <Report By>
The ‘Previous <Report By>’ screen function allows the USER to navigate to the previous detail record in a particular detail report. For example, if the report view were an Open Ticket Detail report by Repair Facility, the ‘Previous <Report By>’ screen function would allow the USER to move to the previous Repair Facility detail record in a report. This screen function should only be available on open or closed ticket detail views (including custom views), and should only be available if a previous report by item exists (i.e., we wouldn't have a previous item if we were on the first item in the list).
2.1.3.5 Next <Report By>
The ‘Next <Report By>’ screen function allows the USER to navigate to the next detail record in a particular detail report. For example, if the report view were an Open Ticket Detail report by Adjuster, the ‘Next <Report By> screen function would allow the USER to move forward to the next Adjuster's detail report view within the office. This screen function should only be available on open or closed ticket detail views (including custom views), and should only be available if a next report by item exists (i.e., we wouldn't have a next item if we were on the last item in the list).
2.1.3.6 Download this Report
The ‘Download this Report’ screen function allows the USER to click on a hyperlink and download a comma-delimited copy of the current report view. The downloaded copy must include:
2.1.3.7 View Report
The ‘View Report’ screen function allows the USER to submit a request for a different type and/or date range of the report view. The system will refresh the screen with updated report view information when this screen function is invoked.
2.1.3.8 Edit Custom View
The Edit Custom View screen function is available only in cases that the USER has a custom defined view active. If the USER selects the Edit Custom View hyperlink, the system will present the USER with the Add/Edit Custom View screen and pre-populate the screen with the custom view definition. This will allow the USER to edit the custom views that they have previously defined.
Functional Design Specification
Add/Edit Custom View
Version 1.1
1. Generate Management Report
1.1 Brief Description
The Add/Edit Custom View use case describes the process to add or edit a custom report view in the ARMS Web system. Custom views allow the USER to select the data columns that they would like to view in a report (from a pre-defined list of available fields). USERs will have the ability to access their custom views just as they would any other ‘standard’ report view.
1.2 Use Case Actors
All actors will use the use case to add or edit a custom report view(s) in the ARMS Web system. All of the following actors can be defined generically as a USER:
The Flow of Events includes all the steps necessary to add or edit a custom report view in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
The Basic Flow of the Add/Edit Custom View use case includes all of the required activities for the USER to successfully add or edit a custom report view for use in the on-line reporting functionality of ARMS Web.
1.4.3 Alternative Flows
The Alternative Flows of this use case can occur when certain conditions exist or when specific USER feedback is provided.
1.4.3.1 Edit Custom Report View
At Step 1 of the Basic Flow, if the USER selected to edit a current custom report view, the system will present the screen to define/build a custom report and pre-fill all fields with the current report definition. For example, if the USER were editing their ‘Massive’ custom report view, ‘Massive’ would appear in the report name field and all of the data columns that were previously defined as the massive report would appear in the ‘selected columns’ portion of the screen.
1.5 Post-Conditions
The special requirements for this use case define all of the management report ‘views’ that are available to the USER. Management reports will be provided two USERs in two ways:
1.6.1 Custom Report Definition
This section provides the system framework for custom report view definition in the ARMS Web system. These are additional requirements around functionality to allow USERs to define/build custom report views, and apply to the use case as a whole.
1.6.1.1 USERs will have the ability to create one or more custom views.
1.6.1.2 USERs will be able to define custom report views for DETAIL views only
(USERs will not have the ability to define custom summary views). (Most of the numeric fields that can be summarized for USERs are already provided in the standard management report views.)
1.6.1.3 USERs will have the ability to select custom report views by Office, by Adjuster, or by Repair Facility (similar to the standard management reports).
1.6.1.4 Custom report views will be limited to the data columns in the Custom Report View Data Domain (see 1.6.2 Custom Report View Data Domain)
1.6.1.5 Custom report views must define if the report view retrieves Open, Closed, or All Ticket statuses.
1.6.1.6 All custom report views defined as ‘closed ticket only’ must allow the user to indicate a date range. The default date range for custom views will be the same as the default range for standard closed ticket reports (the current month plus two (2) prior months).
1.6.1.7 When a custom report view has been defined, the name of the custom report view will become a selection from the USERs view list. For example, ‘MyCustomView’ would be seen in the list with ‘Open Ticket Detail’, ‘Closed Ticket Detail’, etc.
1.6.2 Custom Report View Data Domain
The following is a list of all available data columns that a USER may select as part of a custom report view. The number of columns that a USER selects to make part of the custom report view is not limited, which allows the USER to select a subset or all of these data fields to be published in their report.
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Add/Edit Custom View
This screen provides the USER with the ability to add or edit a custom view, and supports Step 2 of the Basic Flow.
2.1.1 Screen Layout—see
2.1.2 Screen Field Definition
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Remove
The ‘Remove’ screen function allows a USER to remove selected fields from the New Report Fields' list box (and re-add them to the ‘Available Fields’ list box).
2.1.3.2 Insert
The ‘Insert’ screen function allows a USER to add selected fields to the ‘New Report Fields’ list box (and remove them from the ‘Available Fields’ list box).
2.1.3.3 Dictionary
The ‘Dictionary’ screen function allows a USER to open a dictionary that defines all of the fields that can be added to a report view. The dictionary will be included as part of the help functionality of the system.
2.1.3.4 Sequence Up
The ‘Sequence Up’ screen function (presented with an ‘up’ arrow in the screen shot) allows a USER to move a selected field in the ‘New Report Fields’ list box up in the sequence of the report.
2.1.3.5 Sequence Down
The ‘Sequence Down’ screen function (presented with a ‘down’ arrow in the screen shot) allows a USER to move a selected field in the ‘New Report Fields’ list box down in the sequence of the report.
2.1.3.6 Save Report View
The ‘Save Report View’ screen function allows the USER to save the custom report definition and return to the reporting use case(s). The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02) and be presented with the newly defined report view.
2.1.3.7 Close without Saving
The ‘Close without Saving’ screen function allows the USER to exist the screen with saving any changes made. The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02).
2.1.3.8 Delete
The ‘Delete’ screen function allows the USER to delete a custom report view from their profile. When a custom report view is deleted it should no longer be available in the USERs view selection combo box. The system will return the USER to the report use case from which they entered this use case (either RP-01 or RP-02).
Functional Design Specification
Maintain User
Version 1.3
1. Maintain User Use Case
1.1 Brief Description
The Maintain User use case describes how a USER would set up or maintain a user in the ARMS Web system.
1.2 Use Case Actors
The following actors will interact with this use case:
The Flow of Events will include all the steps necessary to add or maintain a company user in the ARMS Web system.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
The Basic Flow will describe how a USER will maintain a user in the ARMS Web system.
1.4.3 Alternative Flows
1.4.3.1 Add User
At step three in the Basic Flow, the USER may choose to add a user, if they have the authority level to do so. The USER will enter a primary office, UserID, First Name and Last Name for the new user. The system will then validate that the office was entered and the UserID does not exist. If a UserID match is found, or the office was not entered, the system will display an error and request the USER enter a new UserID. Otherwise, the system will display the default settings for a new user; the USER will update the default settings and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.
1.4.3.2 Show all Users for the Company
At step three in the Basic Flow, the USER may choose to display all users within the company. This would allow for adding users to offices the USER controls. The USER will choose the user they wish to work with and the system will then display the user's information; the USER will add the user to any offices the USER controls and submit the information to the system. The system will validate the information entered, and update the ARMS Web database. The use case is then complete.
1.4.3.2.1 If a user's primary office is not an office controlled by the USER, the USER may only add the user to offices the USER controls. The USER should not be able to change any of the user's settings. A USER that has control of a user's primary office can only change user settings.
1.4.3.3 User Information Validation Fails
In step six of the Basic Flow, the system may find that user information entered by the USER does not meet the validation criteria. The system should return the USER to step four of the Basic Flow, show the USER the invalid data, and prompt the USER to reenter the data.
This rule also applies for new user creation. Whenever a new user is submitted to the system for creation, the system must validate that the criteria entered is valid. If any information is invalid, the system should present the invalid date to the USER, and prompt the user to correct it.
1.4.3.3.1 The following fields must be populated to complete a user update or new user creation.
1.4.3.4 Cancel Add/Maintain User
Until step five in the Basic Flow, the USER may choose to cancel the use case. The system should not store any changes made by the USER within the use case.
1.5 Post-Conditions
1.6.1 User Inactivation
In order to inactivate a user, the following set of criteria must be validated. If any of the criteria are found to be true, then the system will not allow the USER to inactivate the user.
1.6.2 User Default Settings
Whenever a new user is created, the settings for that user should be defaulted based on the user's primary office profile settings. For example, if the office is a reservation only office, the user should default to reservation only. This does not imply that the administrator cannot change the settings. This should also apply to whether can receive work setting should be on or off for the user/team. If all other users/teams in the office have the setting either on or off, then the new user should mimic this setting. Once again, this does not imply that the administrator cannot change this setting.
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 Create or Modify User
This screen will allow the USER to search for and select a user to modify or select to add a new user.
2.1.1 Screen Layout—see
2.1.2 Create or Modify User
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 A-Z Anchor Links
When any of the letters are clicked, the list of users should position itself with that letter presented at the top of the user view area on the page.
2.3.3.2 Teams Link
When the team link is clicked, the list of teams should position itself at the top of the view area on the page. The list of teams should be placed last in the list of all users/teams.
2.1.3.3 Process
When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new user (Office, Last Name, First Name UserID). If the information is entered, the system will create a new user with those attributes and the other user attributes defaulted. The system should then display the new user's profile.
2.2 Create or Modify Team
This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)
2.2.1 Screen Layout—see
2.2.2 Create or Modify Team
2.2.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.2.3.1 A-Z Anchor Links
When any of the letters are clicked, the list of users should position itself with that letter presented at the top of the user view area on the page.
2.2.3.2 Teams Link
When the team link is clicked, the list of teams should position itself at the top of the view area on the page. The list of teams should be placed last in the list of all users/teams.
2.2.3.3 Process
When the Process button is clicked, the system should check to see that the appropriate information was entered in order to create a new team (Office, Team Name). If the information is entered, the system will create a new team with those attributes and the other user attributes defaulted. The system should then display the new team's profile.
2.3 User Profile
This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)
2.3.1 Screen Layout—see
2.3.2 User Profile
2.3.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.3.3.1 Process
When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User/Team page.
2.3.3.1.1 The user must have a First Name, Last Name and Home Office entered. The Home Office must be a valid office for that company.
2.3.3.1.2 Work Authority for each user will default to all enabled.
2.3.3.1.3 If the Active switch has been set to inactive, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the user to be set to inactive. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to inactivate the user.
2.3.3.1.4 If the reset password option is set, the system will reset the user's password. This will reset the user's password to the password used for new users. Need to verify what that password is.
2.3.3.1.5 If the File Ownership flag is turned off, the system will check to see if the user owns any open work. If the user owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the user has open work assigned to them and request that they transfer the work before attempting to turn off file ownership.
2.4 Team Profile
This screen will allow the USER to input and change information about a user (i.e. name, E-mail address, etc.)
2.4.1 Screen Layout—see
2.4.2 Create or Modify Team
2.4.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.4.3.1 Process
When clicked, the system will ensure that all rules on the page are enforced. Upon completion, the system will return the USER to the Create a New User/Team page.
2.4.3.1.1 The team must have a Team Name and Home Office entered. The Home Office must be a valid office for that company.
2.4.3.1.2 If the Active switch has been set to inactive, the system will check to see if the team owns any open work. If the team owns work, the system will not allow the team to be set to inactive. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to inactivate the team.
2.4.3.1.3 If the File Ownership flag is turned off, the system will check to see if the team owns any open work. If the team owns work, the system will not allow the file ownership flag to be turned off. The system will notify the USER that the team has open work assigned to them and request that they transfer the work before attempting to turn off file ownership. If the user or team does not receive File Ownership, that user or team will not display in the Handle For list.
3. Application Operations
This section will detail all the application operations that are part of this Functional Specification Document.
3.1 Build List of Users
(Office Id, First Name, Last Name, User Id)
Build a list of User first and last names NOT limited to a given office in order to search for a user. Limited by the first or last name passed.
3.2 Find User Information
(User Id)
Retrieve the current values for a user's profile.
3.3 Update User Information
(User Id, Name, e-mail Address, Out of Office, Handler for out of office user, Initial Page, Is user Multi-company, Is User Active, Current Password, New Password, Receive Authorization Assignment)
Update the given data values for the user profile.
3.4 Build List of User offices
(User Id)
Build a list of office names for the offices the user is assigned to.
3.5 Find User Office Information
(User Id, Office Id)
Retrieve the current values assigned for the user at a given office.
3.6 Update User Office Information
(User Id, Office Id, and Data Values)
Update the given data values for the user profile.
3.7 Add User Office Information
(User Id, Office Id)
Assign user access to another office. Default values are set for the users access.
3.8 Remove User Office Information
(User Id, Office Id)
Revoke assignment of the user to an office. The user cannot be revoked from their primary office.
3.9 Build a List of Users to which the Administrator has Access
(Company Id, Administrator Id, User Id)
Build a list of User first and last names limited to a given office in order to maintain a user. Limited by the first or last name passed.
3.10 Validate that User ID does not Exist
(User ID)
Verify that the administrator must add a new user.
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 User Language Preference
This is the user's language preference while working with the ARMS Web System.
Data Field Type: Alpha-Numeric
Data Field Length: 10
Data Source: <Data Source>
4.1.2 Phone Number
This is the user's phone number.
Data Field Type: Alpha-Numeric
Data Field Length: 10
Data Source: <Data Source>
4.1.3 Profile Attribute Id
I.S. assigned identifier for a profile attribute. Must be unique and non-blank. Each profilable item will have a profile attribute.
Data Field Type: Alpha-Numeric
Data Field Length: 20
Data Source: <Data Source>
4.1.4 Last Name
This is the last name of the user.
Data Field Type: Alpha-Numeric
Data Field Length: 20
Data Source: <Data Source>
4.1.5 Handler for Out of Office User
This is the user who will handle work for the user who is out of office.
Data Field Type: Alpha-Numeric
Data Field Length: 0
Data Source: <Data Source>
4.1.6 Start Page
This is the initial page that the user will see when he logs on to the system.
Data Field Type: URL
Data Field Length: 256
Data Source: <Data Source>
4.1.7 Is User Out of Office?
This flag indicates that the user is out of office and no work should be assigned to them. Instead another user can be set up to handle for the user who is out of office.
Data Field Type: Boolean
Data Field Length: 1
Data Source: <Data Source>
4.1.8 Is the User Multicompany?
This flag indicates that this user can do work for multiple insurance companies. These are typically Enterprise Rent-A-Car employees working on site at an insurance company office or Rental Management Services employees who are also Enterprise employees who manage rentals for the insurance company but are not on site.
Data Field Type: Boolean
Data Field Length: 1
Data Source: <Data Source>
4.1.9 Can User Receive Work?
This flag indicates that user can receive work (e.g. requests for authorization, requests for extension etc.). Typically, a manager would set this flag to “No” so that work would not be assigned to him or her although he or she could be notified in certain situations like authority limit exceeded etc.
Data Field Type: Boolean
Data Field Length: 1
Data Source: <Data Source>
4.1.10 Is User Active?
This flag indicates the user is currently active and may log on to the system to do work.
Data Field Type: Boolean
Data Field Length: 1
Data Source: <Data Source>
4.1.11 Email Address
This is the email address of the user.
Data Field Type: Alpha-Numeric
Data Field Length: 30
Data Source: <Data Source>
4.1.12 First Name
This is the first name of the user.
Data Field Type: Alpha-Numeric
Data Field Length: 15
Data Source: <Data Source>
4.1.13 Password
This is the user specified password that the user will use along with the user id to log on to the ARMS Web System.
Data Field Type: Password
Data Field Length: 10
Data Source: <Data Source>
4.1.14 User Id
This is the user id that the user will use to sign on to the ARMS Web System. This id must be unique across the whole system.
Data Field Type: Alpha-Numeric
Data Field Length: 10
Data Source: <Data Source>
5. Questions and Answers
Issue Number: 321
Question: When do we “Kill” profiles that have been created but not used? Question 2—Do we allow for deleting users, and if so, who would handle this function? Question 3—Do we allow for deleting inactive user, and if so, who would handle this function?
Status: Closed—Resolved
Resolution: 3-21-00, Dave Smith—The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out?
8-07-00—Brad Reel: UserIDs that were created, but never accessed will be made inactive after six months. UserIDs that have not been accessed for two years will also be made inactive. After being made inactive, they will be purged after three additional months.
Issue Number: 322
Question: Do we allow for deleting users, and if so who would it be that does so?
Status: Closed—Merged
Resolution: 3-21-00, Dave Smith—The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 3-27-00, merged with Issue 321
Issue Number: 323
Question: When do we delete an inactive user? And who would handle?
Status: Closed—Merged
Resolution: 3-21-00, Dave Smith—The other questions would seem to have procedures in place today. Unless there is a compelling reason, I don't think we should reinvent the wheel. Could you check with the ARMS team to find out? 3-27-00, merged with issue 321
Issue Number: 324
Question: User ID: Do we have current Enterprise Business rules that we need to enforce, and if so, what are they? The assumption we made when discussing this was that the admin could give them whatever ID the user desired. If user wanted the ID Beavis, the admin could create it. The question is, are there some rules we want to enforce (i.e. User ID's start w/first three characters of insurance company's name, GEI for GEICO) and some defaults for both UserID & Password? Maybe for GEICO, the first user is GEI0001 and the default password is GEICO. Just something we need to address.
Status: Closed—Resolved
Resolution: 3-22-00, Dave Smith—I think we should give them whatever user ID they want.
3-30-00. Kim DeVallance—user ID is a company specific item. For example, GEICO's is their associate ID (similar to our employee number). Progressive uses their PACMAN ID, Nationwide uses their RACF ID . . . all a similar concept. It is an ID that the adjuster is familiar with and I think we should allow the customer to use an employee number already familiar to the adjuster.
4-7-00, Issue Mtg, the field is 10 characters, First three will be company driven, the next 7 can be alpha/num and the users choice.
4-11-00, Brad Reel—Current State, ID's are first three characters of the company's name, and up to seven numeric characters. Could possibly expand to seven alpha-numeric instead of just numeric. Barring any disagreement, we will suggest the following in the ARMS Web system: first three characters of the company's name are the first three characters of the ID. Then the ID must include at least 4 alpha-numeric characters with at least one number in it. The minimum ID length would be 7 characters, the maximum 10. Suggest we try to force companies to use their employee IDs as the seven digits. ARMS Web system can generate a number if necessary.
Need to confirm with our security people that this is acceptable security on an Enterprise-owned application. Also, should consider whether or not we think first three characters of a company's name will allow us to always uniquely identify companies.
Issue Number: 325
Question: Current State we capture the primary address for the user, (the address the user (adjuster) is located at) do we want to do the same in future state? In the screen prototype should the primary user (adjuster) address be capture in the user profile screens, given that we currently have an office address in the office profile?
Status: Closed—Resolved
Resolution: 3-30-00, Kim DeVallance—Kim—I do not think it is necessary for the ARMS/Web application, but it may be a mandatory field for the ARMS system when it processes info. I would recommend checking with the analysts from ARMS. We pull the address from ECARS when we send a paper bill, and if the bill is electronic, the address does not matter.
4-7-00, Issue Mtg, Default to office address, allow at the user level to be changed, if it is changed it will only update the database not the 400.
4-11-00, Brad Reel—When creating a user, we need to capture a user-specific address. It should default to the primary office they are assigned to when they are first created, but be changeable. This means we have to change the process for adding a user so we identify their primary office before we enter address information.
Issue Number: 326
Question: Can a user be maintained at more than one office? Do we still have a default/primary office when the user is created?
Example: You have been created at the St. Louis Office and you need to travel to California to help with a disaster, does California have the rights to maintain you.
Status: Closed—Resolved
Resolution: 3-22-00, Dave Smith—For tracking purposes, I think we need to maintain one profile only. If someone moves to another location because of a disaster, we should move the profile to that office. Perhaps to make it easy on the transition, we could transfer their base profile and let the new office modify accordingly.
3-27-00, Ask Brad to follow-up with Dave Smith.
3-30-00, Kim DeVallance—Current state, yes a user can be maintained at more than one office, but a user should have a primary office.
Issue Number: 327
Question: Do we need a primary office at which you see all work below you? This would apply only to people who were in offices that were not claims offices. Example: I am a regional VP (wouldn't that be cool) and I want to use the system. I define “Default One” as my region, so when I look at stuff in the system an I see all the offices under my office as my default.
Status: Closed—Resolved
Resolution: 3-22-00, Dave Smith—Yes, I think this a good enhancement. 3-30-00, Kim DeVallance—This would be great!!!
Issue Number: 328
Question: Do we need a primary office that you can create work at? This would apply to everyone and defines the primary office I can create work in. For an Adjuster, this would be their primary office. For someone at a higher level, it would be the office they assign work to if they create it. Following the example above, if that VP creates a res (unlikely, but work with me), this default would be the claims office it would be sent to for completion.
Status: Closed—Resolved
Resolution: 3-22-00, Dave Smith—Yes, I think this a good enhancement as well. 3-30-00, Kim DeVallance—Yes, but keep in mind during the life of a rental we can transfer the rental to different offices within the same company profile.
Issue Number: 329
Question: Where does the manager get assigned to a user? At the Office Level, the User Level or the Team level? Can a user have more than one manager?
Status: Closed—Resolved
Resolution: 08-08-00—Brad Reel: Upon further discussion with the business, the process for selecting a person to handle an authorization limit is as follows: When a user hits an authorization limit, the system will request that the user select another user to approve the request and handle the rental. The system will only present users that have limits higher than the requested amount/number of days. Once the user has been selected, the rental will then be permanently transferred to the chosen user.
Issue Number: 331
Question: Under Report Layout section, is this for the office to give the user what fields that they want them to see? Then the user can set how he views these fields in MY PROFILE?
Status: Closed—Resolved
Resolution: 3-21-00, Anita Klopfenstein—It allows the user to create a default report layout as well as establish groupings. For example: I may want a team group which allows me to select adjusters to view. However, this would be a function which had to be approved in the profile of the user. Otherwise they can only see their work.
Issue Number: 332
Question: Are the authorization limits for the life of the rental or the transaction, (as applied to use by an adjuster)
Status: Closed—Resolved
Resolution: 3-21-00, Anita Klopfenstein—Both—There is a daily limit and a rental max. For the life of the rental.
Issue Number: 350
Question: Do we want to force a search before and admin can add a user?
Status: Closed—Resolved
Resolution: 08-07-00—Brad Reel: When adding a user, the system will search for the UserID and ensure it does not exist. No other searches will be performed.
Issue Number: 352
Question: Where does the ability to change the language the user can view the screens in reside? With the Admin or the user?
Status: Deferred
Resolution:
Issue Number: 356
Question: When setting up a user, should the office profile restrict the user's profile? Or are the office and user profiles independent of each other?
Status: Closed—Resolved
Resolution: 08-07-00—Brad Reel: Office profile overrides user profile. A user can have more rights than the office, but will still be restricted to only activities that can be performed in that office based on the office profile while they are working in that office.
Issue Number: 360
Question: Brad Decoder, Password/do we send e-mail to the admin to let them know how many times login failed?
Status: I2 User Review
Resolution:
Issue Number: 365
Question: Do we need a batch process for adding users?
Status: Closed—Resolved
Resolution: 07-03-00—Brad Reel: This question has also been asked in the more general setting of “Should a process exist for walking a user through setting up an entire company (much like a wizard tool).” For this release of ARMS Web (V2.0) a batch process for creating users will not be created. There will also not be a wizard for creating a company. However, for future releases, this wizard will be a very worthwhile tool to create and should be incorporated into future releases.
Functional Design Specification
User Profile
Version 1.0
1. User Profile Use Case
1.1 Brief Description
The User Profile use case describes how the USER would customize their working environment. User Profile will allow the USER to change their password, set his or her out of office, and modify their Favorite Locations list.
1.2 Use Case Actors
Actors will use this use case to update their user profile. The following actors will interact with this use case:
The Flow of Events will include the necessary steps to make changes and updates to “My Profile”.
1.4.1 Activity Diagram—see
1.4.2 Basic Flow
1.4.2.1 Edit Favorite Location Subflow
This subflow allows the USER to edit a location on their Favorite Locations List.
1.4.2.2 Add Favorite Location Subflow
This subflow allows the USER to add a location to the Favorite Locations List.
1.4.2.3 Remove Favorite Location Subflow
This subflow allows the USER to remove a location to the Favorite Locations List.
1.4.2.4 Out of Office Subflow
This subflow allows the USER to select when they are out of office and assigns their workload to another USER.
1.4.2.5 Change Password Subflow
This subflow allows the USER to change their current password.
1.4.2.6 Confirmation Page
This subflow allows the USER to turn on or off confirmation pages in the ARMS Web system.
1.4.3 Alternative Flows
1.4.3.1 Invalid Password
At step five in the Change Password Subflow, if the current password is incorrect or if the confirmed password does not match the new password, the system will prompt the USER to re-enter the old, the new and the confirmation password.
1.4.3.1.1 It will be considered invalid if the new password entered was one of the USER'S last five ARMS Web passwords.
1.4.3.1.2 It will be considered invalid if the new password is not at between six and 10 characters and alphanumeric in type. —Validate 1.4.3.1.1 & 1.4.3.1.2 in Sign-on.
1.4.3.2 Alternate Users not Chosen in Each Office User is Assigned
At step five in the Out of Office Subflow, the system will validate that a user was selected to handle the USER'S work in each office the USER is assigned to. If a user was not chosen for each office, the system will notify the USER that they must select a user to handle their work in each office they are assigned to. The system will then return the USER to step two of the Out of Office Subflow.
1.4.3.3 Out of Office Start Date is in the Past
At step five in the Out of Office Subflow, the system will validate that a user selected an out of office date that is present (today) or in the future. If the date is in the past, the system will generate an error and ask the USER to enter a date that is either today or in the future. The system will then return the USER to step two of the Out of Office Subflow.
1.4.3.4 Favorite Location Name Entered is the Same as an Existing Location
When the USER submits the name for a new location, or changes the name of an existing location, the system will validate that the name entered is not an exact duplicate of any other name in the USER'S list of Favorite Locations. If the name is a duplicate, the system will prompt the USER to enter a different name for the location in question. The system will then return the USER to step one of the Edit Favorite Location Subflow.
1.4.3.5 Cancel User Profile
At any point during the use case up until a change has been submitted to the system, the USER may decide to not update their profile.
1.5 Post-Conditions
None.
1.7 Extension Points
None.
2. Screen Design
A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the flows identified above. More than one screen may be used to implement support for the use case flow.
2.1 My Profile
This screen will allow the USER to pick which functions that they wish to change.
2.1.1 Screen Layout—My Profile—see
2.1.2 My Profile
2.1.3 Screen Function Definition
This section includes the definitions for all functions that can be performed within the screen. This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity.
2.1.3.1 Process
When clicked, the system will validate the information on the screen is correct and complete. If an error is found the screen will be redisplayed with a message indicating the error condition and highlighting the field in error. If no errors are found, the database will be updated with the new information.
2.1.3.2 Add a Different Office
When clicked, the system will take the USER to MA-02-Find Rental Location Use Case. Here, the USER will select a new location to add to the preferred location list, and then return to the PR-07-User Profile Use Case. The new information will be validated and the database will be updated.
3. Application Operations
This section will detail all the application operations that are part of this Functional Specification Document.
3.1 Retrieve User Profile
(User Id)
Retrieve user's current profile settings.
3.2 Update User Profile
(User Id, Out of Office, Assigned Adjuster, Start Page)
Update user's Out of Office status, Adjuster to handle work during out of office period, and the user's initial page.
3.3 Change Password
(Current Password, New Password, New Password Confirmation)
Change the user's password from the current password to the new password. Validate that the current password is correct.
4. Data Fields
4.1 Data Field Definition
This section includes a definition of all data fields included in the functional specification.
4.1.1 Handler for Out of Office User
This is the user who will handle work for the user who is out of office.
Data Field Type: Alpha-Numeric
Data Field Length: 0
Data Source: <Data Source>
4.1.2 Start Page
This is the initial page that the user will see when he logs on to the system.
Data Field Type: URL
Data Field Length: 256
Data Source: <Data Source>
4.1.3 Is User Out of Office?
This flag indicates that the user is out of office and no work should be assigned to them. Instead another user can be set up to handle for the user who is out of office.
Data Field Type: Boolean
Data Field Length: 1
Data Source: <Data Source>
4.1.4 Password
This is the user specified password that the user will use along with the user id to log on to the ARMS Web System.
Data Field Type: Password
Data Field Length: 10
Data Source: <Data Source>
5. Questions and Answers
Issue Number: 334
Question: Is out of office assigned at the user level or at the office level? (Could you set this for each office you work out of?) Example: You have been created at the St. Louis Office and you need to travel to California to help with a disaster, does California have the rights to maintain you.
Status: Closed—Resolved
Resolution: 4-7-00, Issue Mtd., Defer to user review I2
08-07-00—Brad Reel: A user will be required to set their out of office function for all offices they are assigned to in order to activate the function. The function is set up using the assumption that a user would only be out of office if they were unreachable at all offices (vacation, training, etc.). Since the system can be accessed from any web connection, it is possible for a user to do work for any and all offices they are assigned to from anywhere. Therefore, it seems logical that a user would only set their out of office function if they were not available in any capacity.
Issue Number: 335
Question: Does a user have the field level control of the fields he can see?
Status: Closed—Resolved
Resolution: 04-7-00, Issue Mtg., Should be set at the Office level, the user should not be able to set the field that they want to see.
4-11-00, Brad Reel—User does not need to have control over the fields they see. Control at the office (or team level, where applicable) is sufficient.
Issue Number: 336
Question: Are we still using the “Requests to be Processed” page (the Command Center) as an option for a start up page?
Status: Future
Resolution: 04-7-00, Issue Mtg., Defer to future release, We are not sure that it will not be an option, right now it is not.
4-11-00, Brad Reel—As of right now, the “Command Center” page (Requests to be Processed) should not be an option for the start page, and is not even planned for the ARMS Web system.
Issue Number: 434
Question: 07-06-00—Brad Reel: The ARMS Web redesign has a requirement that the system would allow the user to choose the page in the system they could use as their start-up page. Their options were: the Command Center Page, the Action Items Page, or the Create Reservation Page. Based on the way the system has been designed to process since that time, it does not seem to make sense to be able to choose anything other than the Action Items page as a user's start page. The profile build team suggests removing the option to allow a user to choose their start page from the user profile. 07-07-00—Brad Reel: Feedback from the technical team and the business suggests that it may make more sense to have Create Reservation as an option, and have it process in a different manner than the normal create reservation process. The main advantage of this would be First Notice of Loss Adjusters. There was also consensus that if the ability to select your start page is removed in this release, it should be possible to easily add it back in the future.
07-07-00—Brad Reel: Upon speaking to the database and build teams, it should not be difficult to add the functionality back to the system in a future release. A user's start page was set up as an attribute of a user, and since there will still be other attributes for a user, the start page will just be a new attribute when it is added back. Therefore adding the ability to choose a start page in a future release should not be difficult.
07-07-00—Brad Reel: This issue is being assigned to Sean O'Donnell for review of the feasibility and impacts to the create reservation process if a user is allowed to enter the create res page without having entered the initial required fields (i.e. Claim #, Claim Type, Renter Last Name, etc.). This issue should be discussed for resolution at the 07-17 issues meeting and is being assigned to Craig Lalumandier as resolution contact until it is resolved. Upon resolution, this issue may need to be assigned back to Brad Reel so that the decision can be implemented into the user profile.
Status: Closed—Resolved
Resolution: 07/17/00 [Craig L.]—For the initial release, the start page will not be profiled. This feature would not be difficult to add in the future.
Sean O'Donnell 07-11-00—I would NOT recommend allowing users to have the create reservation page selected as their ‘Start Page’ for the following reasons:
Please contact me if there are concerns with these statements.
This application is a continuation of U.S. patent application Ser. No. 09/694,050, filed Oct. 20, 2000, now U.S. Pat. No. 7,899,690 (the entire disclosure of which is incorporated herein by reference), which is a continuation-in-part of U.S. patent application Ser. No. 09/641,820, filed Aug. 18, 2000, now U.S. Pat. No. 7,275,038.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4714989 | Billings | Dec 1987 | A |
| 4757267 | Riskin | Jul 1988 | A |
| 4774663 | Musmanno et al. | Sep 1988 | A |
| 4788643 | Trippe et al. | Nov 1988 | A |
| 4797818 | Cotter | Jan 1989 | A |
| 4799156 | Shavit et al. | Jan 1989 | A |
| 4831526 | Luchs et al. | May 1989 | A |
| 4858121 | Barber et al. | Aug 1989 | A |
| 4891785 | Donohoo | Jan 1990 | A |
| 4897867 | Foster et al. | Jan 1990 | A |
| 4899292 | Montagna et al. | Feb 1990 | A |
| 4916611 | Doyle, Jr. et al. | Apr 1990 | A |
| 4931932 | Dalnekoff et al. | Jun 1990 | A |
| 4951196 | Jackson | Aug 1990 | A |
| 4984155 | Geier et al. | Jan 1991 | A |
| 5058044 | Stewart et al. | Oct 1991 | A |
| 5063506 | Brockwell et al. | Nov 1991 | A |
| 5182705 | Barr et al. | Jan 1993 | A |
| 5210687 | Wolfberg et al. | May 1993 | A |
| 5216592 | Mann et al. | Jun 1993 | A |
| 5218697 | Chung | Jun 1993 | A |
| 5224034 | Katz et al. | Jun 1993 | A |
| 5237499 | Garback | Aug 1993 | A |
| 5253165 | Leiseca et al. | Oct 1993 | A |
| 5270922 | Higgins | Dec 1993 | A |
| 5289369 | Hirshberg | Feb 1994 | A |
| 5309355 | Lockwood | May 1994 | A |
| 5311425 | Inada et al. | May 1994 | A |
| 5319542 | King, Jr. et al. | Jun 1994 | A |
| 5355474 | Thuraisngham et al. | Oct 1994 | A |
| 5361199 | Shoquist et al. | Nov 1994 | A |
| 5369570 | Parad | Nov 1994 | A |
| 5375207 | Blakely et al. | Dec 1994 | A |
| 5390314 | Swanson | Feb 1995 | A |
| 5396600 | Thompson et al. | Mar 1995 | A |
| 5406475 | Kouchi et al. | Apr 1995 | A |
| 5422809 | Griffin et al. | Jun 1995 | A |
| 5432904 | Wong | Jul 1995 | A |
| 5465206 | Hilt et al. | Nov 1995 | A |
| 5471615 | Amatsu et al. | Nov 1995 | A |
| 5475585 | Bush | Dec 1995 | A |
| 5504674 | Chen et al. | Apr 1996 | A |
| 5506897 | Moore et al. | Apr 1996 | A |
| 5515268 | Yoda | May 1996 | A |
| 5528490 | Hill | Jun 1996 | A |
| 5530844 | Phillips et al. | Jun 1996 | A |
| 5544040 | Gerbaulet et al. | Aug 1996 | A |
| 5544320 | Konrad | Aug 1996 | A |
| 5550734 | Tarter et al. | Aug 1996 | A |
| 5557515 | Abbruzzese et al. | Sep 1996 | A |
| 5557518 | Rosen | Sep 1996 | A |
| 5570283 | Shoolery et al. | Oct 1996 | A |
| 5581461 | Coll et al. | Dec 1996 | A |
| 5586313 | Schnittker et al. | Dec 1996 | A |
| 5588048 | Neville | Dec 1996 | A |
| 5592375 | Salmon et al. | Jan 1997 | A |
| 5592378 | Cameron et al. | Jan 1997 | A |
| 5640505 | Hearn et al. | Jun 1997 | A |
| 5644721 | Chung et al. | Jul 1997 | A |
| 5664207 | Crumpler et al. | Sep 1997 | A |
| 5666493 | Wojcik et al. | Sep 1997 | A |
| 5694551 | Doyle et al. | Dec 1997 | A |
| 5696901 | Konrad | Dec 1997 | A |
| 5696965 | Dedrick | Dec 1997 | A |
| 5710887 | Chelliah et al. | Jan 1998 | A |
| 5710889 | Clark et al. | Jan 1998 | A |
| 5712989 | Johnson et al. | Jan 1998 | A |
| 5721832 | Westrope et al. | Feb 1998 | A |
| 5721913 | Ackroff et al. | Feb 1998 | A |
| 5724520 | Goheen | Mar 1998 | A |
| 5726885 | Klein et al. | Mar 1998 | A |
| 5732398 | Tagawa | Mar 1998 | A |
| 5734823 | Saigh et al. | Mar 1998 | A |
| 5754772 | Leaf | May 1998 | A |
| 5754830 | Butts et al. | May 1998 | A |
| 5757925 | Faybishenko | May 1998 | A |
| 5758329 | Wojcik et al. | May 1998 | A |
| 5758341 | Voss | May 1998 | A |
| 5764981 | Brice et al. | Jun 1998 | A |
| 5768510 | Gish | Jun 1998 | A |
| 5768511 | Galvin et al. | Jun 1998 | A |
| 5774873 | Berent et al. | Jun 1998 | A |
| 5778178 | Arunachalam | Jul 1998 | A |
| 5781892 | Hunt et al. | Jul 1998 | A |
| 5784565 | Lewine | Jul 1998 | A |
| 5793966 | Amstein et al. | Aug 1998 | A |
| 5794207 | Walker et al. | Aug 1998 | A |
| 5796634 | Craport et al. | Aug 1998 | A |
| 5796967 | Filepp et al. | Aug 1998 | A |
| 5797126 | Helbling et al. | Aug 1998 | A |
| 5799157 | Escallon | Aug 1998 | A |
| 5799289 | Fukushima et al. | Aug 1998 | A |
| 5802293 | van der Sijpt et al. | Sep 1998 | A |
| 5802530 | Van Hoff | Sep 1998 | A |
| 5805689 | Neville | Sep 1998 | A |
| 5805829 | Cohen et al. | Sep 1998 | A |
| 5808894 | Wiens et al. | Sep 1998 | A |
| 5809478 | Greco et al. | Sep 1998 | A |
| 5812067 | Bergholz et al. | Sep 1998 | A |
| 5818715 | Marshall et al. | Oct 1998 | A |
| 5819274 | Jackson, Jr. | Oct 1998 | A |
| 5832451 | Flake et al. | Nov 1998 | A |
| 5832452 | Schneider et al. | Nov 1998 | A |
| 5832454 | Jafri et al. | Nov 1998 | A |
| 5835724 | Smith | Nov 1998 | A |
| 5838910 | Domenikos et al. | Nov 1998 | A |
| 5838916 | Domenikos et al. | Nov 1998 | A |
| 5839112 | Schreitmueller et al. | Nov 1998 | A |
| 5839114 | Lynch et al. | Nov 1998 | A |
| 5842176 | Hunt et al. | Nov 1998 | A |
| 5845077 | Fawcett | Dec 1998 | A |
| 5847957 | Cohen et al. | Dec 1998 | A |
| 5848131 | Shaffer et al. | Dec 1998 | A |
| 5848241 | Misinai et al. | Dec 1998 | A |
| 5850446 | Berger et al. | Dec 1998 | A |
| 5857191 | Blackwell, Jr. et al. | Jan 1999 | A |
| 5862346 | Kley et al. | Jan 1999 | A |
| 5864818 | Feldman | Jan 1999 | A |
| 5864827 | Wilson | Jan 1999 | A |
| RE36111 | Neville | Feb 1999 | E |
| 5870719 | Maritzen et al. | Feb 1999 | A |
| 5870733 | Bass et al. | Feb 1999 | A |
| 5875110 | Jacobs | Feb 1999 | A |
| 5877765 | Dickman et al. | Mar 1999 | A |
| 5881230 | Christensen et al. | Mar 1999 | A |
| 5889863 | Weber | Mar 1999 | A |
| 5889942 | Orenshteyn | Mar 1999 | A |
| 5890129 | Spurgeon | Mar 1999 | A |
| 5890140 | Clark et al. | Mar 1999 | A |
| 5892905 | Brandt et al. | Apr 1999 | A |
| 5893904 | Harris et al. | Apr 1999 | A |
| 5897620 | Walker et al. | Apr 1999 | A |
| 5898835 | Truong | Apr 1999 | A |
| 5901214 | Shaffer et al. | May 1999 | A |
| 5903873 | Peterson et al. | May 1999 | A |
| 5907608 | Shaffer et al. | May 1999 | A |
| 5909542 | Paquette et al. | Jun 1999 | A |
| 5909570 | Webber | Jun 1999 | A |
| 5909581 | Park | Jun 1999 | A |
| 5910982 | Shaffer et al. | Jun 1999 | A |
| 5915241 | Giannini | Jun 1999 | A |
| 5918215 | Yoshioka et al. | Jun 1999 | A |
| 5920696 | Brandt et al. | Jul 1999 | A |
| 5923552 | Brown et al. | Jul 1999 | A |
| 5926793 | de Rafael et al. | Jul 1999 | A |
| 5926798 | Carter et al. | Jul 1999 | A |
| 5930474 | Dunworth et al. | Jul 1999 | A |
| 5931878 | Chapin, Jr. | Aug 1999 | A |
| 5931917 | Nguyen et al. | Aug 1999 | A |
| 5933810 | Okawa et al. | Aug 1999 | A |
| 5944784 | Simonoff et al. | Aug 1999 | A |
| 5946660 | McCarty et al. | Aug 1999 | A |
| 5946687 | Gehani et al. | Aug 1999 | A |
| 5948040 | DeLorme et al. | Sep 1999 | A |
| 5950169 | Borghesi et al. | Sep 1999 | A |
| 5953706 | Patel | Sep 1999 | A |
| 5956397 | Shaffer et al. | Sep 1999 | A |
| 5956487 | Venkatraman et al. | Sep 1999 | A |
| 5956509 | Kevner | Sep 1999 | A |
| 5961569 | Craport et al. | Oct 1999 | A |
| 5961572 | Craport et al. | Oct 1999 | A |
| 5963915 | Kirsch | Oct 1999 | A |
| 5966451 | Utsumi | Oct 1999 | A |
| 5970475 | Barnes et al. | Oct 1999 | A |
| 5973619 | Paredes | Oct 1999 | A |
| 5974444 | Konrad | Oct 1999 | A |
| 5977966 | Bogdan | Nov 1999 | A |
| 5978577 | Rierden et al. | Nov 1999 | A |
| 5978747 | Craport et al. | Nov 1999 | A |
| 5978817 | Giannandrea et al. | Nov 1999 | A |
| 5978834 | Simonoff et al. | Nov 1999 | A |
| 5978840 | Nguyen et al. | Nov 1999 | A |
| 5982867 | Urban et al. | Nov 1999 | A |
| 5982868 | Shaffer et al. | Nov 1999 | A |
| 5983200 | Slotznick | Nov 1999 | A |
| 5983208 | Haller et al. | Nov 1999 | A |
| 5987423 | Arnold et al. | Nov 1999 | A |
| 5991739 | Cupps et al. | Nov 1999 | A |
| 5995939 | Berman et al. | Nov 1999 | A |
| 5996017 | Cipiere et al. | Nov 1999 | A |
| 6002767 | Kramer | Dec 1999 | A |
| 6005568 | Simonoff et al. | Dec 1999 | A |
| 6006148 | Strong | Dec 1999 | A |
| 6006201 | Berent et al. | Dec 1999 | A |
| 6009464 | Hamilton et al. | Dec 1999 | A |
| 6012083 | Savitzky et al. | Jan 2000 | A |
| 6014673 | Davis et al. | Jan 2000 | A |
| 6014702 | King et al. | Jan 2000 | A |
| 6016496 | Roberson | Jan 2000 | A |
| 6018627 | Iyengar et al. | Jan 2000 | A |
| 6021406 | Kuznetsov | Feb 2000 | A |
| 6023679 | Acebo et al. | Feb 2000 | A |
| 6026379 | Haller et al. | Feb 2000 | A |
| 6029175 | Chow et al. | Feb 2000 | A |
| 6031533 | Peddada et al. | Feb 2000 | A |
| 6043815 | Simonoff et al. | Mar 2000 | A |
| 6044382 | Martino | Mar 2000 | A |
| 6049671 | Slivka et al. | Apr 2000 | A |
| 6049774 | Roy | Apr 2000 | A |
| 6049832 | Brim et al. | Apr 2000 | A |
| 6054983 | Simonoff et al. | Apr 2000 | A |
| 6058179 | Shaffer et al. | May 2000 | A |
| 6058378 | Clark et al. | May 2000 | A |
| 6061665 | Bahreman | May 2000 | A |
| 6061691 | Fox | May 2000 | A |
| 6064973 | Smith et al. | May 2000 | A |
| 6070142 | McDonough et al. | May 2000 | A |
| 6072870 | Nguyen et al. | Jun 2000 | A |
| 6073163 | Clark et al. | Jun 2000 | A |
| 6073214 | Fawcett | Jun 2000 | A |
| 6076066 | DiRienzo et al. | Jun 2000 | A |
| 6076067 | Jacobs et al. | Jun 2000 | A |
| 6078321 | Simonoff et al. | Jun 2000 | A |
| 6078322 | Simonoff et al. | Jun 2000 | A |
| 6084585 | Kraft et al. | Jul 2000 | A |
| 6085169 | Walker et al. | Jul 2000 | A |
| 6085170 | Tsukuda et al. | Jul 2000 | A |
| 6088677 | Spurgeon | Jul 2000 | A |
| 6091409 | Dickman et al. | Jul 2000 | A |
| 6091412 | Simonoff et al. | Jul 2000 | A |
| 6091810 | Shaffer et al. | Jul 2000 | A |
| 6094640 | Goheen | Jul 2000 | A |
| 6094679 | Teng et al. | Jul 2000 | A |
| 6097802 | Fleischer, III et al. | Aug 2000 | A |
| 6101496 | Esposito | Aug 2000 | A |
| 6108650 | Musk et al. | Aug 2000 | A |
| 6112185 | Walker et al. | Aug 2000 | A |
| 6119105 | Williams | Sep 2000 | A |
| 6119149 | Notani | Sep 2000 | A |
| 6122642 | Mehovic | Sep 2000 | A |
| 6125384 | Brandt et al. | Sep 2000 | A |
| 6125391 | Meltzer et al. | Sep 2000 | A |
| 6144944 | Kurtzman, II et al. | Nov 2000 | A |
| 6144990 | Brandt et al. | Nov 2000 | A |
| 6148289 | Virdy | Nov 2000 | A |
| 6148290 | Dan et al. | Nov 2000 | A |
| 6154172 | Piccionelli et al. | Nov 2000 | A |
| 6163772 | Kramer et al. | Dec 2000 | A |
| 6167567 | Chiles et al. | Dec 2000 | A |
| 6175832 | Luzzi et al. | Jan 2001 | B1 |
| 6178409 | Weber et al. | Jan 2001 | B1 |
| 6185290 | Shaffer et al. | Feb 2001 | B1 |
| 6185540 | Schreitmueller et al. | Feb 2001 | B1 |
| 6189003 | Leal | Feb 2001 | B1 |
| 6192415 | Haverstock et al. | Feb 2001 | B1 |
| 6205482 | Navarre et al. | Mar 2001 | B1 |
| 6223094 | Muehleck et al. | Apr 2001 | B1 |
| 6226654 | Van Hoff | May 2001 | B1 |
| 6226675 | Meltzer et al. | May 2001 | B1 |
| 6229534 | Gerra et al. | May 2001 | B1 |
| 6230117 | Lymer et al. | May 2001 | B1 |
| 6233329 | Urban et al. | May 2001 | B1 |
| 6233609 | Mittal | May 2001 | B1 |
| 6240365 | Bunn | May 2001 | B1 |
| 6253188 | Witek et al. | Jun 2001 | B1 |
| 6263322 | Kirkevold et al. | Jul 2001 | B1 |
| 6272528 | Cullen et al. | Aug 2001 | B1 |
| 6272675 | Schrab et al. | Aug 2001 | B1 |
| 6275843 | Chorn | Aug 2001 | B1 |
| 6282489 | Bellesfield et al. | Aug 2001 | B1 |
| 6282517 | Wolfe et al. | Aug 2001 | B1 |
| 6282568 | Sondur et al. | Aug 2001 | B1 |
| 6286028 | Cohen et al. | Sep 2001 | B1 |
| 6292185 | Ko et al. | Sep 2001 | B1 |
| 6304892 | Bhoj et al. | Oct 2001 | B1 |
| 6308120 | Good | Oct 2001 | B1 |
| 6308160 | Rex | Oct 2001 | B1 |
| 6311207 | Mighdoll et al. | Oct 2001 | B1 |
| 6311213 | Dawson et al. | Oct 2001 | B2 |
| 6324568 | Diec | Nov 2001 | B1 |
| 6327574 | Kramer et al. | Dec 2001 | B1 |
| 6327617 | Fawcett | Dec 2001 | B1 |
| 6332163 | Bowman-Amuah | Dec 2001 | B1 |
| 6334146 | Parasnis et al. | Dec 2001 | B1 |
| 6336100 | Yamada | Jan 2002 | B1 |
| 6339773 | Rishe | Jan 2002 | B1 |
| 6343290 | Cossins et al. | Jan 2002 | B1 |
| 6347398 | Parthasarathy et al. | Feb 2002 | B1 |
| 6351738 | Clark | Feb 2002 | B1 |
| 6360205 | Iyengar et al. | Mar 2002 | B1 |
| 6363388 | Sprenger et al. | Mar 2002 | B1 |
| 6370523 | Anderson | Apr 2002 | B1 |
| 6381324 | Shaffer et al. | Apr 2002 | B1 |
| 6381603 | Chan et al. | Apr 2002 | B1 |
| 6381617 | Frolund et al. | Apr 2002 | B1 |
| 6385312 | Shaffer et al. | May 2002 | B1 |
| 6389431 | Frolund et al. | May 2002 | B1 |
| 6393415 | Getchius et al. | May 2002 | B1 |
| 6393471 | Kobata | May 2002 | B1 |
| 6397191 | Notani et al. | May 2002 | B1 |
| 6397208 | Lee | May 2002 | B1 |
| 6397219 | Mills et al. | May 2002 | B2 |
| 6401094 | Stemp et al. | Jun 2002 | B1 |
| 6418400 | Webber | Jul 2002 | B1 |
| 6418554 | Delo et al. | Jul 2002 | B1 |
| 6445309 | Walker et al. | Sep 2002 | B1 |
| 6477452 | Good | Nov 2002 | B2 |
| 6542912 | Meltzer et al. | Apr 2003 | B2 |
| 6567783 | Notani et al. | May 2003 | B1 |
| 6609050 | Li | Aug 2003 | B2 |
| 6694234 | Lockwood et al. | Feb 2004 | B2 |
| 6732358 | Siefert | May 2004 | B1 |
| 6748426 | Shaffer et al. | Jun 2004 | B1 |
| 6757698 | McBride et al. | Jun 2004 | B2 |
| 6802061 | Parthasarathy et al. | Oct 2004 | B1 |
| 6968388 | Fuldseth et al. | Nov 2005 | B1 |
| 7020620 | Bargnes et al. | Mar 2006 | B1 |
| 7050986 | Vance et al. | May 2006 | B1 |
| 7062765 | Pitzel et al. | Jun 2006 | B1 |
| 7089588 | Schaefer et al. | Aug 2006 | B2 |
| 7136821 | Kohavi et al. | Nov 2006 | B1 |
| 7243075 | Shaffer et al. | Jul 2007 | B1 |
| 7275038 | Weinstock et al. | Sep 2007 | B1 |
| 7328166 | Geoghegan et al. | Feb 2008 | B1 |
| 7899690 | Weinstock et al. | Mar 2011 | B1 |
| 8160906 | Smith et al. | Apr 2012 | B2 |
| 8160907 | Smith et al. | Apr 2012 | B2 |
| 20010005831 | Lewin et al. | Jun 2001 | A1 |
| 20010008998 | Tamaki et al. | Jul 2001 | A1 |
| 20010010058 | Mittal | Jul 2001 | A1 |
| 20010011222 | McLauchlin et al. | Aug 2001 | A1 |
| 20010011246 | Tammaro | Aug 2001 | A1 |
| 20010014907 | Brebner | Aug 2001 | A1 |
| 20010016825 | Pugliese, III et al. | Aug 2001 | A1 |
| 20010016868 | Nakamura et al. | Aug 2001 | A1 |
| 20010018661 | Sato et al. | Aug 2001 | A1 |
| 20010021912 | Demarcken et al. | Sep 2001 | A1 |
| 20010027420 | Boublik et al. | Oct 2001 | A1 |
| 20010027483 | Gupta et al. | Oct 2001 | A1 |
| 20010029459 | Fujiwara | Oct 2001 | A1 |
| 20010032113 | Rudnick | Oct 2001 | A1 |
| 20010032273 | Cheng | Oct 2001 | A1 |
| 20010037224 | Eldridge et al. | Nov 2001 | A1 |
| 20010037255 | Tambay et al. | Nov 2001 | A1 |
| 20010037298 | Ehrman et al. | Nov 2001 | A1 |
| 20010037331 | Lloyd | Nov 2001 | A1 |
| 20010044811 | Ballantyne et al. | Nov 2001 | A1 |
| 20010056361 | Sendouda | Dec 2001 | A1 |
| 20020004796 | Vange et al. | Jan 2002 | A1 |
| 20020007289 | Malin et al. | Jan 2002 | A1 |
| 20020010781 | Tuatini | Jan 2002 | A1 |
| 20020019821 | Rosenbluth | Feb 2002 | A1 |
| 20020022979 | Whipp et al. | Feb 2002 | A1 |
| 20020026337 | Sasaki | Feb 2002 | A1 |
| 20020032626 | DeWolf et al. | Mar 2002 | A1 |
| 20020032790 | Linderman | Mar 2002 | A1 |
| 20020035488 | Aquila et al. | Mar 2002 | A1 |
| 20020040352 | McCormick | Apr 2002 | A1 |
| 20020042843 | Diec | Apr 2002 | A1 |
| 20020042849 | Ho et al. | Apr 2002 | A1 |
| 20020046213 | Vinati et al. | Apr 2002 | A1 |
| 20020046294 | Brodsky et al. | Apr 2002 | A1 |
| 20020046301 | Shannon et al. | Apr 2002 | A1 |
| 20020049603 | Mehra et al. | Apr 2002 | A1 |
| 20020062262 | Vasconi et al. | May 2002 | A1 |
| 20020069123 | Soderlind et al. | Jun 2002 | A1 |
| 20020072937 | Domenick et al. | Jun 2002 | A1 |
| 20020072938 | Black et al. | Jun 2002 | A1 |
| 20020073012 | Lowell et al. | Jun 2002 | A1 |
| 20020073236 | Helgeson et al. | Jun 2002 | A1 |
| 20020076029 | Shaffer et al. | Jun 2002 | A1 |
| 20020077871 | Udelhoven et al. | Jun 2002 | A1 |
| 20020082912 | Batachia et al. | Jun 2002 | A1 |
| 20020083095 | Wu et al. | Jun 2002 | A1 |
| 20020083099 | Knauss et al. | Jun 2002 | A1 |
| 20020091533 | Ims et al. | Jul 2002 | A1 |
| 20020095319 | Swart et al. | Jul 2002 | A1 |
| 20020099562 | Bruce, Sr. et al. | Jul 2002 | A1 |
| 20020099575 | Hubbard et al. | Jul 2002 | A1 |
| 20020099613 | Swart et al. | Jul 2002 | A1 |
| 20020099735 | Schroeder et al. | Jul 2002 | A1 |
| 20020099738 | Grant | Jul 2002 | A1 |
| 20020106069 | Shaffer et al. | Aug 2002 | A1 |
| 20020107918 | Shaffer et al. | Aug 2002 | A1 |
| 20020111846 | Singer | Aug 2002 | A1 |
| 20020111876 | Rudraraju et al. | Aug 2002 | A1 |
| 20020116205 | Ankireddipally et al. | Aug 2002 | A1 |
| 20020116454 | Dyla et al. | Aug 2002 | A1 |
| 20020120459 | Dick et al. | Aug 2002 | A1 |
| 20020120776 | Eggebraaten et al. | Aug 2002 | A1 |
| 20020129021 | Brown | Sep 2002 | A1 |
| 20020133359 | Brown | Sep 2002 | A1 |
| 20020133517 | Carlson et al. | Sep 2002 | A1 |
| 20020136381 | Shaffer et al. | Sep 2002 | A1 |
| 20020143644 | Tosun et al. | Oct 2002 | A1 |
| 20020152100 | Chen et al. | Oct 2002 | A1 |
| 20020156693 | Stewart et al. | Oct 2002 | A1 |
| 20020156865 | Rajarajan et al. | Oct 2002 | A1 |
| 20020169842 | Christensen et al. | Nov 2002 | A1 |
| 20020178087 | Henderson et al. | Nov 2002 | A1 |
| 20020184054 | Cox et al. | Dec 2002 | A1 |
| 20020184266 | Blessin | Dec 2002 | A1 |
| 20020188761 | Chikirivao et al. | Dec 2002 | A1 |
| 20020194219 | Bradley et al. | Dec 2002 | A1 |
| 20020198743 | Ariathurai et al. | Dec 2002 | A1 |
| 20030004822 | Shorter et al. | Jan 2003 | A1 |
| 20030009545 | Sahai et al. | Jan 2003 | A1 |
| 20030014270 | Qureshi et al. | Jan 2003 | A1 |
| 20030014295 | Brookes et al. | Jan 2003 | A1 |
| 20030018666 | Chen et al. | Jan 2003 | A1 |
| 20030023450 | Casati et al. | Jan 2003 | A1 |
| 20030023463 | Dombroski et al. | Jan 2003 | A1 |
| 20030028404 | Herron et al. | Feb 2003 | A1 |
| 20030028533 | Bata et al. | Feb 2003 | A1 |
| 20030036917 | Hite et al. | Feb 2003 | A1 |
| 20030036930 | Matos et al. | Feb 2003 | A1 |
| 20030036966 | Amra et al. | Feb 2003 | A1 |
| 20030041180 | Schlussman | Feb 2003 | A1 |
| 20030114967 | Good | Jun 2003 | A1 |
| 20030125992 | Rogers et al. | Jul 2003 | A1 |
| 20030149600 | Williams | Aug 2003 | A1 |
| 20030154111 | Dutra et al. | Aug 2003 | A1 |
| 20040054600 | Shike et al. | Mar 2004 | A1 |
| 20050021378 | Weinstock et al. | Jan 2005 | A1 |
| 20050091087 | Smith et al. | Apr 2005 | A1 |
| 20050187833 | Royer et al. | Aug 2005 | A1 |
| 20050246206 | Obora et al. | Nov 2005 | A1 |
| 20070174081 | Smith et al. | Jul 2007 | A1 |
| 20070198311 | Menendez et al. | Aug 2007 | A1 |
| 20070260496 | Weinstock et al. | Nov 2007 | A1 |
| 20070271124 | Weinstock et al. | Nov 2007 | A1 |
| 20070271125 | Weinstock et al. | Nov 2007 | A1 |
| 20080010105 | Rose et al. | Jan 2008 | A1 |
| 20080097798 | DeVallance et al. | Apr 2008 | A1 |
| 20080133281 | Bolt et al. | Jun 2008 | A1 |
| 20080140460 | Smith et al. | Jun 2008 | A1 |
| 20080162199 | Smith et al. | Jul 2008 | A1 |
| 20080243562 | Weinstock et al. | Oct 2008 | A1 |
| 20080243563 | Weinstock et al. | Oct 2008 | A1 |
| 20080249814 | Weinstock et al. | Oct 2008 | A1 |
| 20090030747 | Smith et al. | Jan 2009 | A1 |
| 20100023352 | Smith et al. | Jan 2010 | A1 |
| 20110153375 | Weinstock et al. | Jun 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 2001344490 | Dec 2001 | JP |
| 2002074126 | Mar 2002 | JP |
| 9966738 | Dec 1999 | WO |
| 0052601 | Sep 2000 | WO |
| 0197072 | Dec 2001 | WO |
| 0221314 | Mar 2002 | WO |
| 0229675 | Apr 2002 | WO |
| 02057873 | Jul 2002 | WO |
| 02067079 | Aug 2002 | WO |
| 02080646 | Oct 2002 | WO |
| Entry |
|---|
| U.S. Appl. No. 09/564,911, filed May 4, 2000 (Williams). |
| U.S. Appl. No. 09/698,491, filed Oct. 27, 2000 (Menendez et al.). |
| U.S. Appl. No. 09/698,502, filed Oct. 27, 2000 (Menendez et al.). |
| U.S. Appl. No. 09/698,552, filed Oct. 27, 2000 (Menendez et al.). |
| “Thrifty Introduces Automated Car Rental Centers”, PRNEWSWIRE, Jul. 20, 1994. |
| Prosecution History for U.S. Appl. No. 09/641,820, now USPN 7,275,038, filed Aug. 18, 2000 (as of Apr. 20, 2011). |
| Prosecution History for U.S. Appl. No. 09/694,050, now USPN 7,899,690, filed Oct. 20, 2000—Parts 1-3 (as of Apr. 20, 2011). |
| Prosecution History for U.S. Appl. No. 10/343,576, filed Jan. 31, 2003—Parts 1-3 (as of Apr. 20, 2011). |
| Prosecution History for U.S. Appl. No. 11/550,614, filed Oct. 18, 2006 (as of Oct. 24, 2011). |
| Prosecution History for U.S. Appl. No. 11/747,645, filed May 11, 2007 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 11/823,782, filed Jun. 28, 2007—Parts 1 & 2 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 11/868,266, filed Oct. 5, 2007 (as of Apr. 20, 2011). |
| Prosecution History for U.S. Appl. No. 11/881,216, filed Jul. 26, 2007—Parts 1 & 2 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 11/881,383, filed Jul. 26, 2007—Parts 1 & 2 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 11/929,277, filed Oct. 30, 2007—Parts 1 & 2 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 11/929,350, filed Oct. 30, 2007—Parts 1 & 2 (as of Oct. 18, 2011). |
| Prosecution History for U.S. Appl. No. 12/179,071, filed Jul. 24, 2008 (as of Apr. 20, 2011). |
| Response to Office Action for CA Application 2416840 dated Sep. 3, 2010. |
| Interactions, vol. 2, No. 13, Nov. 1, 1993. |
| Interactions, vol. 2, No. 14, Nov. 15, 1993. |
| Interactions, vol. 2, No. 5, May 1993. |
| Interactions, vol. 2, No. 7, Jul. 1993. |
| Interactions, vol. 2, No. 8, Aug. 1993. |
| Interactions, vol. 3, No. 1, Jan. 1, 1994. |
| Interactions, vol. 3, No. 1, Jan. 15, 1994. |
| Interactions, vol. 3, No. 10, May 15, 1994. |
| Interactions, vol. 3, No. 11, Jun. 1, 1994. |
| Interactions, vol. 3, No. 12, Jun. 15, 1994. |
| Interactions, vol. 3, No. 14, Jul. 15, 1994. |
| Interactions, vol. 3, No. 15, Aug. 1, 1994. |
| Interactions, vol. 3, No. 16, Aug. 15, 1994. |
| Interactions, vol. 3, No. 21, Nov. 1, 1994. |
| Interactions, vol. 3, No. 23, Dec. 1, 1994. |
| Interactions, vol. 3, No. 8, Apr. 15, 1994. |
| Interactions, vol. 4, Issue 14, Jul. 15, 1995. |
| Interactions, vol. 4, Issue 16, Aug. 15, 1995. |
| Interactions, vol. 4, Issue 19, Oct. 1, 1995. |
| Interactions, vol. 4, Issue 21, Nov. 1, 1995. |
| Interactions, vol. 4, Issue 24, Dec. 15, 1995. |
| Interactions, vol. 4, No. 3, Feb. 1, 1995. |
| Interactions, vol. 4, No. 6, Mar. 15, 1995. |
| Interactions, vol. 4, No. 9, May 1, 1995. |
| Interactions, vol. 5, Issue 1, Jan. 1, 1996. |
| Interactions, vol. 5, Issue 13, Oct. 1, 1996. |
| Interactions, vol. 5, Issue 14, Nov. 1, 1996. |
| Interactions, vol. 5, Issue 2, Jan. 15, 1996. |
| Interactions, vol. 5, Issue 4, Feb. 15, 1996. |
| Interactions, vol. 6, Issue 12, Dec. 1997. |
| Interactions, vol. 6, Issue 8, Aug. 1997. |
| Interactions, vol. 7, Issue 1, Jan. 1998. |
| Interactions, vol. 7, Issue 12, Dec. 1998. |
| Interactions, vol. 7, Issue 5, May 1998. |
| Interactions, vol. 7, Issue 7, Jul. 1998. |
| Interactions, vol. 7, Issue 8, Aug. 1998. |
| Interactions, vol. 8, Issue 7, Jul. 1999. |
| Interactions, vol. 8, Issue 8, Aug. 1999. |
| Interactions, vol. 8, Issue 9, Sep. 1999. |
| Interactions, vol. 9, Issue 2, Feb. 2000. |
| Interactions, vol. 9, Issue 3, Mar. 2000. |
| Interactions, vol. 9, Issue 5, May 2000. |
| International Search Report for PCT/US2007/025327 dated May 21, 2008. |
| Internet Networking Architecture, 1999. |
| Interoffice Memorandum re ARMS Outline, Oct. 7, 1999, pp. 1-2. |
| Introducing ARMS Claims, Jun. 2000, pp. 1-6. |
| IS General Use Programs—Section 15, AACB40, Overview, pp. 1-16, Jun. 22, 2000. |
| IS General Use Programs—Section 19, AACB34 Callback Fax Customization, Mar. 5, 1998. |
| Jacada Implementation Methodology, pp. 1-10, May 12, 1999. |
| Jacada, Chicago Executive Briefing, Nov. 4, 1999, pp. 1-13. |
| “Additional Internet Efforts Will Propel Every Segment of Our Business”, Free Enterprise, Summer 1999, p. 13. |
| “All Open Orders for Customer No. 218556”; Motorola Corporation; Nov. 23, 1999. |
| “Information on Hertz Corporation”; Sep. 24, 2002; pp. 1-61. |
| “Rental Management for Vehicle Replacement Rentals”, National Electronic Data Interchange Transaction Set Implementation Guide, 272/824, Jul. 2000. |
| “Rental Management Invoicing and Application Advice for Vehicle Replacement Rentals”, National Electronic Data Interchange Transaction Set Implementation Guide, 811/824, Jul. 2000. |
| “Rental Management Remittance Advice for Vehicle Replacement Rentals”, National Electronic Data Interchange Transaction Set Implementation Guide, 820, Jul. 2000. |
| “Welcome to the Hertz Interactive Reservation Process”; Mar. 3, 2000; pp. 62-27. |
| 10K Report; Agency Rent-A-Car Inc.; Report No. 0127651; Section Heading: Part I, Item 1. Business; Jan. 31, 1994; p. 4 of 54. |
| 1997 Rental Systems Manual, 1997. |
| A Call to ARMS, 1996. |
| AACB35 Fax Display, pp. 1-5. |
| AACM07, Customer Add/Update, Revised Documentation, pp. 1-12, Sep. 17, 2001. |
| AAGP12, Group/Branch Name and Address Add/Update, pp. 1 through 2-8, Nov. 19, 1999. |
| AAPW01 Update Code Maintenance, Jul. 1, 1999, pp. 1-25. |
| ABC Insurance Company/EngineRoar, pp. 1-2. |
| ARMS 400 Demonstration, p. 1-67. |
| ARMS Claims Internet Quick Reference Guide, Oct. 1999. |
| ARMS Electronic Callback System Demonstration, pp. 1-22, 1998. |
| ARMS Overview, pp. 1-10. |
| ARMS Technology, Jul. 2000. |
| ARMS/400—Automated Rental Management System, pp. 1-8, 1995. |
| ARMS/400—ERAC Employee Reference, pp. 1-10. |
| ARMS/400 Automated Rental Management System, Copyright 1998. |
| ARMS/400 Automated Rental Management System, Copyright 1999. |
| ARMS/400 Automated Rental Management System, Version 3, Feb. 1997. |
| ARMS/400 Main Menu Flow, pp. 1-20. |
| ARMS/400 Manual. |
| ARMS/400 Training System Document, Nov. 16, 1998. |
| ARMS/400 Update, Mar. 15, 2000, pp. 1-4. |
| ARMS/400 Update, p. 1-7, Jan. 7, 2000. |
| ARMS/400 Update, pp. 1-6. |
| ARMS/400 User Manual, 1999. |
| ARMS/400 User Training, Jul. 2000, pp. 1-26. |
| ARMS/ECARS Handbook for ARMS/Claims Developers, pp. 1-19. |
| ARMS/Web User Training, pp. 1-38, Jul. 18, 2000. |
| ARMS/Web Using Jacada, Oct. 13, 1999, pp. 1-13. |
| Automated Rentals, Unwrapped, pp. 1-7, Oct. 1995. |
| Bluebird Auto Rental Systems, “Are You Buried Under an Evergrowing Mountain of Paper?”. |
| Bluebird Auto Rental Systems, Business Description & Products. |
| Business Wire; “Cendent's Real Estate Subsidiaries Create On-Line Cross-Marketing Alliance with Rent Net; Coldwell Banker, Century 21 and ERA Join Forces with Sister Company, Rent Net”; May 7, 1998; pp. 1-3. |
| Car Rental Insider, May 1997, pp. 1-4. |
| CarTemps Rent-A-Car; “CarTemps DIRECT” information; publication date unknown. |
| CarTemps Rent-A-Car; “CarTemps MPOWERENT Management System”; Instruction Manual; Copyright 2000; v1.1; publication date unknown. |
| CIO Magazine 2002 Enterprise Value Awards Application, pp. 4-10, 2002. |
| CLIP, “Servlets: CGI the Java Way”, Byte, May 1, 1998, pp. 55-56, vol. 23, No. 5, McGraw-Hill, Inc., St. Peterborough, US. |
| Close Pending Ticket Report (All Tickets pended for 5 days or more), Job #579, DR0018, Apr. 3, 1996, pp. 1-2. |
| Copyright Chronicle Publishing Company, May 2, 1997, “Booking a room, vehicle for vacation via the ′Net”, Pantagraph, C.1. |
| CST , May 6, 1999, pp. 1-18. |
| Customer Account Services, AACB45. |
| D.P. General Use Programs, AACB10 Consolidated Callback Maintenance, Apr. 1994, pp. 1-4. |
| Notice of Allowance for U.S. Appl. No. 11/747,645 dated Dec. 28, 2011. |
| Notice of Allowance for U.S. Appl. No. 12/179,071 dated Dec. 30, 2011. |
| Saha, “Application Framework for e-business: Portals”, Internet Citation, Nov. 1999, XP002276158, Retrieved from the Internet: URL:ftp://www6.softwarejbm.com/software/developer/library/portals.pdf, Retrieved on Apr. 5, 2004. |
| Schlosser, “IBM Application Framework for e-business: Security”, Internet Citation, Nov. 1999, XP002257288, Retrieved from the Internet: URL:ftp://www6.software.ibm.com/software/developer/library/security.pdf, Retrieved on Sep. 12, 1999. |
| Summons to Attend Oral Proceedings for EP Application 01273072.7 dated Jan. 30, 2012. |
| Kenyon, Stephanie, “20 Tips for an Effective Web Site”, ASTA Agency Management, Jan. 1999. |
| King, Jeff and Estes, Steve, Enterprise Rent-A-Car ARMS Web-enabled Management Reporting System Initial Project Analysis & Options, Jul. 23, 1999, pp. 1-7. |
| Kiplinger's Money Power; “Booking a room, vehicle for vacation via the ′Net”; Copyright May 2, 1997; Chronicle Publishing Company; Downloaded from the Internet on Apr. 7, 2002. |
| Lone Star Rental Systems, EZ Traker™, Your Complete Auto Rental Management Solution. |
| Lorentz, Jeff, Functional Specification, Internet Application Development, ARMS Automotive, pp. 1-3. |
| Marino, Donna, “Internet Experts Urge Development of E-Commerce Models”, ASTA Agency Management, Jan. 1999, pp. 32-34. |
| McKeown, Rosemary, The Right Computer System Adds to Your Revenue, Computer Systems, pp. 1-4. |
| Memorandum re Sabre Meeting, Rob Hibbard to Scott Shuler, Sep. 21, 1998. |
| Milligan, Michael, “OTA targets mid-January to release e-commerce protocol”, Travel Weekly, Jan. 10, 2000. |
| Nelson, “Quicken 99 for Windows for Dummies”, IDG Books Worldwide, Inc., 1998, pp. 114, 122-124. |
| Net rentacar.com User Guide, pp. 1-19. |
| Office Action for CA Application No. 2416840 dated Jan. 7, 2005. |
| Office Action for CA Application No. 2416840 dated Mar. 5, 2010. |
| Office Action for EP Application No. 01273072.7 dated Apr. 11, 2004. |
| Open Travel Alliance, “ebXML Uses Opentravel Alliance Specification for Early Tests”, May 10, 2000. |
| Open Travel Alliance, “Open Travel Alliance Joins Forces with DISA”, Sep. 9, 1999. |
| Open Travel Alliance, “Open Travel Alliance Names Board Officers”, Sep. 2, 1999. |
| Open Travel Alliance, “OpenTravel Alliance's New XML Specification Creates a Common Customer Profile for Travelers”, Feb. 29, 2000. |
| Open Travel Alliance, “White Paper”, pp. 1-20, Feb. 2000. |
| Orion Systems, Ltd., pp. 1-36. |
| Orion Systems, Ltd., System Overview and Handheld Terminals, downloaded from www.orsys.com on Dec. 1, 1997, pp. 1-5. |
| Orion Systems, Ltd., System Overview with Screens and Reports, May 1996. |
| Our Packages Come in All Sizes!, Nov. 1999, pp. 1-2. |
| PC/ARMS Demonstration, pp. 1-45, 1995. |
| PGMR, ECARS—Enterprise Computer Assisted Rental System, pp. 1-4. |
| Planning and Managing a Project, Version 5.3, CST Catalog UG-184-1198, 1st Ed., Nov. 1998, pp. 1-90. |
| Preview Travel, Inc., Car Reservations, 1999. |
| Reeves, “Travel Web Site Expedia's Shares Take Off During Initial Offering”, Denver Post, Nov. 11, 1999, p. C-02, entire document. |
| Rental 101, pp. 1-30. |
| Rental Redesign Requirements—Contract Process, pp. 1-5, Feb. 16, 2000. |
| Rental Redesign Requirements Contract, pp. 1-56, Feb. 15, 2000. |
| Rental Redesign, Rental Management, RMS (Rental Management Services), Sep. 30, 1998, pp. 1-2. |
| Response to Office Action for CA Application No. 2416840 dated Jul. 7, 2005. |
| Response to Office Action for EP Application No. 01273072.7 dated Aug. 30, 2005. |
| Rosen, Cheryl, “OTA Debuts Data Protocol”, Business Travel News, Jan. 10, 2000. |
| Rosen, Cheryl, “OTA Publishes XML Data Standard”, Business Travel News, pp. 1-2, Mar. 20, 2000. |
| St. Louis Business Journal; “E-commerce Department Director Answers Questions about TWA.com”; Aug. 28, 2000; St. Louis, Missouri. |
| The ARMS Connection, Safeco/Enterprise Rent-A-Car, pp. 1-4. |
| The Connection, State Farm Insurance/Enterprise Rent-A-Car, Rental Process Automation and Procedures, pp. 1-3. |
| The Hertz Corporation, 1998. |
| The Jacada User Guide: Jacada for Java, Version 6.0, CST Catalog UG-213-0799, 1st Ed., Jul. 1999. |
| TSD Brochure, “Are You Comparing Apples to Apples When Choosing Rental Software”, p. 1-3. |
| TSD Brochure, Rent 2000 from TSD, Rental Management Software, Revolutionize the Way You Do Business with the Proven Solution, p. 1-2. |
| TSD Brochure, Rent 2000 from TSD, Rental Management Software, Revolutionize the Way You Do Business, p. 1-29. |
| Warner, Fara, “Car Race in Cyberspace”. |
| Weinstock, Tim, ARMS/Web is Coming, pp. 1-2, Aug. 13, 1999. |
| Welcome to ARMS/400, New York State Rollout and Implementation Session, Oct. 28, 1999, pp. 1-51. |
| Welcome to the Data Warehouse, Jun. 2000, pp. 1-2. |
| Yenckel, “For This Cyberspace Visitor, Once Is More Than Enough”, Feb. 11, 1996, p. E.01, The Washington Post (Pre-1997 Fulltext), ISSN 01908286. |
| U.S. Appl. No. 60/194,128, filed Apr. 3, 2000 (Aquila). |
| Response to Office Action for U.S. Appl. No. 11/823,782 dated Feb. 17, 2011. |
| Response to Office Action for U.S. Appl. No. 11/881,216 dated Sep. 28, 2011. |
| Response to Office Action for U.S. Appl. No. 11/881,383 dated Sep. 6, 2011. |
| Response to Office Action for U.S. Appl. No. 11/929,277 dated Aug. 18, 2011. |
| Response to Office Action for U.S. Appl. No. 11/929,350 dated Aug. 30, 2011. |
| Notice of Allowance for U.S. Appl. No. 13/025,546 dated Jun. 25, 2012. |
| D.P. General Use Programs, AACM12, ECARS—Special Instructions/Rates/Rate Rules, Jun. 1993, pp. 1-5. |
| Darrah, “Hi-Tech Streamlines Car Rental Process”, Feb. 1999, p. 29, vol. 66, Issue 2. |
| Data Warehouse & Analyzer Quick Sheet, Jun. 2000, pp. 1-2. |
| Declaration of Timothy Weinstock, including Exhibits A-D, filed Jan. 12, 2006 in U.S. Appl. No. 09/641,820. |
| Declaration of William G. Tingle, including Exhibits A-F, filed Jan. 12, 2006 in U.S. Appl. No. 09/641,820. |
| Dollar Rent a Car Systems, Inc., pp. 1-5, 1998. |
| ECARS—Enterprise Computer Assisted Rental System, AACJO1 Callbacks, pp. 1-9, Jul. 1, 1997. |
| ECARS 2000 Customer Profile, Chapters 1-16. |
| ECARS Backdated Ticket Report, Job #043/DR0099, Mar. 1996, pp. 1-2. |
| Edlund, Al, “How Thin Clients Lead to Fat Networks”, Business Communications Review, Jul. 1998, pp. 28-31. |
| eINFO, Data Warehouse, Oct. 1999. |
| Email exchange between Ken Keller and David Smith, Jun. 4, 1997. |
| Email from Angela Babin, Jun. 22, 1999, single page. |
| EngineRoar.com, pp. 3-76. |
| Enterprise Computer Assisted Rental System Workbook, Dec. 1996. |
| Enterprise Computer Assisted Rental System Workbook, Sep. 1997. |
| Enterprise Network and Physical Connections Overview, 1995, pp. 1-5. |
| Enterprise Rent-A-Car ARMS—Vehicle Messaging System, Project Charter, Oct. 15, 1998, pp. 1-7. |
| Enterprise Rent-A-Car Company ARMS—Vehicle Messaging System Overview, May 16, 2001, p. 1-35. |
| Enterprise Rent-A-Car Company ARMS—Vehicle Messaging System Phase II Project Charter, Aug. 20, 1999, p. 1-6. |
| Enterprise Rent-A-Car Company, AACM27/AACM28, Overview, pp. 1-8, Nov. 22, 1999. |
| Enterprise Rent-A-Car Company, ARMS Basics and Concepts, vol. 1, Chapter 1-4, Feb. 24, 1998. |
| Enterprise Rent-A-Car Company, ARMS Basics and Concepts, vol. 1, Chapters 1-4, Jun. 10, 1998. |
| Enterprise Rent-A-Car Company, ARMS Technical Document (ATD Internal), pp. 1-40, Aug. 2, 1993. |
| Enterprise Rent-A-Car Company, ARMS, Automated Rental Management System, pp. 1-36. |
| Enterprise Rent-A-Car Company, Automated Rental Management System (ARMS), Version 1, Apr. 12, 1993. |
| Enterprise Rent-A-Car Company, Automated Rental Management System (ARMS), Version 1.1, Jan. 5, 1994. |
| Enterprise Rent-A-Car Company, ECARS Workbook, Dec. 1996. |
| Enterprise Rent-A-Car Company, Functional Specification, pp. 1-2, Nov. 1999. |
| Enterprise Rent-A-Car Customer Profile Data Form, pp. 1-14. |
| Enterprise Rent-A-Car Rental Application Development and Support Project Request, Jul. 12, 1999, pp. 1-3. |
| Enterprise Rent-A-Car Rental Application Development and Support Project Request, Jul. 6, 1999, pp. 1-2. |
| Enterprise Rent-A-Car, ARMS Online Reporting, Project Charter, Version 1.0, Aug. 20, 1999, pp. 1-7. |
| Everything You Need to Know About Arms Automotive, 2000, pp. 1-8. |
| Future State Summary, Jun. 1999, pp. 1-8. |
| GUI ARMS/400 Development Project Approach. |
| GUI ARMS/400 Development, pp. 1-2, 1999. |
| http://www.eautoclaims.com, pp. 1-11, Apr. 8, 2000. |
| http://www.hertz.com/InteractionRes/htm/isexckge.htm, pp. 1-2, Mar. 20, 1997. |
| Interactions, “Electronic Connections”, p. 3, Mar. 15, 1995. |
| Interactions, ARMS Update, vol. 6, Issue 2, Feb. 1997. |
| Interactions, ARMS, vol. 3, No. 6, Mar. 15, 1994. |
| Interactions, Published especially for our Farmers adjusters, 1994. |
| Interactions, Special Edition, Nov. 1992. |
| Interactions, Special Edition, vol. 1, No. 4, Aug. 1992. |
| Interactions, vol. 1, No. 3, Jul. 1992. |
| Interactions, vol. 1, No. 5, Sep. 1992. |
| Interactions, vol. 1, No. 8, Dec. 1992. |
| Interactions, vol. 2, No. 1, Jan. 1993. |
| Interactions, vol. 2, No. 11, Oct. 1, 1993. |
| Number | Date | Country | |
|---|---|---|---|
| 20110153372 A1 | Jun 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09694050 | Oct 2000 | US |
| Child | 13025617 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09641820 | Aug 2000 | US |
| Child | 09694050 | US |
