Patent Grant
8204820
1. Technical Field of the Invention
The present invention relates to a computer system and method for electronically facilitating all aspects of projects, including the project bid process, requisition process, spend process and performance management process, and specifically to electronically managing and analyzing all aspects of the projects.
2. Description of Related Art
Corporations, businesses and other types of enterprises regularly utilize third party providers (vendors) to handle various business functions, such as providing a good or service. Typically, these outsourced business functions are performed under a “project,” “staff supplementation” or “consulting” (hereinafter collectively referred to as “project work”) agreement between the buyer and the vendor. The various tasks involved in project work, such as vendor engagement, project administration, resource management and project accounting, can be extremely complex, entailing the convergence of numerous buyer organizational departments, such as purchasing, finance, operations, legal, human resources, security and the project management organization.
Due to the complexity of project work, it has become standard in today's business environment to employ multiple systems and processes to facilitate the management of project work. For example, typically, separate systems and processes are used for one or more aspects of project work, such as vendor qualification, bid solicitation, bid response, bid evaluation, contract administration, milestone/deliverable administration, payment vouchering and quality control. Currently, there exists on-line “bid” and “auction” systems for handling the bid solicitation and bid response processes, project management tracking systems for providing the milestone/deliverable administration process and financial processing systems for administering the payment vouchering process. However, there does not exist a single system for managing all aspects of project work.
To overcome the deficiencies of the prior art, embodiments of the present invention provide a comprehensive, web-enabled computer system and method for facilitating and managing all aspects of project work in a project bid management system. In embodiments of the present invention, the computer system and method is capable of producing analytical data related the project bid management system. Transactional data related to the bid and project are entered into the computer system through an on-line bid and project requisition process. Using the transactional data stored within the system, virtually any type of analytical data related to single or multiple projects performed by one or more vendors for one or more buyers can be generated.
In one embodiment, the analytical data can include aggregate transactional data associated with multiple projects, multiple vendors and/or multiple buyers. In other embodiments, the analytical data can include statistical data computed as a function of the transactional data. If the analytical data is generated from transactional data related to multiple buyers, the transactional data is stored in a central database that is configured to receive at least a portion of individual transactional data stored within database systems of buyers, vendors or administrators.
In exemplary embodiments, the transactional data includes at least bid data that is entered into data fields of a bid during the on-line bid process. The transactional data can further include project tracking parameters identifying one or more contractual terms of a project associated with the bid and project performance data related to the performance of the project by the vendor. The project tracking parameters can further include taxation information identifying taxable components of the project and taxation amounts associated with each of the taxable components. In other embodiments, the transactional data can further include voucher information entered into data fields associated with the bid and the project by the buyer and the vendor during the performance of the project.
In further exemplary embodiments, the analytical data can be generated from the transactional data based on the type of request and information included as part of the request. For example, the request can include one or more filters related to vendor profile properties, buyer profile properties, project profile properties and/or commodity profile properties. The transactional data can be filtered using the included filters, and the filtered transactional data can be used to generate the analytical data. The analytical data can be presented to an authorized user in a project reporting view on a web page.
The disclosed invention will be described with reference to the accompanying drawings, which show important sample embodiments of the invention and which are incorporated in the specification hereof by reference, wherein:
The numerous innovative teachings of the present application will be described with particular reference to exemplary embodiments. However, it should be understood that these embodiments provide only a few examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily delimit any of the various claimed inventions. Moreover, some statements may apply to some inventive features, but not to others.
In accordance with embodiments of the present invention, a vendor is any provider of goods and/or services, a buyer is any purchaser of goods and/or services, a contractor is a resource employed by a vendor for project work and an administrator is a third-party system administrator or buyer-employed project administrator. Buyers can solicit bids from vendors for a particular good and/or service (hereinafter referred to as a project) in a form specified by the buyer using a bid request generated from a pre-established list of bid items related to the project type. Therefore, the bid responses submitted from vendors all have the same form, enabling efficient and effective evaluation of the bid responses. Embodiments of the present invention further combine the bid process with project management to enable the buyer, vendor, contractor and administrator to track the performance of the project after the bid is awarded.
The bid request data 210 is formatted by the project bid management system 30 and transmitted as a bid request 200 to one or more vendors 10a . . . 10n for solicitation of respective bid responses 220. For example, the vendor 10 can be an individual 10a, business entity 10b or any other vendor 10n that is capable of performing the requested project. Bid responses 220 are submitted from the vendors 10 to the project bid management system 30 for review prior to forwarding qualified bid responses 2201 to the buyer 50. For example, the project bid management system 30 may be pre-configured to force vendor completion of required bid response items in a specific data format to enable the system 30 to perform some filtering of vendor bid responses 220. In this way, the system 30 can ensure that the buyer 50 only receives the bid responses 220 that have the necessary data for bid evaluation.
In accordance with embodiments of the present invention, the project bid management system 30 can be implemented within a computer system 100, as is shown in
A bid web server 120 enables vendors 10, buyers 50, contractors 15 and administrators 80 to interface to a database system 150 maintaining data related to the vendors 10, buyers 50, contractors 15 and administrators 80. The data related to each of the vendors 10, buyers 50, contractors 15 and administrators 80 can be stored in a single database 155, in multiple shared databases 155 or in separate databases 155 within the database server 150 for security and convenience purposes, the latter being illustrated. For example, the database system 150 can be distributed throughout one or more locations, depending on the location and preference of the buyers 50, vendors 10, administrators 80 and contractors 15.
The user interface to the vendor users 5 is provided by the bid web server 120 through a vendor module 115. For example, the vendor module 115 can populate web pages pushed to the vendor browser 20b using the data stored in the particular vendor database 155b. The user interface to the buyer users 5 is provided by the bid web server 120 through a buyer module 110. For example, the buyer module 110 can populate web pages pushed to the buyer browser 20a using the data stored in the particular buyer database 155a. The user interface to the contractor users 5 is provided by the web server 120 through a contractor module 130. For example, the contractor module 130 can populate web pages pushed to the contractor browser 20c using the data stored in the contractor database 155c. The user interface to the administrative users 5 is provided by the bid web server 120 through an administrative module 135. For example, the administrative module 135 can populate web pages pushed to the administrative browser 20d using the data stored in the administrator database 155d. It should be noted that the vendor module 115, buyer module 110, contractor module 130 and administrative module 135 can each include any hardware, software and/or firmware required to perform the functions of the vendor module 115, buyer module 110, contractor module 130 and administrative module 135, and can be implemented as part of the bid web server 120, or within an additional server (not shown).
The computer system 100 further provides an additional user interface to administrative users 5 through an administrative web server 125. The administrative web server 125 enables administrators 80 to interface to a top-level database 160 maintaining data related to the vendors 10, buyers 50 and contractors 15 registered with the computer system 100. For example, the top-level database 160 can maintain vendor qualification data 162, buyer-defined vendor criteria data 164 and contractor re-deployment data 166.
To access information related to vendors 10, the administrative web server 125 uses a vendor module 145 to push web pages to the administrative browser 20d related to vendors 10. For example, the vendor module 145 can access vendor qualification information 162 to qualify vendors 10 for a particular buyer 50 or for a particular industry. Likewise, the administrative web server 125 can push web pages to the administrative browser 20d related to the buyer-defined vendor criteria information 164 through a buyer module 140 in order to qualify vendors 10 for a particular buyer 50. A contractor module 148 enables administrators 80 to access contractor re-deployment data 166 entered by contractors 15 through the bid server 120 and retrieved into the top-level database 160 from a contractor database 155. The re-deployment data 166 can include, for example; an indication of the mobility of the contractor, desired geographical areas, contractor skills, desired pay and other contractor information that can be used to assist administrators 80 in qualifying vendors 10 for buyers 50.
In another embodiment, as shown in
Referring now to
Turning now to
Upon entering the Uniform Resource Locator (URL) of the web server 120 into a computer, a connection between the computer 60 and the web server 120 is created. The web server 120 pushes web pages 61 to the computer 60 for viewing by the user on a user interface device 65. In one embodiment, the user interface device 65 is a computer screen 15 connected to the computer 60. For example, once a user has been validated (e.g., by entering a user name and password), the user can view one or more web pages 61 on the computer screen 65, each containing prompts for the user to enter various information into the computer system 100. The user can enter the information into the computer 60 for transmission via the data network 40 to the web server 120 via an I/O interface 68 and any type of input device 70, such as, for example, a mouse, keyboard, light pen, touch screen (not shown) or voice recognition software (not shown).
At the web server 120, a processor (e.g., a microprocessor or microcontroller) loads and executes computer instructions resident in software modules 128 stored within a storage medium 124, which can be any type of storage medium, as discussed above in connection with storage medium 64. The computer instructions can be created using any type of programming technique, including object-oriented programming techniques. For example, the software modules 128 may contain the computer instructions for the vendor modules, buyer modules, contractor modules and administrative modules (shown in
Examples of web pages 61 displayed to buyer users, vendor users, contractor users and administrative users are shown in
In
Exemplary steps in the bid/project process 500 handled by the project bid management system of the present invention are shown in
Once all of the pre-bid activity is completed (step 510), a buyer can create a bid request for a project (step 520), as will be described in more detail below in connection with
Once the bid request has been approved, the bid request is broadcast (e.g., made available to vendors via the system with optional notification via electronic mail) to qualified vendors (step 530), as will be described in more detail below in connection with
Once all of the bid activity is completed (step 515), the system is further capable of handling post-bid activity (step 560) to track the performance of the project and payment of vouchers during the course of the project. For example, the vendor and contractors assigned to the project can enter time worked and expenses into the system (step 565) for the generation of payable vouchers to be submitted to the buyer through the system, as will be described in more detail below in connection with
As discussed above, a buyer 50 may want to pre-qualify vendors 10 for particular project types to reduce the amount of processing required for each bid request submitted. Referring now to
For example, the vendor qualification data 162 can identify the specific goods and/or services that the vendor 10 provides and the specific geographical areas that the vendor 10 is capable of supplying these goods and/or services, along with other vendor information, such as the size of the vendor, whether the vendor has insurance, whether the vendor is certified in certain industries, etc. The buyer-defined vendor criteria data 164 can identify the specific goods and/or services that the buyer 50 desires, the specific geographical areas that the buyer 50 wants the goods and/or services and other buyer constraints, such as the preferred size of the vendor, requisite vendor insurance needs, requisite vendor certifications, etc.
Based on the vendor qualification data 162 and buyer-defined vendor criteria data 164, the computer system 100 can determine which vendors 10 have the requisite qualifications for buyers 50 and provide qualified vendor information 170 (e.g., name, address, and any other vendor information that the buyer needs) to the buyer 50 for review. If the buyer 50 or optionally the administrator 80 approves of the vendor 10, the buyer 50 can add the vendor information 170 to a vendor list 158, which is stored in the buyer database 155a. In addition, vendor information 172 for those vendors 10 that the buyer 50 previously qualified can also be stored in the vendor list 158. Furthermore, a master copy of the vendor list 158 (i.e., Master Vendor List for Buyers 165) can be stored in the top-level database 160 for redundancy and updating purposes.
Buyer information 174 (e.g., name, address and other information that the buyer agrees to provide) can also be downloaded to the vendor database 155b for storage in a buyer list 159 therein. In addition, a master copy of the buyer list 159 (i.e., Master Buyer List for Vendors 167) can be stored in the top-level database 160 for redundancy and updating purposes. However, it should be understood that if the computer system 100 is implemented solely at the buyer network, the top-level database 160 would not store master copies 165 and 167, and the buyer 50 would perform vendor qualification using only the vendor information 172 known to the buyer 50 or provided directly to the buyer 50 by the vendor 10. For a complete discussion of qualifying vendors 10 for buyers 50 based on vendor qualification data 162 and buyer-defined vendor criteria data 164, reference is made to co-pending and commonly-assigned U.S. patent application Ser. No. 10/141,801, which is hereby incorporated by reference in its entirety herein.
Exemplary steps for qualifying vendors for buyers are shown in
However, if the vendor qualification information does not match the buyer-defined vendor criteria information (step 730), the system determines whether additional vendor qualification information is needed to qualify the vendor for the buyer (step 770). If so, the vendor is requested to provide this additional vendor qualification information (step 780) to qualify the vendor for the buyer (step 710). If not, the vendor is not qualified for the buyer (step 790), and the vendor is not added to the buyer list.
In addition to qualifying vendors for buyers, vendors, buyers and administrators may want to designate certain personnel to handle various aspects of the bid/project process to synchronize communications, data and transaction processing across multiple user platforms. For example, referring now to
Referring now to
Referring again to
To assign specific personnel to user role positions, the specific user role position is selected (step 930), and a list of personnel that can be assigned to that user role position, depending upon user role constraints, is determined from the personnel data file (steps 935, 940 and 945). For example, if a user role position requires a particular level user, only those personnel at the particular user level or higher are included on the list. From the list of personnel for the user role position, one of the personnel is selected for the particular user role position (step 950) and the selected personnel is stored in the user role table (step 925). For example, as shown in
Examples of data structures for selecting and assigning user role positions for a buyer are shown in Tables 1-9 hereinbelow. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for defining and assigning user role positions for the buyer. The tables are related in a hierarchical and/or relational manner, so that all of the necessary information for user role positions can be accurately stored and accessed, as will be described hereinbelow in connection with the exemplary database table structure 300 of
Tables 1 and 2 below illustrate sample user role categories and user role positions within each of the user role categories, respectively, which can be stored in the database in tables “tblHMPositionCategories” 305 and “tblHMPositions” 306, respectively, as shown in
Table 3 below illustrates sample data stored within the personnel date file for each user of the system, which can be stored in the database in table “tblUser” 302, as shown in
Tables 6-9 below will be described in more detail hereinbelow in connection with
As can be seen in
The database table structure 300 for the buyer takes as input personnel data (“tblHRdata” 301) from the buyer and creates a personnel data file (“tblUser” 302) including the specific personnel that may be involved in the shared work environment. The personnel data is shown as table “tblHRdata” 301 for simplicity purposes. However, it should be understood that the personnel data may be in any form, depending on the buyer database system. Periodic downloads from the table “tblHRdata” 301 to the table “tblUser” 302 can be performed to update the system as to the current employees of the buyer to ensure that user role positions are properly assigned. The various business grades designated by the buyer can also be stored in table “tblHMBusinessGrades” 303 and mapped to table “tblUser” 302 for individual assignment of business grades, as discussed above in connection with Tables 3 and 4. In addition, the business grades can be mapped to the selected user roles in table “tblHMPositiontoGrade” 304, as discussed above in connection with Tables 4 and 5.
The user role categories table (“tblHMPositionCategories” 305) and user role positions table (“tblHMPositions” 306), and their interrelation to the position grades and assigned personnel are also shown in
Exemplary steps for a buyer to assign personnel to user role positions during a transaction are shown in
Once the user role positions have been ascertained, the system and/or key personnel determines whether specific personnel (also referred to herein as users) have been pre-designated for the user role positions (step 1215) and whether any of the pre-designated users need to be changed for the transaction (step 1220). If one or more user role positions do not have a pre-designated user or if one or more pre-designated users should be changed, the system and/or key personnel designates the appropriate user for all user role positions (step 1225) and stores the identity of the designated users for the user role positions in the user role table (step 1230) (e.g., “tblBidHMPositions” in
Referring again to
In addition, each user can be provided access rights to view and modify data within the system. For example, one user role position may have the authority to modify or enter data in the system through a first web page, while another user role position may only have the authority to view the data through a second web page. Thus, although the information displayed on the web page may be the same to both users, the actual web pages are different, depending on the approval level of the user role position. When a user logs in to the system, the system determines the approval level of the user and pushes the appropriate web pages to the user. An example of a data structure implementing user role to web page access mapping is shown below in Table 10.
In order to maintain the relationship between user role positions, internal personnel and specific transactions in an ongoing manner, the system of the present invention is further designed to account for shifts in organizational personnel and the business level and user authority of personnel. Referring now to
For specific user role position changes (step 1410), all of the user role positions held by the user can be displayed (step 1425), and one of the user role positions can be selected for changes (step 1430). A new user is chosen for that selected user role position (step 1435) and the new user is substituted for the previous user for that selected user role position (step 1440). This process can be repeated for each user role position that requires a change (step 1445). Specific user role position changes may occur for a number of reasons, such as promotion, reorganization, employee status changes (e.g. full-time to part-time), etc.
If the modification is made based on the transaction type (step 1405), a listing of all transaction types (e.g., bid request creation, bid request broadcasting, bid request receipt, bid response generation, bid response receipt, bid evaluation, bid award, time keeping, vouchering payment, etc.) can be displayed (step 1450), and a particular transaction type is selected (step 1455). All of the user role positions associated with that particular transaction type can be displayed (step 1460) and the particular user role position to be modified is selected (step 1465). A new user is chosen for that selected user role position (step 1470), and the new user is substituted for the previous user for that selected user role position (step 1475). Transaction type modifications may be beneficial, for example, when the particular user for a user role position is unknown, but a change is required due to customer complaints.
The user role position modifications can be applied to existing transactions or only to new transactions (step 1480), depending on the reason for the modification and the need for continuity in existing transactions. If the modification is to be applied to existing transactions, the user role table is updated with the new user and the previous user record is modified to “outdated” (step 1485). However, if the modification is only to be applied to new transactions, the user role table is updated with the new user, but the previous user is not deleted, and the new user is marked for new transactions only (step 1490).
For the vendor, user role positions are typically pre-designated to limit access to qualified personnel. Examples of data structures implementing vendor user roles are shown in Tables 11-13 hereinbelow. As can be seen, the vendor personnel can be assigned a vendor contact type, which can be mapped to access rights to view and modify data within the system, similar to that described above for the buyer in connection with Table 10. However, it should be understood that other vendor user role configurations can be included, and the system is not limited to the specific configurations listed in Tables 11-13.
For the administrator, user role positions can be defined to enable entire processing teams and team members to be specified in order to administer transactional activity associated with specific bid types and for specific locations. Referring now to
Once the user groups have been ascertained, as shown in
In addition, processing teams can be mapped to specific geographic regions, so that different processing teams can handle the same type of transaction in different regions (step 1325). Therefore, when a particular type of transaction is conducted in a particular location, the system can manage the workflow to the appropriate users based on the transaction type and location (step 1330). For example, the appropriate users can be notified of the transaction via an e-mail and/or dashboard update.
Thus, the user role management supported by the system of the present invention provides a flexible, scalable and robust work-sharing environment for the entire bid/project process from bid creation to project completion. In addition, the system enables secure communications and transaction processing based upon user roles, which enables users to interface with the correct personnel at the right times while insuring that data view and access rights are limited to those users that have a functional need for the access.
After the pre-bid activity is completed, a buyer can create and transmit a bid request to one or more vendors to solicit a bid response from the vendors for a particular project. To facilitate the bid process in the context of a complete bid/project process, bid templates can be used for specific project types to solicit the requisite information from vendors for the specific project type in a uniform and comprehensive manner to enable efficient and effective evaluation of bid responses.
Exemplary functionality for creating a bid request utilizing a bid template is shown in
To create a bid template 240, the bid template creation tool 180 accesses the buyer database 155a to retrieve bid items 230 within a bid item list 194 and provides the buyer with the bid item list 230 via the buyer module 110, web server 120, data network 40 and buyer browser 20a for the buyer to choose from. The bid items 230 are associated with specific types of information to be solicited from the buyer, vendor or both. From the list of bid items 230, the buyer selects and provides one or more bid item selections 235 for inclusion in a bid template 240. Depending on buyer configurations, one or more of the bid items 230 may be mandatory for the bid template 240, such as the name of the buyer, location of the work to be performed and type of project work requested. For one or more of the mandatory bid items 230, in addition to including the mandatory bid items 230 in the bid template 240, the specific information associated with each of the mandatory bid items 230 can also be included in fields associated with the mandatory bid items 230 within the bid template 240. For example, the buyer name and project work type can be stored in the bid template 240 for that project work type. Each bid template 240 created by the buyer is stored in the buyer database 155a within a bid template list 190 for later use in creating a bid request 200.
To create a bid request 200, the bid request creation tool 185 accesses the buyer database 155a to retrieve the bid templates 240 stored within the bid template list 190 and provides a list of bid templates 240 to the buyer via the buyer module 110, web server 120, data network 40 and buyer browser 20a for the buyer to choose from. Upon selecting an appropriate bid template 240, the buyer provides bid request data 210 to the bid request creation tool 185 for inclusion in a bid request 200 of the bid template 240 type. For example, the buyer can enter bid request data 210 into provided fields for each bid item selection 235 that requires information from the buyer within the bid template 240. By way of example, but not limitation, the bid request data 210 could include the location of work to be performed, the timing of the project and the specific vendor qualifications necessary for the project.
The bid request creation tool 185 further interfaces with the buyer database 155a to access the vendor list 158 for the buyer and determine the appropriate vendors to receive the bid request. The appropriate vendors can be selected based on the bid template 240 type and any other vendor qualifications included within the bid request 200 itself. Thus, the vendor list 158 can be separated into pre-qualified vendors for bid template 240 types to further reduce processing time when submitting bid requests 200. The bid request creation tool 185 further uses vendor contact information 250 associated with the selected vendors to broadcast (transmit) the bid request 200 to the appropriate vendors (as shown in
Vendor bid responses 220 received from solicited vendors (as shown in
Exemplary steps for creating a bid template, a bid request from the bid template and a bid response from the bid request from various system perspectives are shown in
In
The main processing steps performed by the system for bid request generation and broadcasting are shown in
In
Examples of data structures used for creating the bid templates are shown in Tables 20-25 hereinbelow. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for displaying bid items to the buyer user to select from and storing bid item selections for bid templates. The tables are related in a hierarchical and relational manner, as will be described hereinbelow in connection with
Referring now to
The table “tblRFXBidSections” 401, which has the form of Table 20 above, includes the bid section name and identification of each section 250 of bid items 230, along with an indication of the display order for each bid section 250 on a web page and any comments to be included with the bid section 250 on the web page. Each bid section 250 can be stored as a separate record in table “tblRFXBidSections” 401, with each record having the form of Table 20. Within each bid section 250 are one or more bid categories 255. The table “tblRFXBidCategories” 402, which has the form of Table 21 above, includes the category name, the identification number of each bid category 255 and the associated bid section 250 for each bid category 255. In addition, the table “tblRFXBidCategories” 402 further includes the display order for each bid category 255 on a web page and any comments to be included with the bid category 255 on the web page. Each bid category 255 can be stored as a separate record in table “tblRFXBidCategories” 402, with each record having the form of Table 21.
Each bid category 255 further includes one or more bid items 230 associated with the bid category 255. Therefore, the table “tblRFXBidItems” 403, which has the form of Table 22 above, includes the bid item name and identification number, along with the bid category 255 associated with the bid item 230. A separate record for each bid item 230 can be stored in table “tblRFXBidItems” 403, with each record having the form of Table 22 above. The table “tblRFXBidItems” 403 further includes additional information pertaining to the bid item 230, such as whether or not disablement of the bid item 230 is allowed, whether the bid item 230 is displayed to the vendor, whether the bid item 230 requires a vendor response, the type of data entered by the buyer for the bid item 230, the field length for the data entered by the buyer for the bid item 230; the type of data entered by the vendor for the bid item 230 and the field length for the data entered by the vendor for the bid item 230. For example, the following Table 26 illustrates sample bid items 230 in the table “tblRFXBidItem” 403 making up a bid item list 194, as shown in
Referring again to
Once all of the bid items 230 have been disabled or enabled (bid item selections 235 are enabled bid items) for a particular bid template 240, the bid template 240 and associated bid item selections 235 can be stored in the database table structure 400. The table “tblRFXBidTemplates” 405, which has the form of Table 23 above, includes the bid template name and bid template identification number for use in associating bid item selections 235 with the bid template 240 in the table “tblRFXTemplateItemMatrix” 404, which has the form of Table 24 above. A separate record for each bid template 240 can be stored in table “tblRFXBidTemplates” 405, with each record having the from of Table 23. In addition, a separate record for each bid item selection 235 included within a particular bid template 240 can be stored in table “tblRFXTemplateItemMatrix” 404, with each record having the form of Table 24.
If there are specific bid items 230 that have a default value applicable to all bid templates 240, such as the buyer name, the default value for that particular bid item 230 can be stored in the table “tblRFXBidItemsCDV” 406, which has the form of Table 25. A separate record for each default value associated with each bid item 230 can be stored in table “tblRFXBidItemsCDV” 406, with each record having the form of Table 25. By providing selectable bid items in a structured, configurable and scalable format, any bid item 230 can be added or removed at any time depending on the specific needs of the buyer.
Exemplary steps for creating a bid template using the hierarchical and relational database table structure are illustrated in
If one or more of the bid items in the selected bid category are required (step 1830), the required bid selections are automatically included in the bid template (step 1835). Other bid items are selected based on the needs of the buyer user for the particular type of bid template (step 1840). This process is repeated for each bid category within the selected bid section (step 1845) and for each bid section within the list of bid sections (step 1850), until all bid items have been reviewed and either enabled (selected) or disabled for the bid template. As discussed above, in other embodiments, all bid items within a bid section or bid category may be able to be disabled without individual bid item review if disablement of all of those bid items is allowed. Once the bid item selections have been made for the bid template, the bid template is stored in the bid template list (step 1855) for later use in creating a bid request.
A screen shot of an exemplary web page for creating a bid template is shown in
All of the bid item selections in the bid template are displayed by bid section and bid category to the buyer user for review (step 2010). If one or more of the bid item selections in the bid template are not applicable to the particular bid request (step 2015), and the undesired bid item selections can be disabled (step 2020), the buyer user can disable those bid item selections that are not needed for the particular bid request (step 2025). Thereafter, the buyer user enters the requisite bid request data into appropriate fields for the bid item selections enabled in the bid request (step 2030). For example, one or more bid item selections may contain a field for the buyer to enter data, such as the location of the work to be performed or the type of project work. These fields can be variable type data fields, such as text-entry fields or selectable options fields with links to other web pages containing the selectable option.
An example of a selectable option field that may be displayed involves the selection of a particular type of project work for the bid request from a number of pre-established project types. To implement the project type selection process, a configurable and scalable database structure can be provided that enables the buyer's specific project work business requirements to be classified in a non-prose fashion. By selecting from pre-established project work types, the buyer can ensure that vendor bid responses are synchronous with the buyer's project work requirements. The project work types can also be selected by the vendor when completing vendor qualification data (shown in
Table 27 below illustrates sample project services types, such as consulting, staff supplementation and other project services. Within each of the project services types may be one or more project sectors, as shown in Table 28, and within each of the project sectors may be one or more project families, as shown in Table 29. Therefore, to select a particular project work type (project family) for the bid request, the buyer user can select a project services type and project sector type to display a list of project families to select from. It should be understood that other configurations and project types can be included and the system is not limited to the specific configurations and information listed in Tables 27-29.
Referring again to
In many companies, bid requests must be approved prior to transmission to vendors. Therefore, if the bid request requires approval (step 2040), the originator of the bid request submits the bid request to the appropriate approvers (step 2045). In exemplary embodiments, as discussed above in connection with
As shown in
Once the bid request is in a completed form, the administrative user accesses the vendor list (step 2315) to determine qualified vendors for the bid request based on the bid template type and entered bid request data (step 2320) (e.g., based on the project family in conjunction with the anticipated geographic work location). If the list of qualified vendors is insufficient (step 2325), the administrative user may also query the top-level database (as shown in
A screen shot of an exemplary web page displaying all of the potential vendors to be selected from to include on the qualified vendor list is shown in
Turning back to
Exemplary steps for generation and transmission of a vendor bid response, as shown generally in
To limit the amount of time that vendors have to submit vendor bid responses, the bid request may also include a time frame that the vendor must agree to respond within. If the vendor user cannot agree to respond within the time frame (e.g., by clicking on an accept button) (step 2520), the vendor user is notified that the contents of the bid request will no longer be available to the vendor user and the bid request is removed from the vendor user's view (step 2525). The buyer or project administrator is also notified of the vendors that do not acknowledge the confidentiality agreement or time frame constraints, and based on the number of non-acknowledged vendors, the buyer or project administrator can add vendors to the qualified vendor list and transmit the bid request to the additional vendors to ensure that a sufficient number of vendor bid responses are received.
If the vendor user does agree to respond within the time frame (step 2520), the vendor is authorized to begin completion of the vendor bid response (step 2530). To respond to the bid request, the vendor user accesses the bid item selections by bid section and bid category that require vendor response data for review (step 2535). If the vendor user has any questions regarding the bid request (e.g., the type or amount of vendor response data that is required) (step 2540), the vendor user can submit questions to the buyer for bid clarification within a buyer-configured time frame (step 2545). An appropriate buyer user (e.g., the bid request originator or project administrator) is notified of each question submitted by a vendor via e-mail and/or dashboard update (step 2550) and that buyer user is responsible for providing an answer to the submitted questions within applicable time constraints (step 2555). The vendors are notified of the buyer answers via e-mail and/or dashboard update (step 2560).
For example, a bid message board can be provided by the system that both the vendors and the buyer can access for a particular bid request. A screen shot of an exemplary bid message board 600 is shown in
Turning back to
The bid item fields can be of various data types, such as text/currency/numeric-entry fields and/or selectable options fields. In addition, the fields can have multiple levels of detail associated with a singular bid response item for different aspects of the project. For example, if a project has several phases, as determined by the buyer and/or vendor, the vendor response fields can include a separate section for each phase of the project. Upon attempted submission of the vendor bid response, the system validates vendor completion of all necessary data fields for bid item selections in the vendor bid response (step 2570). If all required data fields are not completed (step 2575), the vendor user is provided a system message indicating the deficient vendor response bid item selections, and is prompted to complete the required bid item selections prior to submitting the vendor bid response (step 2580). Once all required data fields for bid item selections are completed in a bid response (step 2575), the vendor (upon submission) is provided a message indicating that the vendor bid response has been submitted to the buyer or project administrator for review (step 2585) and the appropriate buyer user is notified of a new vendor bid response via e-mail and/or dashboard update (step 2590).
To complete a vendor response to a bid item selection 235, as shown in
An example of vendor response data selected from pre-established vendor responses is shown in
Examples of data structures used for selecting the resource type and associated skills are shown in Tables 30-37 hereinbelow. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for displaying the resource types and associated skills to the vendor user to select from and storing the selected resource profile within the data field of the associated bid item selection. The tables are related in a hierarchical and relational manner, such that the tables are accessed in a particular order for displaying the resource types and associated skills to the vendor user, as will be described hereinbelow in connection with
Table 30 below illustrates sample business sector categories, such as light industrial, management/professional, office and technical. Within each of the business sector categories are one or more business arenas, as shown in Table 31, and within each of the business arenas are one or more business families, as shown in Table 32. Therefore, to select a particular business family associated with the resource type for the bid response, the vendor user can select a business sector category and business arena to display a list of business families to select from. Once the business family is selected, the various skills (general functions and business skills) associated with the resource type can be selected and mapped to the particular resource type, as shown in Tables 33-37. For example, the general functions can identify the level of skill associated with the resource type, the skills category can identify the types of skills, training and experience that the resource type possesses and one or more skills sets associated with each skills category can identify the specific experience associated with the resource type. In addition, certain skills sets can be emphasized over other skills sets by establishing a priority level for each of the skills sets of the resource type. It should be understood that other resource type and skill selections can be provided, and the system is not limited to the particular configuration and information shown in Tables 30-37. For a more complete discussion of resource profiling, reference is made to co-pending and commonly assigned U.S. patent application Ser. No. 10/128,751, which is hereby incorporate by reference in its entirety herein.
Upon submission of the vendor bid response, all of the bid item selection fields are populated with bid data (either bid request data or vendor response data), which is stored in system (buyer database and vendor database) as a bid in a hierarchical and relational manner, as shown in the database table structure 800 of
Tables 38 and 39 below illustrate sample bid request data associated with a particular bid request that can be stored in the database in tables “tblRFX” 801 and “tblRFXSelectedBidItems” 802, as shown in
The specific bid items selections included within the bid request and the bid request data (buyer comments) entered by the originator for each of the bid item selections can be stored in the table “tblRFXSelectedBidItems” 802. Each bid item selection can be stored as a separate record in “tblRFXSelectedBidltems” 802, with each record containing all of the fields shown in Table 39 below. Table “tblRFXSelectedBidItems” 802 is tied to the general bid request information table “tblRFX” 801. As discussed above in connection with
Sample information pertaining to the posting (transmitting) of the bid request to qualified vendors is shown hereinbelow in Table 40, which can be stored in the database in table “tblRFXPost” 803, as shown in
Sample information pertaining to the receipt of the bid request by the vendor and the submission of the vendor bid response is shown hereinbelow in Table 41, which can be stored in the database in table “tblRFXResp” 804, as shown in
Table 43 below illustrates sample vendor bid response data submitted in a vendor bid response from a vendor to a buyer, which can be stored in the database in table “tblRFXRespMain” 806, as shown in
Associated with one or more of the vendor responses to bid item selections may be one or more resource profiles of the particular resources (contractors) that the vendor identified as necessary to complete the project. The resource profiles can be created in advance or as part of the vendor bid response. The resource profiles are generated using the business sector, business arena, business family, general functions and skills discussed above in connection with
Examples of resource profile information (resource type and skills) for resource profiles are shown hereinbelow in Tables 44-46, which can be stored in the database in tables “tblResourceProfileMaster” 807, “tblResourceProfile MasterSkills” 816 and “tblResourceProfileMasterGF's” 817, as shown in
Sample information relating to the particular selected resource profiles submitted with the vendor bid response is shown in Table 47 below, which can be stored in table “tblRFXResourcePfoiles” 818 in
Depending on the bid request, as part of the vendor bid response to one or more bid item selections, the vendor may also provide pricing information associated with the particular selected resource profiles for the project. Sample resource pricing information is shown in Table 48 below, which can be stored in the database in table “tblRFXResourcesProfilePricing” 819, as shown in
In addition to the particular resource profiles and pricing, the vendor bid response may also include information related to the types of materials needed for the project. Sample material information is shown below in Table 49, which can be stored in the database in table “tblRFXRespMaterials” 822, as shown in
The vendor bid response may also include information related to the phasing of the project. Sample phasing information is shown below in Table 50, which can be stored in the database in table “tblRFXRespPhase” 823, as shown in
All of the questions and answers posted by the vendor and buyer on the bid message board and any questions submitted to the vendor from the buyer regarding the vendor bid response can also be stored in the system and associated with the particular vendor bid response. Sample question information is shown in Tables 51 and 52 below, which can be stored in the database in tables “tblRFXQuestionsFromVendor” 820 and “tblRFXQuestionsFromBuyer” 821, as shown in
The vendor bid response can also be associated with details about previous project work that has been performed by the vendor to aid in bid response process. Sample previous project work details are shown in Table 53 below, which can be stored in the database in table “tblRFXRespTrackRecord” 824, as shown in
Referring now to
Once the buyer has received one or more vendor bid responses to a particular bid request, the buyer can grade or otherwise compare the vendor bid responses in order to determine which vendor will get awarded the project. With the use of pre-established bid items in the (bid request and bid responses, all vendor bid responses have the same format, enabling efficient and effective grading and comparison of vendor bid responses. Therefore, prior to begin grading of the vendor bid responses, the buyer can select one or more bid items for grading purposes.
Exemplary functionality for selecting graded bid items and grading vendor responses to the selected graded bid items is shown in
At any time after the creation of the bid request, a grader (e.g. buyer user or project administrator user) responsible for grading vendor bid responses can access the grading tool 188 to select one or more bid item selections 235 from the bid request for grading purposes. The grading tool accesses the bid item list 194 stored in the database 155, retrieves the bid item selections 235 from the bid item list 194 that are included within the particular bid request identified by the grader and displays the bid item selections 235 to the grader via the buyer module 110, web server 120, data network 40 and buyer browser 20a to choose from. From the bid item selections 235, the grader can select one or more graded bid items 236 and provide a list of the graded bid items 236 to the grading tool 188.
Upon receipt of one or more vendor bid responses, the grading tool 188 can access a vendor bid response list 192 to retrieve the vendor response data 215 associated with one of the graded bid items 236 for one of the vendor bid responses in the list 192. The bid item response data 215 is displayed to the grader for grading purposes. Based on various factors (objective and subjective) regarding the quality and information included within the displayed bid item response data 215, the grader can assign a grade for that bid item response 215 and transmit a bid item response grade 260 to the grading tool 188.
The grading tool 188 further interfaces with the database 155 to store the bid item response grade 260 for the vendor in a vendor grades list 198 that contains the bid item response grades 260 for all graded bid items 236 for each of the vendor bid responses in the vendor bid response list 192. In addition, based on all of the bid item response grades 260 received by the grading tool 188 for all of the graded bid items 236 for a particular vendor bid response, the grading tool 188 can calculate an overall vendor score 265 for the particular vendor bid response and store the vendor score 265 in the vendor grades list 198.
Exemplary steps for selecting graded bid items and grading vendor bid responses using the graded bid items are shown in
A more detailed grading process is shown in
Once all of the graded bid items have been chosen and assigned a weighting factor, the grader is provided a list of vendor bid responses (step 3320) and selects one of the vendor bid responses for grading purposes (step 3325). Thereafter, the grader selects one of the graded bid items (step 3330) to grade the vendor bid response data included within the graded bid item (step 3335). The grader can grade the vendor bid response data using any mechanism available to the grader. In one embodiment, the grader can pre-establish grading criteria for a particular graded bid item to enable the system to automatically grade the vendor response data. For example, to grade pricing information, the grader can pre-assign grades to specific pricing ranges, and the system can automatically provide a grade for a pricing graded bid item based on the price submitted in the vendor bid response. In other embodiments, the grader can compare all of the vendor bid response data for a particular graded bid item initially before assigning grades based on the relative differences between the vendor bid response data. In still further embodiments, the grader can pre-establish a checklist or thresholds for each grade to be assigned to a particular graded bid item.
The grade assigned to the vendor response data for the graded bid item is stored in the database (step 3340), and the process is repeated for each graded bid item until the vendor response data included within each graded bid item for a particular vendor bid response is graded (step 3345). Once all of the grades have been completed, the system calculates the vendor's total score based on the individual grades assigned to each graded bid item (step 3350). For example, if the possible grades are A, B, C and D, the vendor score can be calculated by assigning four points for an A, three points for a B, two points for a C and one point for a D.
Each vendor bid response is graded in the same manner (step 3355) to enable the vendor scores to be sorted into descending order (step 3360) for display to the buyer user (step 3365). In addition to the total score, the grader can also be provided with the individual grades for the graded bid items to determine if any re-quotes are necessary. By providing the grader with the total scores and individual grades, the grader can visually determine which vendor had the highest overall score and which vendors had the highest grades for particular graded bid items in order to make a decision as to which vendor to award the project. However, it should be understood that other bid response comparison techniques can be used with the system of the present invention, instead of the specific grading and scoring described herein.
Screen shots of exemplary web pages 61 that can be displayed to the grader for selection of graded bid items and grading of vendor bid responses are shown in
In order to grade vendor bid responses, as shown in
Once a vendor bid response has been graded, as shown in
Examples of the data structures used for selecting the graded bid items and storing the vendor grades are shown in Tables 54-56 hereinbelow. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for displaying bid item selections to the buyer user to select from and storing grades and scores for vendor bid responses. The tables are related in a hierarchical and relational manner, as will be discussed in connection with
Sample bid item selections that could be included in a bid request and associated vendor bid response are shown in Table 54 below. However, it should be understood that other information can be included, and the system is not limited to the specific information shown in Table 54. For each bid item selection, there is an indication of whether or not that bid item selection is gradable. For example, not all of the bid item selections may include vendor response data to grade. Therefore, only the gradable bid item selections are displayed to the buyer user to select from.
A separate grade is stored for each of the graded bid items, as shown in Table 55 below, which can be stored in the database table structure 1100 in table “tblRFXGradeItems” 825, as shown in
The calculated scores 865 for each of the vendor grades 855 for each bid item 235 can be stored as shown below in Table 56, which can be stored in the database in table “RFXItemScoreVendor” 826, as shown in
The table “tblRFXItemScoreVendor” 826 is tied to the table “tblRFXGradeItems” 825 to associate each score 865 with the pertinent grade 855 for all of the graded bid items 236 for a particular vendor bid response. In addition, the table “tblRFXScoreVendor” 827 is tied to the table “tblRFXItemScoreVendor” 826 to associate all of the scores 865 for all of the graded bid items 236 for a particular vendor bid response with the total score 860 for that particular vendor bid response. Furthermore, table “tblRFXScoreVendor” 827 is tied to table “tblRFXPost” 803, which is described above in connection with
After a vendor bid response is received and graded, the buyer user may provide the opportunity for a vendor to submit a re-quote on one or more graded bid items to improve the vendor's score. For example, a vendor that the buyer user typically chooses or that has high grades on other graded bid items may have a lower score than another vendor, and the buyer user may want to provide, the vendor the opportunity to revise the vendor bid response data for the one or more graded bid items that have low grades.
Exemplary steps for facilitating the re-quote process are shown in
If the vendor chooses to not re-quote within a buyer-constrained time frame (step 3630), the original vendor grading and scoring applies to the vendor bid response (step 3640). However, if the vendor does re-quote on one or more of the re-quoted bid items (step 3630), the vendor user can enter new vendor response data into bid item fields for the selected re-quoted bid items (step 3650). Upon receipt of the re-quote (step 3660), the grader grades the re-quoted bid items using the new vendor response data and modifies the vendor score accordingly (step 3670).
Exemplary steps for awarding the bid and entering project tracking parameters are shown in
Once the vendor for the project has been selected, the system notifies both the project administrator (step 3720) and the awarded vendor of the bid award (step 3725). Thereafter, the awarded vendor and buyer enter into negotiations to finalize the terms and conditions of the project, as conventionally done (step 3730). If the awarded vendor and buyer cannot agree on the terms and conditions of the project (step 3735), the buyer can re-open the bid process to select a new vendor based on existing vendor scores, based on new vendor bid responses or both (step 3740). However, if the terms and conditions are agreed to (step 3735), the buyer and awarded vendor can load various project tracking parameters into the system (step 3745), such as the project start date, project end date, anticipated project expenditure (requisition amount), assigned resources, project phasing schedule, project payment release schedule, project deliverables, project materials and project expenses to create a purchase requisition for the project. It should be understood that additional project tracking parameters can be loaded into the system to track the performance of the project, and the system is not limited to the project tracking parameters described herein. Once the purchase requisition for the project is approved by the appropriate approval users for the project administrator and the vendor (step 3750), the project can begin.
Screen shots of exemplary web pages 61 for the project administrator and vendor to load project tracking parameters 870 into the system are shown in
As shown in
For example, as shown in
For example, as shown in
An exemplary process for entering and processing taxation information is shown in
Upon approval by the buyer, the vendor purchase order is created and issued to the vendor (step 4030) to begin working on the project (step 4035). During the commencement of the project, one or more purchase order designated goods or services are performed by the vendor (step 4040). If the good/service is related to billable time expenses of a contractor, the contractor completes his or her time card (step 4045), as will be described in more detail hereinbelow in connection with
As another example of project tracking parameters that can be entered into the system, during the final negotiation, the buyer may request the vendor to submit resumes of resource candidates (actual contractors) for the buyer to approve to ensure that the resource profile positions included in the vendor bid response are filled by actual candidates having the resource profiles. Exemplary data structures for the submission of resource candidates and the review of resource candidates are shown in Tables 58 and 59 below.
Table 58 below illustrates sample resource candidate information that can be submitted for each resource candidate selected by the vendor for a resource profile position in the project. For example, the resource candidate information can include the bid tracking number of the particular bid (bid request and bid response) associated with the resource candidate, the identity of the resource profile for the resource candidate, personal resource candidate information, vendor information, the resume of the resource candidate and the status of the resource candidate submittal. Table 59 illustrates various resource submittal status information that can be included in Table 58. However, it should be understood that other information can be included, and the system is not limited to the specific information shown in Table 58.
Exemplary steps for approving resource candidates are shown in
If one or more of the resource candidates is not acceptable (e.g., the resume does not indicate that the resource candidate has the requisite skills for the resource profile) (step 3820), and there are no other acceptable candidates for the resource profile position (step 3830), the buyer can re-open the bid process to secure another vendor for the project that can provide the necessary resources (step 3840). However, if all resource profile positions can be filled by qualified resource candidates, the buyer and/or vendor enters resource information associated with each of the assigned resource candidates (contractors) into the contractor database (step 3850). For example, personal information concerning the contractor, such as the contractor name, address, telephone numbers and employee number, can be entered into the contractor database. In addition, specific project-related contractor information, such as the total number of authorized billable hours, billable rate, the total amount and type of expenses authorized and any agreements or documents that the contractor needs to execute or provide prior to beginning work, can be entered into the contractor database.
Once the contractor information is entered, the system can authenticate the contractor for time keeping and system access purposes (step 3860). For example, the system can provide a user name and password to the contractor for system log-in and authentication purposes. In addition, the system can require the contractor to execute one or more agreements (e.g., by acknowledging the terms of the agreements on-line) and/or provide one or more documents before being allowed access to the time keeping system.
A screen shot of an exemplary web page 61 displayed to a contractor upon initial log-in and authentication is shown in
Exemplary database structures for storing contractor information and ensuring that relevant documents are obtained from the contractor or agreed to by the contractor are shown in Tables 60-63 below. Table 60 lists various sample documents that either need to be obtained from the contractor or that the contractor needs to execute at some point during the project. Table 60 also lists the time constraints for obtaining or executing such documents. Table 61 lists the contractor information, such as the identity of the contractor, the number of billable hours authorized, the amount of expenses authorized, the execution date of various documents and the contractor type. Table 62 lists the particular document and identifies whether the contractor has executed or provided that document and the date of such execution or provision. It should be understood that a separate record for each document is stored having the format of Table 62. Table 63 illustrates various exemplary information identifying the type of contractors, such as the number of days the contractor has and has not worked for the buyer. However, it should be understood that other information can be included, and the system is not limited to the specific information shown in Tables 60-63.
Examples of the data structures used for storing the project tracking parameters are shown in Tables 64-79 hereinbelow. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for tracking the performance of the project. The tables are related in a hierarchical and relational manner, as will be discussed in connection with
Table 64 below illustrates sample general purchase requisition information, which can be stored in the database in table “tblPurchaseReq” 1000, as shown in
Tables 65-70 below illustrate sample specific purchase requisition information associated with tax codes, account plants, cost centers, project codes, account assignment and other similar buyer specific purchase requisition information, all of which can be stored in the database in respective tables “tblPurchaseReqTaxCode” 1001, “tblPurchaseReqAcctPlant” 1002, “tblPuchaseReqAcctCostCenter” 1003, “tblPurchaseReqProjectCodes” 1004, “tblPurchaseReqAcctGL” 1005 and “tblPurchaseReqAcctAssignment” 1006, as shown in
Tables 71-75 below illustrate sample requisition payment information related to the purchase requisition. For example, such requisition payment information can include payment amounts based on project deliverables (e.g., goods and services delivered at the end of the project or during phases of the project), payment amounts based on time frames, payment amounts based on the number of units completed, payment amounts based on project materials and payment amounts based on project expenses. In
It should be understood that additional tables or information may be included, depending on the purchase requisition requirements. In addition, it should be understood that one or more of the payment tables can be included, depending on the project. Furthermore, it should be understood that a separate record for each payment amount is included having the format of one of Tables 71-75 below.
Tables 77 and 77 below illustrate sample information associated with the pay rates for contractors assigned to the purchase requisition. For example, the contractor pay rate information can indicate the type of pay (e.g., hourly, fixed, overtime, etc.) and the pay rate amount (e.g., billable rate per hour, billable rate per overtime hour, billable amount). The pay rate information can be stored in the database in tables “tblPurchaseReqPayRates” 1014 and “tblluContractorPayRateTypes” 1015, which are shown in
Tables 78 and 79 below illustrate sample payment information associated with the contractor expenses for contractors assigned to the purchase requisition. For example, the contractor expense information can indicate the type of expense and the maximum amount allocated for the expense. The contractor expense information can be stored in the database in tables “tblPurchaseReqPayContractorExpenses” 1016 and “tblluContractorPayExpenseTypes” 1017, which are shown in
Once the project has begun, the project administrator (or buyer) can monitor the progress of the project using a time keeping system, in which contractors enter time into time cards for project work performed. The time cards can be stored to assess project performance for requisition payment information and/or to generate payment vouchers based on time worked, depending on the requisition payment information. For example, if the requisition payment amount was based, at least in part, on an anticipated number of billable hours of a particular contractor at a particular pay rate, and the contractor completed the project under the anticipated number of billable hours, the project administrator and vendor may be able to re-negotiate the requisition payment amount that was initially set for payment based on deliverables, time frames or units.
Referring now to
Once the contractor has entered the time keeping information into the time card, the time card is provided to the project administrator (step 4325) for review and approval (step 4330). If the time card is not approved (step 4340), the contractor and vendor are notified of the time card rejection (step 4350) and the contractor is instructed to access the time keeping system to modify the time card (step 4300). For example, if the contractor has not completely filled out the time card, the time keeping information (e.g., number of hours) entered into the time card is out of the normal or unreasonable or the project administrator has knowledge that the time keeping information is incorrect, the time card may be rejected. If the time card is approved (step 4340), all applicable records within the system are updated with the time keeping information (step 4360) and any payable vouchers associated with the time keeping information are extracted for invoice processing (step 4370). For example, if requisition payment is based on the number of hours worked within a particular time frame, a payable voucher may need to be generated based on the time keeping information entered by the contractor.
Screen shots of exemplary web pages 61 provided to the contractor through the time keeping system are shown in
To create a new time card (or complete a temporarily saved time card), as shown in
A screen shot of a sample web page 61 displayed to the project administrator for review of the submitted time card is shown in
Exemplary database structures for storing the time cards and contractor expense vouchers are shown in Tables 80-83 below. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for storing time cards and contractor expense vouchers. The tables are related in a hierarchical and relational manner with other tables stored in the database, as will be discussed in connection with
Table 80 below illustrates sample general time keeping information, which can be stored in the database table structure 1160 in table “tblTimeCard” 1050, as shown in
The time card status identifier stored in the table “tblTimeCard” 1050 can be selected from a table “tblluTimeCardStatus” 1051, which stores time card status types (e.g., temporarily saved, submitted, approved, rejected, etc.) and their associated time card status identifiers.
Table 81 illustrates sample detailed time keeping information, which can be stored in the database in table “tblTimeCardDetails” 1052, as shown in
Table 82 below illustrates sample general contractor expense voucher information, which can be stored in the database in table “tblContractorExpenseVoucher” 1054, as shown in
Table 83 below illustrates sample detailed contractor expense voucher information, which can be stored in the database in table “tblContractorExpenseVoucherDetails” 1055, as shown in
Referring now to
Referring now to
If the voucher is not approved (step 4460), the vendor is notified and provided the option of re-submitting the voucher (step 4470). If the voucher is approved (step 4460), the vendor is notified of the approval of the voucher (step 4480). If the voucher is a billable voucher (step 4490), the voucher is processed for electronic invoicing based on prescribed scheduling (using system or buyer constraints) (step 4495). For example, the system can employ a batch process to collect all payment vouchers for the buyer (for one or more projects) approved during a pre-designated time period. All invoices can be generated in a format based on buyer specifications or in a system-defined format. The buyer receives the invoice(s) (step 4498) and releases payment of the invoice(s) to the vendor(s) via a pre-configured method (e.g., EFI, check, etc.) (step 4499).
Exemplary database structures for storing the voucher information in payable vouchers and generating a paid voucher record are shown in Tables 84-92 below. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for storing voucher information. The tables are related in a hierarchical and relational manner with other tables stored in the database, as will be discussed in connection with
Table 84 below illustrates sample general project unit completion voucher information, which can be stored in the database table structure 1170 in table “tblVoucherUnits” 1060, as shown in
Furthermore, although not shown, the table “tblContractorExpenseVoucher” 1054, shown in
Table 85 below illustrates sample detailed project unit completion voucher information, which can be stored in the database in table “tblVoucherUnitsDetails” 1061, as shown in
It should be understood that a separate record in the format of Table 85 is stored in table “tblVoucherUnitsDetails” 1061 for each payable unit voucher. It should further be understood that other tables and project unit completion voucher information can be included, and the system is not limited to the specific tables and project unit completion voucher information shown in
Table 86 below illustrates sample general time completion voucher information, which can be stored in the database in table “tblVoucherTimePayment” 1062, as shown in
Table 87 below illustrates sample detailed time completion voucher information, which can be stored in the database in table “tblVoucherTimePaymentDetails” 1063, as shown in
It should be understood that a separate record in the format of Table 87 is stored in table “tblVoucherTimePaymentDetails” 1063 for each payable unit voucher. It should further be understood that other tables and time completion voucher information can be included, and the system is not limited to the specific tables and time completion voucher information shown in
Table 88 below illustrates sample general project expense voucher information, which can be stored in the database in table “tblVoucherProjectExpense” 1064, as shown in
Table 89 below illustrates sample detailed project expense voucher information, which can be stored in the database in table “tblVoucherProjectExpenseDetails” 1065, as shown in
It should be understood that a separate record in the format of Table 89 is stored in table “tblVoucherProjectExpenseDetails” 1065 for each payable project expense voucher. It should further be understood that other tables and project expense voucher information can be included, and the system is not limited to the specific tables and project expense voucher information shown in
Table 90 below illustrates sample general material voucher information, which can be stored in the database in table “tblVoucherMaterials” 1066, as shown in
Table 91 below illustrates sample detailed material voucher information, which can be stored in the database in table “tblVoucherMaterialsDetails” 1067, as shown in
It should be understood that a separate record in the format of Table 91 is stored in table “tblVoucherMaterialsDetails” 1067 for each payable material voucher. It should further be understood that other tables and material voucher information can be included, and the system is not limited to the specific tables and material voucher information shown in
1-
Table 92 below illustrates sample general deliverables voucher information, which can be stored in the database in table “tblVoucherDeliverables” 1068, as shown in
Table 93 below illustrates sample detailed deliverables voucher information, which can be stored in the database in table “tblVoucherDeliverablesDetails” 1069, as shown in
It should be understood that a separate record in the format of Table 93 is stored in table “tblVoucherDeliverablesDetails” 1069 for each payable deliverables voucher. It should further be understood that other tables and deliverables voucher information can be included, and the system is not limited to the specific tables and deliverables voucher information shown in
Table 94 below illustrates sample paid voucher information, which can be stored in the database as table “tblPaidVoucherRecords” 1070, as shown in
Table “tblPaidVoucherRecords” 1070 is shown tied to table “tblPurchaseReq” 1000, which is discussed above in connection with
Referring now to
During the pre-bid, bid and post-bid activities described above, various transactional data related to the bid/project process are obtained from the buyer, vendor and other parties (e.g., administrator) involved in the process. As shown in
For example, referring now to
Once the buyer 50 has awarded the bid to a particular vendor 10, both the buyer 50 and vendor 10 can enter project tracking parameters 870 (e.g., purchase requisition information, taxation information, etc.) into the system 30 (step 4520) for storage in the database, along with the bid data 212. The project tracking parameters 870 can include some or all of the contract terms and conditions, including vendor responsibilities for goods and services, both billable and non-billable. When the vendor 10 provides an authorized good or service (as determined by the entered project tracking parameters 870), the vendor 10 can access the system to submit a voucher to request payment, or buyer acknowledgment of completion in the event that the activity is non-billable, for the good provided or service performed (step 4530). Upon approval of the voucher and subsequent invoicing for the same, the buyer releases payment to the vendor via a pre-configured method (step 4540). The information entered by the buyer 50 and vendor 10 during the voucher submittal and payment process is stored as voucher information 1160 in the database.
During the performance of the project, various project performance data 1190 can be entered into the system 30, or generated automatically by both the vendor 10 and the buyer 50 (step 4550), as will be described in more detail hereinbelow with respect to
The bid data 212, project tracking parameters 870, voucher information 1160 and project performance data 1190 are all stored in the system database as transactional data related to the bid and project. With access to all of this transactional data, the system 30 can perform virtually any type of analysis desired and generate reports based on the analysis. Thus, the system 30 is operable to receive requests for certain types of analytical data from the buyer, vendor or another user with access to the analytical data (step 4560). In accordance with the request, the system 30 performs an analysis of the transactional data to generate the analytical data (step 4570) and provides the analytical data to the requestor (e.g., buyer 50, vendor 10 or other user) (step 4580) in a reporting view.
For example, a buyer 50 can request reports containing analytical data related to a specific project, multiple projects or multiple vendors 10. The analytical data can be directed to financial information (e.g., invoice details, spending (past, present and future) and other types of financial analysis), project information (e.g., project performance, future project activity and project planning), vendor information (e.g., vendor financial information, vendor operational information and supply chain information) and any other type of information desired. In addition, a buyer 50 can request reports containing industry analytical data related to multiple projects commissioned by multiple buyers 50. The industry analytical data can be directed to financial information (e.g., the percentage of total cost spent on various aspects of a project type or the percentage amount spent industry-wide on various types of projects), vendor information (e.g., the on-time percentage of the vendor in the industry or the cost percentage over/under budget of the vendor in the industry), and any other type of industry information as desired. Similar analytical data can be provided to a vendor 10 or other authorized user. For example, a vendor 10 or administrator can request reports containing analytical data related to a specific project or multiple projects that the vendor 10 is involved in conducting.
Turning now to
In one embodiment, the project performance data 1190 can be entered directly into the database 155 by a buyer, vendor or administrator through the project performance tool 180. The buyer, vendor or administrator can access the server 120 of the computer system 100 via the buyer browser 20a, vendor browser 20b or administrative browser 20c, respectively, and the data network 40. The buyer module 110, vendor module 115 or administrative module 135 interfaces with the project performance tool 121 to push web pages to the buyer browser 20a, vendor browser 20b or administrative browser 20c, respectively, soliciting the project performance data. The project performance tool 121 accesses the database 155 to populate project performance data fields associated with a particular project with the project performance data entered by the buyer, vendor and/or administrator. For example, the project performance data can include comments by the buyer, vendor and/or administrator on the status or personal project satisfaction thus far.
Upon receiving project performance data 1190 from either the buyer, vendor or administrator, the project performance tool 121 can further be configured to automatically generate a message (e.g., e-mail message) to the other parties informing them of the new project performance data 1190, thereby enabling the other parties to enter additional project performance data 1190 clarifying, responding or providing data unrelated to the previously entered project performance data 1190.
In other embodiments, the comparison tool 123 can automatically enter the project performance data 1190 into the database 155 based on a comparison of project tracking parameters 870 and voucher information 1160 associated with a particular project. The comparison tool retrieves requisite project tracking parameters 870 and voucher information 1160 from the database 155, performs a comparison or analysis of the retrieved project tracking parameters 870 and voucher information 1160, and based on the results of the comparison or analysis, enters any necessary project performance data 1190 into data fields associated with the project within the database 155.
As an example, the comparison tool 123 can be configured to monitor the database 155 for new voucher information 1160 entries or otherwise be triggered upon the entry of new voucher information 1160 to compare the entered voucher information 1160 with the previously stored project tracking parameters 870 for the project. The voucher information 1160 can contain cost, timing or other information with which to compare to the project tracking parameters 870. The results of the comparison can be stored as project performance data 1190 in the database 155. For example, the voucher information 1160 could indicate an invoice amount paid by the buyer 50 on a project, and the comparison tool 123 can compare the invoice amount with the requisition amount to determine if a discrepancy exists. In this case, the project performance data 1190 could include an indication of the cost status, such as under-budget, over-budget or in-budget, and the amount over or under budget, if any.
As another example, the comparison tool 123 can be configured to search the database 155 for particular project tracking parameters 870, and enter the status of the project tracking parameters 870 as project performance data 1190. For example, the comparison tool 123 can search the database 155 for expired target completion dates on projects, and enter the number of days each of the projects are past due as project performance data 1190 related to those projects. The comparison tool 123 can further search for voucher information 1160 related to those past due projects and enter the status of the projects based on the voucher information 1160. For example, if the vendor has submitted a voucher for payment, but the buyer has not yet made the payment, the status could indicate “voucher submitted, awaiting payment.”
Exemplary processes for entering project performance data 1190 from various system perspectives are shown in
Exemplary database structures for storing the project performance data 1190 are shown in Tables 95-112 below. The data structures are illustrated for simplicity as being organized in a table format, with each table including all of the fields necessary for storing project performance data 1190. The tables are related in a hierarchical and relational manner with other tables stored in the database, as will be discussed in connection with
Tables 95 and 96 below illustrate sample deliverable project performance data, which can be stored in the database table structure 1185 in table “tblDeliverableTrackPerformance” 1080 and table “lkpDeliverableStatus” 1081, as shown in
For example, if the buyer, vendor or other user has entered any comments related to the status of the deliverables, these comments can be stored in table “tblDeliverableTrackPerformance” 1080. The identity of the user that entered the comments, along with the date the comments were entered can also be stored in-addition to the comments. If the system is configured to inform the vendor when the buyer enters comments, the status of the vendor response (e.g., not yet responded, no response, response) can also be stored.
Tables “tblDeliverableTrackPerformance” 1080 and “lkpDeliverableStatus” 1081 are shown tied to table “tblPurchaseReqPayDeliverable” 1007, which in turn is tied to table “tblPurchaseReq” 1000, which are discussed above in connection with
Tables 97 and 98 below illustrates sample phase project performance data, which can be stored in the database table structure 1185 in table “tblPhaseTrackPerformance” 1082 and table “lkpPhaseStatus” 1083, as shown in
For example, if the buyer, vendor or other user has entered any comments related to the status of the phasing, these comments can be stored in table “tblPhaseTrackPerformance” 1083. The identity of the user that entered the comments, along with the date the comments were entered can also be stored in addition to the comments. If the system is configured to inform the vendor when the buyer enters comments, the status of the vendor response (e.g., not yet responded, no response, response) can also be stored.
Tables 99 and 100 below illustrates sample units project performance data, which can be stored in the database table structure 1185 in table “tblUnitsTrackPerformance” 1084 and table “lkpUnitStatus” 1085, as shown in
For example, if the buyer, vendor or other user has entered any comments related to the status of the units, these comments can be stored in table “tblUnitsTrackPerformance” 1084. The identity of the user that entered the comments, along with the date the comments were entered can also be stored in addition to the comments. If the system is configured to inform the vendor when the buyer enters comments, the status of the vendor response (e.g., not yet responded, no response, response) can also be stored.
Tables 101 and 102 below illustrates sample cost project performance data, which can be stored in the database table structure 1185 in table “tblCostTrackPerformance” 1086 and table “lkpCostStatus” 1087, as shown in
For example, if the buyer, vendor or other user has entered any comments related to the status of the cost, these comments can be stored in table “tblCostTrackPerformance” 1086. The identity of the user that entered the comments, along with the date the comments were entered can also be stored in addition to the comments. If the system is configured to inform the vendor when the buyer enters comments, the status of the vendor response (e.g., not yet responded, no response, response) can also be stored.
Other tables are shown in
Other information related to the vendor and the buyer can be stored in additional tables. For example, Table 106 below illustrates master vendor data, which can be stored in the database table structure 1185 in table “lkpVendorMaster” 1090, and Table 107 below illustrates master buyer data, which can be stored in the database table structure 1185 in table “lkpBuyerMaster” 1095, as shown in
As described above in connection with
In other embodiments, as shown in
The transferred transactional data 1195 can include all of the transactional data 1195 in the lower-level database 160 or only a portion as designated by the system or the buyer/administrator and/or vendor. For example, various portions of the transactional data 1195 may not be necessary for industry-wide analytical purposes, and therefore, the transactional data 1195 transferred to the central database 160 may exclude those portions that are unnecessary. As another example, the buyer/administrator and/or vendor may desire to limit the type of transactional data 1195 that is made available to the central database 160 for privacy or other reasons.
Referring now to
The analytical data 270 can be generated using transactional data 1195 from a lower-level database (not specifically shown) within the lower-level database system 150 or from the central database 160, depending on the type of analytical data 270 desired. For example, if a buyer user requires analytical data related to only those projects associated with the buyer, the buyer user would access the transactional data 1195 within the lower-level database of the buyer within the lower-level database system 150. However, if the buyer user requires industry analytical data related to projects associated with multiple buyers, the buyer user would access the transactional data 1195 within the central database 160.
To receive analytical data 270 using transactional data 1195 from either the lower-level database system 150 or the central database 160, a buyer user, vendor user or administrative user accesses the respective server 120 or 125 associated with the database 150 or 160 via the buyer browser 20a, vendor browser 20b or administrative browser 20c, respectively and the data network 40. The buyer module 110 or 140, vendor module 115 or 145 or administrative module 135 or 149 interfaces with the reporting module 126 or 127 to push web pages to the buyer browser 20a, vendor browser 20b or administrative browser 20c, respectively, to assist the buyer user, vendor user or administrative user in generating a request 285 for a specific type of analytical data 270. For example, the analytical data 270 requested can be related to various price and performance factors as a function of the transactional data 1195. The analytical data 270 can be related to a single project, multiple projects, multiple vendors or multiple buyers, the latter being possible with only the central database transactional data 1195. The different permutations and possibilities for the different types of analytical data 270 that can be generated are limited only by the type and amount of transactional data 1195 that is stored. In addition, it should be understood that, although not shown, in other embodiments, a contractor user may be allowed to access various analytical data 270 that the contractor is authorized to view, such as the number of hours worked by the contractor on a project to date, the number of hours worked on all projects within a certain time period, the pay rate for different projects, the average pay rate, etc.
In some embodiments, the request 285 submitted by the user may contain one or more filters 280 to focus the analytical data 270 on specific transactional data 1195. For example, the user may want to receive analytical data 270 related to only those projects completed in a specific geographical area or associated with a specific project type or industry segmentation. The reporting module 126 or 127 uses the filters 280 to access the database 150 or 160 to retrieve filtered transactional data 1198 that contains only that transactional data that meets the requirements of the filters 280. From the filtered transactional data 1198, the reporting module 126 or 127 generates the analytical data 270.
Using the transactional data 1195 or filtered transactional data 1198, the reporting module 126 or 127 generates the analytical data 270 based on the request 285. For example, if the request 285 is for a financial report indicating the projected spending in future months on current projects, the reporting module 126 or 127 can access the transactional data 1195 to retrieve various project tracking parameters related to future requisition amounts of current projects, and aggregate the requisition amounts by month to generate the analytical data 270. As another example, if the request 285 is for a statistical report on the percentage of expenditures on various components of projects (e.g., materials, expenses, deliverables, labor, etc.) with tier 1 vendors, the reporting module 126 or 127 can access the transactional data 1195 to retrieve various bid data (to determine the projects tied to tier 1 vendors), project tracking parameters, voucher information and project performance data and utilize various mathematical and statistical functions to produce the analytical data 270. The reporting module 126 or 127 pushes web pages including reporting views containing the analytical data to the buyer browser 20a, vendor browser 20b or administrative browser 20c.
Exemplary processes for generating various types of analytical data 270 using various types of transactional data are shown in
Once the requisite transactional data is identified and retrieved, the analytical data is generated from the transactional data (step 4810). In generating the analytical data, various mathematical and statistical functions may be utilized to produce a wide variety of information requested by the user. The analytical data can be generated from bid data related to a single project, multiple projects, multiple vendors or multiple buyers, and it can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, aggregate views, estimation views, statistical views, project performance views or any combination of thereof. The analytical data may be utilized by the user for a variety of purposes, including assessing individual bids, assessing vendor performance, assessing spending or income, assessing inflation within an industry, producing industry trend information, etc.
Once the requisite project performance data is identified and retrieved, the aggregate project performance data is generated (step 4840). In generating the aggregate project performance data, various arithmetic and/or statistical analysis operations may be utilized. For example, the system can compute a variety of information related to projects, such as the percentage of projects that are on-time or under-budget, etc. The aggregate project performance data can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, estimation views or statistical views. The aggregate project performance data may be utilized by the user for a variety of purposes, including assessing the individual performance of a vendor relative to other vendors, assessing past, present or future spending or income, assessing inflation within an industry, producing industry trend information, etc.
Once the requisite project performance data is identified and retrieved, statistical project performance data is calculated for individual projects (step 4870) using various arithmetic and/or statistical analysis operations. The statistical analysis can compute a variety of information about a project, such as average monthly cost, average expenditure, percentage of total cost for various components or aspects of the project, etc. Thereafter, the individual statistical data is aggregated to generate aggregate statistical project performance data (step 4880). The aggregate statistical project performance data can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, estimation views, etc. By aggregating the statistical data across multiple projects being performed by vendors, the buyer may get an overall view of the projects being performed to assist in assessing the projects as a whole.
Once the requisite transactional data is identified and retrieved, the analytical data is generated from one or more components of the transactional data (e.g., bid data, project tracking parameters and/or project performance data) (step 4920). In generating the analytical data, various mathematical and statistical functions may be utilized to produce a wide variety of information requested by the user. The analytical data can be generated from transactional data related to a single project, multiple projects, multiple vendors or multiple buyers, and it can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, aggregate views, estimation views, statistical views, project performance views or any combination of thereof. The analytical data may be graphically displayed to assist the user in analyzing projects or industry trends.
Upon award of the project, the project tracking parameters for the project related to the bid are received (step 4965) and stored as further transactional data (step 4970). During the performance of the project, various project performance data related to the project are received (step 4975) and stored as further transactional data (step 4980). Once the transactional data has been received and stored, a subsequent request for analytical data as a function of the transactional data is received (step 4985). The request may be submitted as a search and/or sort request by the user to select particular or general types of transactional data as collected by the system. In addition, the request may include one or more filters to narrow the amount of transactional data within the selected types of transactional data that is used in the generation of the analytical data.
Once the requisite transactional data is identified and retrieved, the analytical data is generated from one or more components of the transactional data (e.g., bid data, project tracking parameters and/or project performance data) (step 4990). In generating the analytical data, various mathematical and statistical functions may be utilized to produce a wide variety of information requested by the user. The analytical data can be generated from transactional data related to a single project, multiple projects, multiple vendors or multiple buyers, and it can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, aggregate views, estimation views, statistical views, project performance views or any combination of thereof. The analytical data may be graphically displayed to assist the user in analyzing projects or industry trends.
Initially, the industry analysis process begins when a request for industry analytical data is received by the system (e.g., the administrative server 125 in
Once the requisite transactional data is identified and retrieved, industry analytical data can be generated as a function of the transactional data (step 5020). In generating the industry analytical data, mathematical and/or statistical functions may be utilized to produce a variety of industry analytical data that the user is interested in viewing. The industry analytical data can be presented to the user in a variety of reporting views. For example, exemplary reporting views include summary views, aggregate views, estimation views, statistical views, project performance views or any combination of thereof. The analytical data may be graphically displayed to assist the user in analyzing projects or industry trends.
Based on the request and any filters, the system accesses the batch transactional data to identify and retrieve the particular batch transactional data needed to perform the requested industry analysis (step 5080). Thereafter, the industry analytical data is generated from the identified batch transactional data (step 5090). In generating the industry analytical data, various mathematical and statistical functions may be utilized to produce a wide variety of information requested by the user. The industry analytical data can be presented to the user in a variety of reporting views (step 5095). For example, exemplary reporting views include summary views, aggregate views, estimation views, statistical views, project performance views or any combination of thereof. The industry analytical data may be graphically displayed to assist the user in analyzing projects or industry trends.
As discussed above, the analytical data request submitted by the user can include one or more filters to tailor the types of transactional data utilized in the analytical process. Referring now to
Exemplary steps for retrieving filtered transactional data from the database are shown in
Screen shots of exemplary web pages presenting reporting views containing analytical data are shown in
Examples of reporting views 360 within the financial reporting type 350 are invoice details reporting views, commodity summary reporting views, future spend modeling/budgeting reporting views and completed projects financial analysis reporting views. Examples of reporting views 360 within the project reporting type 350 are project performance reporting views, plan upcoming phasing and deliverable activity reporting views and project management planning module reporting views. Examples of reporting views 360 within the vendor/human capital reporting type 350 are financial reporting views, operational reporting views and supply chain reporting views. However, it should be understood that the present invention is not limited to the specific reporting types 350 and reporting views 360 shown in
Examples of specific types of reporting views 360 are shown in
As another example, as shown in
As can be seen on the bottom of the web page shown in
As can be seen in the web page 61 shown in
As an example, if a user clicked on the link to summarize the estimated future project spending by project sector and family, a reporting view 360 similar to the one shown in
Three different examples of estimated future project sector/family spending are shown in
As an example, if a user clicked on the link to summarize the project performance analytical data by project management ownership type, a reporting view 360 similar to the one shown in
As another example, if a user clicked on the link on the bottom of the web page 61 in
As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications. Accordingly, the scope of patented subject matter should not be limited to any of the specific exemplary teachings discussed, but is instead defined by the following claims.
This patent application is a continuation of U.S. patent application Ser. No. 10/412,096, filed on Apr. 10, 2003 now U.S. Pat. No. 7,925,568. U.S. patent application Ser. No. 10/412,096 is a Continuation-in-Part of U.S. patent application Ser. No. 10/262,487, filed on Sep. 30, 2002, which claims priority from U.S. Provisional Application No. 60/371,488, filed on Apr. 10, 2002. U.S. patent application Ser. No. 10/412,096 claims priority from U.S. Provisional Application No. 60/371,488. U.S. Provisional Application No. 60/371,488, U.S. patent application Ser. No. 10/262,487, and U.S. patent application Ser. No. 10/412,096 are hereby incorporated by reference in their entirety herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4799156 | Shavit et al. | Jan 1989 | A |
| 4937743 | Rassman et al. | Jun 1990 | A |
| 4992940 | Dworkin | Feb 1991 | A |
| 5117353 | Stipanovich et al. | May 1992 | A |
| 5164897 | Clark et al. | Nov 1992 | A |
| 5291397 | Powell | Mar 1994 | A |
| 5381332 | Wood | Jan 1995 | A |
| 5416694 | Parrish et al. | May 1995 | A |
| 5493490 | Johnson | Feb 1996 | A |
| 5592375 | Salmon et al. | Jan 1997 | A |
| 5600554 | Williams | Feb 1997 | A |
| 5664115 | Fraser | Sep 1997 | A |
| 5715402 | Popolo | Feb 1998 | A |
| 5740421 | Palmon | Apr 1998 | A |
| 5758328 | Giovannoli | May 1998 | A |
| 5794212 | Mistr, Jr. | Aug 1998 | A |
| 5802493 | Sheflott et al. | Sep 1998 | A |
| 5842178 | Giovannoli | Nov 1998 | A |
| 5862223 | Walker et al. | Jan 1999 | A |
| 5907490 | Oliver | May 1999 | A |
| 5913202 | Motoyama | Jun 1999 | A |
| 5915086 | Buzsaki et al. | Jun 1999 | A |
| 5960407 | Vivona | Sep 1999 | A |
| 5970475 | Barnes et al. | Oct 1999 | A |
| 5978768 | McGovern et al. | Nov 1999 | A |
| 5987464 | Schneider | Nov 1999 | A |
| 5991735 | Gerace | Nov 1999 | A |
| 5995951 | Ferguson | Nov 1999 | A |
| 6014644 | Erickson | Jan 2000 | A |
| 6038547 | Casto | Mar 2000 | A |
| 6041303 | Mathews | Mar 2000 | A |
| 6049776 | Donnelly et al. | Apr 2000 | A |
| 6058373 | Blinn et al. | May 2000 | A |
| 6058379 | Odom et al. | May 2000 | A |
| 6070143 | Barney et al. | May 2000 | A |
| 6088678 | Shannon | Jul 2000 | A |
| 6092050 | Lungren et al. | Jul 2000 | A |
| 6092197 | Coueignoux | Jul 2000 | A |
| 6112189 | Rickard et al. | Aug 2000 | A |
| 6115642 | Brown et al. | Sep 2000 | A |
| 6131087 | Luke et al. | Oct 2000 | A |
| 6141653 | Conklin et al. | Oct 2000 | A |
| 6157808 | Hollingsworth | Dec 2000 | A |
| 6158044 | Tibbetts | Dec 2000 | A |
| 6161099 | Harrington et al. | Dec 2000 | A |
| 6167385 | Hartley-Urquhart | Dec 2000 | A |
| 6189003 | Leal | Feb 2001 | B1 |
| 6199050 | Alaia et al. | Mar 2001 | B1 |
| 6213780 | Ho et al. | Apr 2001 | B1 |
| 6266659 | Nadkarni | Jul 2001 | B1 |
| 6272467 | Durand et al. | Aug 2001 | B1 |
| 6275812 | Haq et al. | Aug 2001 | B1 |
| 6289340 | Puram et al. | Sep 2001 | B1 |
| 6302695 | Rtischev et al. | Oct 2001 | B1 |
| 6324522 | Peterson et al. | Nov 2001 | B2 |
| 6349238 | Gabbita et al. | Feb 2002 | B1 |
| 6356909 | Spencer | Mar 2002 | B1 |
| 6370510 | McGovern et al. | Apr 2002 | B1 |
| 6385620 | Kurzius et al. | May 2002 | B1 |
| 6408337 | Dietz et al. | Jun 2002 | B1 |
| 6442528 | Notani et al. | Aug 2002 | B1 |
| 6480857 | Chandler | Nov 2002 | B1 |
| 6529909 | Bowman-Amuah | Mar 2003 | B1 |
| 6556976 | Callen | Apr 2003 | B1 |
| 6647300 | Balasubramanian et al. | Nov 2003 | B1 |
| 6658400 | Perell et al. | Dec 2003 | B2 |
| 6662194 | Joao | Dec 2003 | B1 |
| 7054821 | Rosenthal et al. | May 2006 | B1 |
| 7089203 | Crookshanks | Aug 2006 | B1 |
| 7103567 | Smukowski | Sep 2006 | B2 |
| 7107268 | Zawadzki et al. | Sep 2006 | B1 |
| 7275039 | Setteducati | Sep 2007 | B2 |
| 7305392 | Abrams et al. | Dec 2007 | B1 |
| 7386475 | Parasnis et al. | Jun 2008 | B2 |
| 7430523 | Khalidi | Sep 2008 | B1 |
| 7437304 | Barnard et al. | Oct 2008 | B2 |
| 7451106 | Gindlesperger | Nov 2008 | B1 |
| 7457764 | Bullock et al. | Nov 2008 | B1 |
| 7523045 | Walker et al. | Apr 2009 | B1 |
| 7533033 | Unite et al. | May 2009 | B1 |
| 7653583 | Leeb et al. | Jan 2010 | B1 |
| 7805382 | Rosen et al. | Sep 2010 | B2 |
| 20010044768 | Wares | Nov 2001 | A1 |
| 20010051913 | Vashistha et al. | Dec 2001 | A1 |
| 20020002479 | Almog et al. | Jan 2002 | A1 |
| 20020046147 | Livesay et al. | Apr 2002 | A1 |
| 20020055870 | Thomas | May 2002 | A1 |
| 20020072946 | Richardson | Jun 2002 | A1 |
| 20020073082 | Duvillier et al. | Jun 2002 | A1 |
| 20020087382 | Tiburcio | Jul 2002 | A1 |
| 20020103687 | Kipling | Aug 2002 | A1 |
| 20020152133 | King et al. | Oct 2002 | A1 |
| 20020156668 | Morrow et al. | Oct 2002 | A1 |
| 20020161619 | Ham et al. | Oct 2002 | A1 |
| 20020198766 | Magrino et al. | Dec 2002 | A1 |
| 20020198818 | Scott et al. | Dec 2002 | A1 |
| 20030004850 | Li et al. | Jan 2003 | A1 |
| 20030018481 | Zhou et al. | Jan 2003 | A1 |
| 20030037032 | Neece et al. | Feb 2003 | A1 |
| 20030055694 | Menninger | Mar 2003 | A1 |
| 20030055754 | Sullivan | Mar 2003 | A1 |
| 20030083910 | Sayal et al. | May 2003 | A1 |
| 20030101114 | Delapass et al. | May 2003 | A1 |
| 20030101127 | Cornelius | May 2003 | A1 |
| 20030135401 | Parr | Jul 2003 | A1 |
| 20030145006 | Dalfsen et al. | Jul 2003 | A1 |
| 20030177051 | Driscoll et al. | Sep 2003 | A1 |
| 20030200150 | Westcott et al. | Oct 2003 | A1 |
| 20030200168 | Cullen, III et al. | Oct 2003 | A1 |
| 20030204439 | Cullen, III | Oct 2003 | A1 |
| 20030208434 | Posner | Nov 2003 | A1 |
| 20030212604 | Cullen, III | Nov 2003 | A1 |
| 20030216986 | Hassan | Nov 2003 | A1 |
| 20040030566 | Brooks Rix | Feb 2004 | A1 |
| 20040030590 | Swan et al. | Feb 2004 | A1 |
| 20040039681 | Cullen, III et al. | Feb 2004 | A1 |
| 20040068728 | Blevins | Apr 2004 | A1 |
| 20040093583 | McAnaney et al. | May 2004 | A1 |
| 20040107125 | Guheen et al. | Jun 2004 | A1 |
| 20040107405 | Schein | Jun 2004 | A1 |
| 20040158513 | Musacchio | Aug 2004 | A1 |
| 20040186852 | Rosen | Sep 2004 | A1 |
| 20040205519 | Chapel et al. | Oct 2004 | A1 |
| 20040210490 | Almstead et al. | Oct 2004 | A1 |
| 20040210510 | Cullen, III et al. | Oct 2004 | A1 |
| 20040215467 | Coffman et al. | Oct 2004 | A1 |
| 20040236598 | Thomsen | Nov 2004 | A1 |
| 20040260601 | Brief | Dec 2004 | A1 |
| 20040267606 | Brishke et al. | Dec 2004 | A1 |
| 20050114829 | Robin | May 2005 | A1 |
| 20050120039 | Amys et al. | Jun 2005 | A1 |
| 20050144129 | Coolman et al. | Jun 2005 | A1 |
| 20050262008 | Cullen, III et al. | Nov 2005 | A1 |
| 20050288993 | Weng et al. | Dec 2005 | A1 |
| 20060173775 | Cullen et al. | Aug 2006 | A1 |
| 20060190391 | Cullen et al. | Aug 2006 | A1 |
| 20060259476 | Kadayam et al. | Nov 2006 | A1 |
| 20070124196 | Brief et al. | May 2007 | A1 |
| 20080004890 | Hargroder | Jan 2008 | A1 |
| 20090248482 | Knyphausen et al. | Oct 2009 | A1 |
| 20100241482 | Knyphausen et al. | Sep 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 1195676 | Apr 2002 | EP |
| 2002-041835 | Feb 2002 | JP |
| 2004-086757 | Mar 2004 | JP |
| 2165679 | Apr 2001 | RU |
| WO-0033187 | Jun 2000 | WO |
| WO-0050970 | Aug 2000 | WO |
| WO-0114962 | Mar 2001 | WO |
| WO-0148656 | Jul 2001 | WO |
| WO-0208868 | Jan 2002 | WO |
| WO-0225544 | Mar 2002 | WO |
| WO-0241270 | May 2002 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20110282714 A1 | Nov 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60371488 | Apr 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10412096 | Apr 2003 | US |
| Child | 13017760 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10262487 | Sep 2002 | US |
| Child | 10412096 | US |
