US 7,665,127 B1Grant
System and method for providing access to protected services
Issue Date:2010-02-16
•25 Claims
•3 Drawing Sheets
Abstract
A method and a system for allowing computer-executable applications to efficiently and securely obtain credentials required to access data from a protected Web service utilizes an ID token. The ID token is associated with an IP address of a user's computer, and is validated before providing the credentials to the user's computer.
Metadata
Assignee
- JP Morgan Chase Bank
Inventors
- Srinivasan N. Rao
- Lioun Chen
Application Information
Application Number:US 11/052,677
Filing Date:2005-02-07
Priority Date:2004-06-30
Art Unit:2435
Classifications
IPC:
G06F7/04
Patent Drawings (3 sheets)
Description
Cross-Reference to Related Application
[0001] This application claims the benefit of U.S. Provisional Application No. 60/584,234, filed Jun. 30, 2004, the entire disclosure of which is incorporated herein by reference.
Field of the Invention
[0002] The present invention relates to a system and method for providing access to a protected Web service, such that a plurality of requests for application data may be submitted without having to re-authenticate each request.
Background of the Invention
[0003] The use of many conventional computer-executable applications often requires the applications to obtain data from protected Web services. A “protected Web service” involves a computer located on a web-based network, such as the Internet, which requires the authentication and validation of a user's identity prior to permitting access to data stored on the computer. Exemplary applications that require this type of repeated data acquisition include, but are not limited to, spreadsheet applications, such as Microsoft® Excel; word processing applications, such as Microsoft® Word or Corel WordPerfect®; database applications, such as Microsoft® Access; and presentation applications, such as Microsoft® PowerPoint. For example, these applications may require access to application data that includes, but is not limited to, logical expressions, equations, dates, numbers, characters and/or any information suitable for incorporation into or use by the application.
[0004] Often, the application data sought by the user is dynamic, and use of the application requires repeated requests for access to this changing data. Take, for example, the case where the application is a spreadsheet application having a number of equations embedded within the spreadsheet, each having variables representing source data stored on an application server. In the event the source data and/or equations change, these changes must be communicated to the spreadsheet for incorporation therein, often for a large number of users. Effectuating this type of universal change to the application is cumbersome and difficult when done on an individual user basis.
[0005] To alleviate problems associated with the distribution and management of applications and changes to application data, the applications and the application data may be stored on a central computer, known in the art as an “application server.” Typically, the application server is accessible by users through a Web browser via a conventional computer network using any known Web-based protocol.
[0006] Although housing an application and application data on an application server allows for efficient control and distribution of the application and the application data, providing the application to users via a computer network introduces a number of security-related risks and problems. As such, access to the application server must be monitored to prevent access by unauthorized users. In order for a user to access the application server, which houses a desired application file, the user must first be authenticated. Typically, the user is authenticated by providing authenticating information, such as a username and a passcode, which is verified by a known authentication system.
[0007] Conventional systems require the re-authentication of a user each time a request for data is made. However, re-authenticating the user for each request is problematic for an application that requires frequent and repeated exchanges between the application and the application server. For example, an application that imports real-time data must access the application server at frequent periodic intervals, forcing the user to respond to numerous prompts for his or her authenticating information. These incessant interruptions distract the user from his or her intended purpose, leading directly to a decrease in productivity. Accordingly, there is a need in the art for a method and a system that allows a user to access an application and/or application data stored for a protected Web service.
Summary of the Invention
[0008] The present invention relates to a system and a method that enables a computer-executable application to efficiently and securely obtain credentials required to request and access data from a protected Web service without having to re-authenticate the user for each request. Access to contents of the protected Web service, or application server, is protected by a credential validation system. A secure link between an application and the application server is established using a one-time authentication of the user and an authentication of the application itself.
[0009] According to an embodiment of the invention, an authenticated user's request for an application is transmitted with validated credentials and other request information (e.g., user IP address, time stamp) to an application server. The application server generates a unique identification (ID) token and links the ID token with the application.
[0010] The application server also associates the ID token, the user's authentication credentials, and other request information, and stores this association in a computer-readable memory communicatively connected to the application server.
[0011] The requested application and associated ID token are sent to the user for execution (i.e., opening or downloading). Upon execution of the application, the ID token is extracted from the application and sent back to the application server as a request for the credentials. The application server uses the ID token to look up the associated credentials stored in the computer-readable memory. If located, the application server further checks to ensure that the IP address from which the request for credentials originated matches the IP address associated with the ID token stored in the memory. If the information matches, the application server removes from memory the stored ID token, IP address, time stamp, and credentials, and sends the credentials to the application operating locally on the user's computer.
[0012] Having received the credentials, the application is authenticated. Advantageously, a secure link is established between the application and the application server such that the application may make multiple requests for data using the authenticated credentials without the need for the user to supply authenticating information for each request.
Brief Description of the Figures
[0013] The present invention will be more readily understood from the detailed description of the preferred embodiment(s) presented below considered in conjunction with the attached drawings, of which:
[0014] FIG. 1 is a schematic diagram of a system for providing a secure link between an application stored locally on a user computer and an application server, according to an embodiment of the present invention; and
[0015] FIG. 2 is a schematic diagram of an application validation system, according to an embodiment of the present invention.
[0016] It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.
Detailed Description of the Invention
[0017] The present invention relates to a method and a system for allowing a computer-executable application stored locally on a user's computer to transmit one or more requests for application data to an application server during a session, without having to re-authenticate the user for each request. Computer-executable applications or application files, collectively referred to as “applications,” include, but are not limited to spreadsheet applications, such as Microsoft® Excel; word processing applications, such as Microsoft® Word or Corel WordPerfect®; database applications, such as Microsoft® Access; and presentation applications, such as Microsoft® PowerPoint. Although an exemplary description of the invention is presented in the context of a spreadsheet application, one skilled in the art will appreciate that the invention is not limited to any particular application, and that the invention applies to other types of applications known in the art.
[0018] The term “application data” is intended to include, but is not limited to, any information or data that may be used by, incorporated in, or embedded in an application. For example, application data may include logical expressions, equations, dates, numbers, characters, or any other information suitable for use by the application.
[0019] The term “computer” is intended to include any data processing device, such as a desktop computer, a laptop computer, a mainframe computer, a server, a personal digital assistant, or any other device able to process data.
[0020] The term “session” is generally defined as a lasting connection between a user's computer and another computer. Typically, the start of the session begins when the user connects with the other computer and ends when the connection is terminated. For example, a session may be a Web-based HTTP exchange between a browser operating on a user's computer and a computer running a Web server program (a “Web Server”) or an application server.
[0021] The manner in which the present invention provides a secure link between an application and an application server, such that the application may transmit one or more requests for application data to the application server during a session without having to re-authenticate each request, is described in detail with respect to FIG. 1 . FIG. 1 illustrates an exemplary system 1 for providing access to an application and application data residing on an application server, referred to as an Application Server 50, which is protected by a communicatively connected credential validation system, referred to as a Credential Validator 40. Optionally, the Credential Validator 40 is part of a Web Server 70, which is a computer that serves as an interface between the Application Server 50 and a User's Computer 5. However, one of ordinary skill in the art will appreciate that alternative implementations may be used.
[0022] The term “communicatively connected” is intended to include any type of connection, whether wired or wireless, in which data may be communicated. The connection may be between devices within a single computer or between devices on separate computers.
[0023] The User's Computer 5 is communicatively connected to the Credential Validator 40 via, for example, any known Web-based network, such as the Internet. Preferably, the User's Computer 5 interfaces with the network via a Web browser 10 using, for example, any known Web-based protocol, including but not limited to HyperText Transmission Protocol (“HTTP”) or HyperText Transmission Protocol, Secure (“HTTPS”). One having ordinary skill in the art will appreciate that any known Web browser may be used, including but not limited to Microsoft® Internet Explorer.
[0024] Each component of the system 1 depicted in FIG. 1 is represented on the network by a unique Uniform Resource Locator (“URL”) which specifies the address or location of the component on the network. Using the Web browser 10, a user addresses his or her request to the URL of the Application Server 50, which maintains the services sought by the user. Although this embodiment of the invention is described in the context of using URLs to identify the locations of the components depicted in FIG. 1 , one skilled in the art will appreciate that other addressing conventions may be used and that the invention is not limited to any one particular addressing convention.
[0025] The Credential Validator 40, communicatively connected between the User's Computer 5 and the Application Server 50, checks incoming communications received from the User's Computer 5 for valid user-authentication credentials, thus protecting the Application Server 50 from requests that do not include valid credentials. For this reason, the Application Server 50 provides what is referred to as a “protected Web service.” The Credential Validator 40 may be any known credential validation system able to check and validate user-authentication credentials. Preferably, the Credential Validator 40 is an Apache ReverseProxy system.
[0026] In the event the Credential Validator 40 determines that the user has not been properly authenticated, the Credential Validator 40 redirects the user to a User Authentication System 20, which is communicatively connected to the User's Computer 5. Optionally, as shown in FIG. 1 , a Web Server 30 may be communicatively connected between the User's Computer 5 and the User Authentication System 20 to allow the communication therebetween to use a Web-based protocol.
[0027] The User Authentication System 20 authenticates the user by verifying authentication information provided by the user. Typically, the authentication information includes, but is not limited to, a username and a passcode. Preferably, the User Authentication System 20 generates credentials that expire within a finite period, so that the credentials, once validated, cannot be used indefinitely. For example, the credentials may be time limited such that a session automatically terminates after passage of a fixed period of time. One of ordinary skill in the art will appreciate that any authentication system known in the art is suitable for use in the present invention. Preferably, the user authentication system is a single-sign-on system.
[0028] Upon authentication of the user, the User Authentication System 20 provides the user with the credentials for use during the session. Once the user has been properly authenticated, communications originating from the User's Computer 5 having these credentials will be validated by the Credential Validator 40 and forwarded to the Application Server 50.
[0029] The Application Server 50 may be a computer that stores and manages the services sought by the user. The Application Server 50 is further communicatively connected to a computer-readable memory, referred to as a Memory 55. The term “computer-readable memory” is intended to include any computer-accessible data storage device, whether volatile or nonvolatile, electronic, optical, or otherwise, including but not limited to floppy disks, hard disks, CD-ROMs, DVDs, flash memories, ROMs, and RAMs.
[0030] Although the Memory 55 is shown in FIG. 1 as residing on the Application Server 50, one of ordinary skill in the art will appreciate that the Memory 55 may be located remotely with respect to the Application Server 50. Further, one of ordinary skill in the art will appreciate that although the Credential Validator 40, the User Authentication System 20, the Application Server 50, and the Memory 55, are shown in FIG. 1 as physically distinct components, they may be located within a single computer or within different computers that are connected via a network.
[0031] The system 1 depicted in FIG. 1 allows the User's Computer 5 to submit one or more requests for services stored and managed by the Application Server 50 without having to re-authenticate each request according to the method described in detail below with respect to FIG. 2 .
[0032] FIG. 2 provides a schematic depiction of the application authentication method and system according to the present invention. It is to be understood that the schematic representation of the system provided in FIG. 2 is exemplary in nature and alternative arrangements are within the scope of the present invention.
[0033] Referring to FIG. 2 , in step 201, a request for an application is transmitted by the user from the User's Computer 5 to the Credit Validator 40. The application request may be transmitted with other request information including, but not limited to the user's IP address and a time stamp. The time stamp provides temporal information related to the session and/or request, which may include, for example, the time when the user initiated the current session and session/request expiration parameters. The Credential Validator 40 checks the application request for valid user-authentication credentials. In the event the Credential Validator 40 determines that the request does not include valid credentials, the Credential Validator 40 redirects the user to the User Authentication System 20, as described above.
[0034] In step 202, after validating the user's credentials, the Credential Validator 40 forwards the authenticated user's request, credentials, and request information to the Application Server 50. In step 203, upon receipt of the application request, request information, and credentials, the Application Server 50 performs a number of functions. First, for each application request received, the Application Server 50 creates a unique Identification (ID) Token. The ID token may be a numeric or alphanumeric identifier of any length, which may be randomly generated. Next, the Application Server 50 associates the credentials and the request information (IP address and time stamp) with the ID token and stores this association in the Memory 55. Optionally, this association may be stored in tabular form.
[0035] In step 204, the Application Server 50 associates the ID token with the requested application 60 and sends the ID token and the application 60 to the User's Computer 5. Preferably, the ID token is associated with the application 60 by changing the name of the file to the ID token. For example, if the application 60 is an Excel spreadsheet, the ID token may be associated with the spreadsheet by changing the spreadsheet name to “ID TOKEN.xls.” Alternatively, the ID token may be associated with the application 60 by embedding the ID token in the application 60 itself. Other suitable methods of associating the ID token and the application 60 may be used according to the method and the system of the current invention.
[0036] Next, the application 60 is executed by the user. As used herein, the term “execute” refers to opening, downloading, detaching, saving, or any like operation known in the art. In step 205, upon execution, the application 60 is programmed to automatically extract the ID token and send the ID token back to the Application Server 50 as a request for credentials. The request for credentials includes the ID token extracted from the application 60 and the IP address of the User's Computer 5.
[0037] The request for credentials is received by the Credential Validator 40 and automatically forwarded to the Application Server 50. In step 206, the Application Server 50 looks up the credentials associated with the ID token sent with the request for credentials in the Memory 55. If found, the Application Server 50 verifies that the IP address from which the request for credentials originated matches the IP address associated with the ID token stored in the Memory 55. Optionally, the Application Server 50 checks the time stamp to ensure that the session has not expired. This time stamp check is intended to detect stale requests for credentials or stale data. The time stamp parameters may be customized according to individual system requirements.
[0038] In the event that either the ID token sent via the request for credentials is not found in the Memory 55, the IP addresses do not match, or the session time has expired, an error state is entered. The error state may include sending an error message back to the IP address from which the request originated.
[0039] In step 207, if the Application Server 50 successfully verifies the information as described above in connection with step 206, the credentials are sent to the User's Computer 5. By providing the credentials to the application 60, the application has been authenticated. Further, once the information is verified, the Application Server 50 removes the association between the ID token and the credentials from the Memory 55. This is done to protect against an unauthorized attempt to submit a repeat request for credentials.
[0040] Advantageously, matching the IP address in the request for credentials and the IP address stored in the Memory 55 prevents “sniffing,” which is known in the art as an unauthorized learning of a valid ID Token and an attempted use of that ID token to engage in communications using the ID token from an unauthorized IP address. If the ID token has been sniffed, the Application Server 50 will detect, while matching the ID token stored in the Memory 55, that the ID token does not originate from the IP address associated with the ID token in the Memory 55. As such, the Application Server 50 will deny the corresponding request and enter the error state. In addition, comparing the IP addresses prevents access to application data by those persons who have not been validated but who receive the application 60 via email from a validated user.
[0041] Once the application 60 has been authenticated by receiving the validated credentials, the Application Server 50 views and treats the application 60 as it would a standard Web browser. This means that once the validated credentials are stored locally by the User's Computer 5, requests for application data may be submitted by the application 60 using the HTTPS protocol, by use of a cookie. In step 208, the Application Server 50 and the application 60 may now repeatedly interact with one another by passing the validated credentials back and forth as a cookie during data requests and responses. Each request from the application 60 includes the credentials and is validated by the Credential Validator 40 prior to forwarding onto the Application Server 50.
[0042] Preferably, the above described method and system may be used for any application that may be stored on a computer-accessible computer by one or more users via a Web-based network and that may be modified (i.e., operatively adjusted via code or logic added to the application) such that, upon execution, the application may extract the ID Token provided by the Application Server 50 and forward the extracted ID token to the Application Server 50.
[0043] Although the present invention has been described in considerable detail with reference to certain preferred embodiments and versions, other versions and embodiments are possible. Therefore, the scope of the appended claims are not limited to the description of the versions and embodiments expressly disclosed herein. The references and disclosure provided in the “Background of the Invention” section are not admitted to be prior art with respect to the disclosure provided in the current application.
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
What is claimed is:
1. A method for providing access to application data stored on a protected resource computer, the method comprising the steps of:
validating a request for an application received from a user computer wherein the request includes authenticated credentials and an IP address of the user computer;
generating an identification token for each validated request;
storing an association between the identification token, the credentials, and the IP address in a computer-readable memory communicatively connected to the protected resource computer;
sending the requested application and the identification token to the user computer, wherein the requested application is stored locally on the user computer;
receiving a request for credentials from the requested application stored locally on the user computer, wherein the request for credentials includes an identification token and an IP address, and wherein the request for credentials is generated upon execution of the requested application;
verifying that the identification token and the IP address received from the requested application match the identification token and the IP address stored in the computer-readable memory; and
sending the credentials to the requested application stored locally on the user computer, wherein the credentials allow the requested application to submit one or more requests for application data stored on the protected resource computer without requiring the user to input authentication information for each request.
2. The method of claim 1, wherein the requested application includes a Microsoft® Excel file.
3. The method of claim 1, wherein the requested application is sent to the user with the identification token embedded within the requested application.
4. The method of claim 1, wherein the requested application is sent to the user with the identification token provided as a filename of the requested application.
5. The method of claim 1, wherein the authenticated credentials are provided to the user computer by a user authentication system.
6. The method of claim 1, wherein the request for the application further includes a time stamp.
7. The method of claim 6, further comprising the step of using the time stamp to determine whether the request for the application has expired.
8. The method of claim 1, wherein the identification token is randomly generated.
9. The method of claim 1, wherein the association is removed from the computer-readable memory following verification of the identification token.
10. The method of claim 1, wherein the one or more requests for application data are submitted as a cookie.
11. A computer-implemented method for providing access to services stored on a protected resource computer, the method comprising the steps of:
validating a request for an application received from a user computer wherein the request includes authenticated credentials and an IP address of the user computer;
generating an identification token for each validated request;
storing an association between the identification token, the credentials, and the IP address in a computer-readable memory communicatively connected to the protected resource computer;
sending the requested application and the identification token to the user computer, wherein the requested application is stored locally on the user computer;
receiving a request for credentials from the requested application stored locally on the user computer, wherein the request for credentials includes an identification token and an IP address, and wherein the request for credentials is generated upon execution of the requested application;
verifying that the identification token and the IP address received from the requested application match the identification token and the IP address stored in the computer-readable memory; and
sending the credentials to the requested application stored locally on the user computer, wherein the credentials allow the requested application to submit one or more requests for application data stored on the protected resource computer without requiring the user to input authentication information for each request.
12. A system for providing access to application data stored on a protected resource computer, the system comprising:
a credential validator communicatively connected to a user computer, wherein the credential validator is configured to validate a request for an application received from the user computer, and wherein the request includes authenticated credentials and an IP address of the user computer; and
an application server communicatively connected to the credential validator, wherein the application server is configured to:
generate an identification token for each validated request,
store an association between the identification token, the credentials, and the IP address in a computer-readable memory communicatively connected to the application server,
send the requested application and the identification token to the user computer, wherein the requested application is stored locally on the user computer,
receive a request for credentials from the requested application stored locally on the user computer, wherein the request for credentials includes an identification token and an IP address, and wherein the request for credentials is generated upon execution of the requested application,
verify that the identification token and the IP address received from the requested application match the identification token and the IP address stored in the computer-readable memory, and
send the credentials to the requested application stored locally on the user computer, wherein the credentials allow the requested application to submit one or more requests for application data stored on the protected resource computer without requiring a user to input authentication information for each request.
13. The system of claim 12, wherein the requested application includes a Microsoft® Excel file.
14. The system of claim 12, wherein the requested application is sent to the user computer with the identification token embedded within the requested application.
15. The system of claim 12, wherein the requested application is sent to the user computer with the identification token provided as a filename of the requested application.
16. The system of claim 12, wherein the authenticated credentials are provided to the user computer by a user authentication system.
17. The system of claim 12, wherein the request for application further includes a time stamp.
18. The system of claim 17, wherein the time stamp is used to determine whether the request for the application has expired.
19. The system of claim 12, wherein the identification token is randomly generated.
20. The system of claim 12, wherein the association is removed from the memory following verification of the identification token.
21. The system of claim 12, wherein the one or more requests for application data are submitted as a cookie.
22. The system of claim 12, further comprising a user authentication system for providing the authenticated credentials.
23. The system of claim 12, wherein the user computer communicates with the credential validator using HyperText Transmission Protocol.
24. The system of claim 12, wherein the user computer communicates with the credential validator using HyperText Transmission Protocol, Secure.
25. A computer-readable storage medium storing computer code for providing access to application data stored on a protected resource computer, wherein the computer code comprises:
code for validating a request for an application received from a user computer, wherein the request includes authenticated credentials and an IP address of the user computer;
code for generating an identification token for each validated request;
code for storing an association between the identification token, the credentials, and the IP address in a computer-readable memory communicatively connected to the protected resource computer;
code for sending the requested application and the identification token to the user computer, wherein the requested application is stored locally on the user computer;
code for receiving a request for credentials from the requested application stored locally on the user computer, wherein the request for credentials includes an identification token and an IP address, and wherein the request for credentials is generated upon execution of the requested application;
code for verifying that the identification token and the IP address received from the requested application match the identification token and the IP address stored in the computer-readable memory; and
code for sending the credentials to the requested application stored locally on the user computer,
wherein the credentials allow the requested application to submit one or more requests for application data stored on the protected resource computer without requiring the user to input authentication information for each request.
Patent Citations (130)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4751702(A) | 1988-06-01 | Beier et al. | Applicant |
| US5027269(A) | 1991-06-01 | Grant et al. | Applicant |
| US5075881(A) | 1991-12-01 | Blomberg et al. | Applicant |
| US5313616(A) | 1994-05-01 | Cline et al. | Applicant |
| US5347518(A) | 1994-09-01 | Lee | Applicant |
| US5386551(A) | 1995-01-01 | Chikira et al. | Applicant |
| US5446895(A) | 1995-08-01 | White et al. | Applicant |
| US5539885(A) | 1996-07-01 | Ono et al. | Applicant |
| US5549117(A) | 1996-08-01 | Tacklind et al. | Applicant |
| US5563998(A) | 1996-10-01 | Yakich et al. | Applicant |
| US5566297(A) | 1996-10-01 | Devarakonda | Applicant |
| US5594863(A) | 1997-01-01 | Stiles | Applicant |
| US5630047(A) | 1997-05-01 | Wang | Applicant |
| US5630069(A) | 1997-05-01 | Flores et al. | Applicant |
| US5655074(A) | 1997-08-01 | Rauscher | Applicant |
| US5701471(A) | 1997-12-01 | Subramanyam | Applicant |
| US5712971(A) | 1998-01-01 | Stanfill et al. | Applicant |
| US5721913(A) | 1998-02-01 | Ackroff et al. | Applicant |
| US5721914(A) | 1998-02-01 | De Vries | Applicant |
| US5748878(A) | 1998-05-01 | Rees et al. | Applicant |
| US5752034(A) | 1998-05-01 | Srivastava | Applicant |
| US5758061(A) | 1998-05-01 | Plum | Applicant |
| US5768506(A) | 1998-06-01 | Randell | Applicant |
| US5781448(A) | 1998-07-01 | Nakamura et al. | Applicant |
| US5784562(A) | 1998-07-01 | Diener | Applicant |
| US5799297(A) | 1998-08-01 | Goodridge et al. | Applicant |
| US5806075(A) | 1998-09-01 | Jain et al. | Applicant |
| US5828883(A) | 1998-10-01 | Hall | Applicant |
| US5835770(A) | 1998-11-01 | Shum et al. | Applicant |
| US5842196(A) | 1998-11-01 | Agarwal et al. | Applicant |
| US5845292(A) | 1998-12-01 | Bohannon et al. | Applicant |
| US5872976(A) | 1999-02-01 | Yee et al. | Applicant |
| US5884037(A) | 1999-03-01 | Aras et al. | Applicant |
| US5903721(A) | 1999-05-01 | Sixtus | Applicant |
| US5903897(A) | 1999-05-01 | Carrier, III et al. | Applicant |
| US5920719(A) | 1999-07-01 | Sutton et al. | Applicant |
| US5937198(A) | 1999-08-01 | Nelson et al. | Applicant |
| US5960196(A) | 1999-09-01 | Carrier, III et al. | Applicant |
| US5960445(A) | 1999-09-01 | Tamori et al. | Applicant |
| US5995965(A) | 1999-11-01 | Experton | Applicant |
| US6003075(A) | 1999-12-01 | Arendt et al. | Applicant |
| US6009274(A) | 1999-12-01 | Fletcher et al. | Applicant |
| US6026237(A) | 2000-02-01 | Berry et al. | Applicant |
| US6028938(A) | 2000-02-01 | Malkin et al. | Applicant |
| US6029002(A) | 2000-02-01 | Afifi et al. | Applicant |
| US6058393(A) | 2000-05-01 | Meier et al. | Applicant |
| US6061503(A) | 2000-05-01 | Chamberlain | Applicant |
| US6061686(A) | 2000-05-01 | Gauvin et al. | Applicant |
| US6067412(A) | 2000-05-01 | Blake et al. | Applicant |
| US6073107(A) | 2000-06-01 | Minkiewicz et al. | Applicant |
| US6088700(A) | 2000-07-01 | Larsen et al. | Applicant |
| US6101601(A) | 2000-08-01 | Matthews et al. | Applicant |
| US6108673(A) | 2000-08-01 | Brandt et al. | Applicant |
| US6125390(A) | 2000-09-01 | Touboul | Applicant |
| US6128708(A) | 2000-10-01 | Fitzpatrick et al. | Applicant |
| US6138112(A) | 2000-10-01 | Slutz | Applicant |
| US6145121(A) | 2000-11-01 | Levy et al. | Applicant |
| US6167534(A) | 2000-12-01 | Straathof et al. | Applicant |
| US6175833(B1) | 2001-01-01 | West et al. | Applicant |
| US6195676(B1) | 2001-02-01 | Spix et al. | Applicant |
| US6226752(B1) | 2001-05-01 | Gupta et al. | Examiner |
| US6230319(B1) | 2001-05-01 | Britt, Jr. et al. | Applicant |
| US6237035(B1) | 2001-05-01 | Himmel et al. | Applicant |
| US6237143(B1) | 2001-05-01 | Fontana et al. | Applicant |
| US6243862(B1) | 2001-06-01 | Lebow | Applicant |
| US6247029(B1) | 2001-06-01 | Kelley et al. | Applicant |
| US6249877(B1) | 2001-06-01 | Kawakami et al. | Applicant |
| US6269479(B1) | 2001-07-01 | Puram | Applicant |
| US6279039(B1) | 2001-08-01 | Bhat et al. | Applicant |
| US6301701(B1) | 2001-10-01 | Walker et al. | Applicant |
| US6311327(B1) | 2001-10-01 | O'Brien et al. | Applicant |
| US6338138(B1) | 2002-01-01 | Raduchel et al. | Examiner |
| US6363499(B1) | 2002-03-01 | Delo et al. | Applicant |
| US6363524(B1) | 2002-03-01 | Loy | Applicant |
| US6405250(B1) | 2002-06-01 | Lin et al. | Applicant |
| US6405364(B1) | 2002-06-01 | Bowman-Amuah | Applicant |
| US6411910(B1) | 2002-06-01 | Eulau et al. | Applicant |
| US6424981(B1) | 2002-07-01 | Isaac et al. | Applicant |
| US6438749(B1) | 2002-08-01 | Chamberlain | Applicant |
| US6446126(B1) | 2002-09-01 | Huang et al. | Applicant |
| US6463454(B1) | 2002-10-01 | Lumelsky et al. | Applicant |
| US6466980(B1) | 2002-10-01 | Lumelsky et al. | Applicant |
| US6467052(B1) | 2002-10-01 | Kaler et al. | Applicant |
| US6470464(B2) | 2002-10-01 | Bertram et al. | Applicant |
| US6477471(B1) | 2002-11-01 | Hedstrom et al. | Applicant |
| US6502207(B1) | 2002-12-01 | Itoh et al. | Applicant |
| US6505176(B2) | 2003-01-01 | DeFrancesco, Jr. et al. | Applicant |
| US6513154(B1) | 2003-01-01 | Porterfield | Applicant |
| US6519763(B1) | 2003-02-01 | Kaufer et al. | Applicant |
| US6526443(B1) | 2003-02-01 | Goldsmith et al. | Applicant |
| US6546506(B1) | 2003-04-01 | Lewis | Applicant |
| US6560580(B1) | 2003-05-01 | Fraser et al. | Applicant |
| US6578004(B1) | 2003-06-01 | Cimral et al. | Applicant |
| US6578006(B1) | 2003-06-01 | Saito et al. | Applicant |
| US6584447(B1) | 2003-06-01 | Fox et al. | Applicant |
| US6587841(B1) | 2003-07-01 | DeFrancesco et al. | Applicant |
| US6601017(B1) | 2003-07-01 | Kennedy et al. | Applicant |
| US6601018(B1) | 2003-07-01 | Logan | Applicant |
| US6601233(B1) | 2003-07-01 | Underwood | Applicant |
| US6626953(B2) | 2003-09-01 | Johndrew et al. | Applicant |
| US6629266(B1) | 2003-09-01 | Harper et al. | Applicant |
| US6820088(B1) | 2004-11-01 | Hind et al. | Applicant |
| US6920467(B1) | 2005-07-01 | Yoshimoto | Applicant |
| US6934934(B1) | 2005-08-01 | Osborne, II et al. | Applicant |
| US7185364(B2) | 2007-02-01 | Knouse et al. | Examiner |
| US7509672(B1) | 2009-03-01 | Horwitz et al. | Examiner |
| US2002/0004912(A1) | 2002-01-01 | Fung | Applicant |
| US2002/0133593(A1) | 2002-09-01 | Johnson et al. | Applicant |
| US2002/0133757(A1) | 2002-09-01 | Bertram et al. | Applicant |
| US2002/0138571(A1) | 2002-09-01 | Trinon et al. | Applicant |
| US2002/0143929(A1) | 2002-10-01 | Maltz et al. | Applicant |
| US2002/0147961(A1) | 2002-10-01 | Charters et al. | Applicant |
| US2002/0162090(A1) | 2002-10-01 | Parnell et al. | Applicant |
| US2002/0165754(A1) | 2002-11-01 | Tang et al. | Applicant |
| US2003/0004848(A1) | 2003-01-01 | Hellerstein et al. | Applicant |
| US2003/0018952(A1) | 2003-01-01 | Roetzheim | Applicant |
| US2003/0033586(A1) | 2003-02-01 | Lawler | Applicant |
| US2003/0041000(A1) | 2003-02-01 | Zajac et al. | Applicant |
| US2003/0065644(A1) | 2003-04-01 | Horman et al. | Applicant |
| US2003/0120539(A1) | 2003-06-01 | Korium et al. | Applicant |
| US2003/0144868(A1) | 2003-07-01 | MacIntyre et al. | Applicant |
| US2003/0188290(A1) | 2003-10-01 | Corral | Applicant |
| US2003/0196190(A1) | 2003-10-01 | Ruffolo et al. | Applicant |
| US2003/0212518(A1) | 2003-11-01 | D'Alessandro et al. | Applicant |
| US2003/0225662(A1) | 2003-12-01 | Horan et al. | Applicant |
| US2003/0225663(A1) | 2003-12-01 | Horan et al. | Applicant |
| US2005/0055555(A1) | 2005-03-01 | Rao et al. | Examiner |
| US2005/0071807(A1) | 2005-03-01 | Yanai | Applicant |
| US2006/0101114(A1) | 2006-05-01 | Sandhu et al. | Examiner |
| WO1/74043 | 2001-10-01 | Applicant |
Non-Patent Literature (22)
- Hilbert; Hilbert, et al., An Approach to Large Scale Collection of Application Usage Data Over the Internet, Software Engineering 1998, Proceedings of the 1998 International Conference, Abstract, Apr. 1998.Applicant
- Quantitative Monitoring of Software Development by Time-Based and Intercheckpoint Monitoring, Software Engineering Journal, vol. 5, Iss. 1, p. 43-49, Abstract, Jan. 1990.Applicant
- Sammet; Beginning of 4.6 Software Evaluation, Tests and Measurements and RMF I/O Time Validation, Association of Computing Machinery, p. 519.Applicant
- Duggan; 2.40 General—Reviews and Abstracts, SPI Database of Software Technologies, p. 1-5, Feb. 1, 1974.Applicant
- Agostini et al.; A Light Workflow Management System Using Simple Process Models, Cooperation Technologies Laboratory, Disco-University of Milano-Bicoca, Aug. 2000.Applicant
- Muehlen; Business Process Automation and Workflow in the Financial Industry, CSK Software AG, Version 3, p. 1-37, September 10, 2003.Applicant
- Georgakopoulos et al.; An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure, Kluwer Academic Publishers, Boston, Distributed Parallel Databases, vol. 3, p. 119-153, 1995.Applicant
- OS/2EE Database Manager SQLJRA Remote Protocol, IBM Corporation, IBM TDB N10-93, p. 33-36, Jan. 1, 1993.Applicant
- Code Generation for Database Applications, IBM Corporation, p. 1-3, Mar. 1, 2002.Applicant
- Hudeponhl et al.; Integrating Metrics and Models for Software Risk Assessment, The Seventh International Symposium on Software Reliability Engineering (ISSRE '96), p. 93, Oct. 30, 1996.Applicant
- Wohlin et al.; Understanding the Sources of Software Defects: A Filtering Approach, 8th International Workshop on Program Comprehension (IWPC '00), p. 9, (Abstract), Jun. 10, 2000.Applicant
- Mohapatra et al.; Defect Prevention Through Defect Prediction: A Case Study at INFOSYS.Applicant
- Basili et al.; Understanding and Predicting the Process of Software Maintenance Releases, 18th International Conference on Software Engineering (ICSE '96), Mar. 25-29; p. 464; (Abstract).Applicant
- Betwixt: Turning Beans Into XML, Apache Software Foundation, Archived Jun. 20, 2002 at <http://web.archive.org/web/20020620000410/http://jakarta.apahce.org.commons/betwixt/>, p. 1 of 1, Nov. 13, 2005.Applicant
- Castor: Using Castor XML, Exolab Group, Archived Aug. 27, 2001 at <http://web.archive.org/web/20011019155934/http://www.castor.org/xml-framework.html>, Retrieved From the Internet on Nov. 11, 2005.Applicant
- Campione, et al.; Special Edition Using Java Tutorial, Third Edition: A Short Course on the Basics, Addison Wesley Professional ISBN: 0201-70393-9, 21 pages From Chapter 5, December 28, 2000.Applicant
- Pitt and McNiff; Java, RMI: The Remote Method Inovocation Guide, Addison Wesley Professional, ISBN: 0201-70043-3, Section 3.5, 3 Pages.Applicant
- Hamilton; Javabeans, Sun Microsystems, Chapter 8, Aug. 8, 1997.Applicant
- Reinhart; Liability Management: A New Tool for Financial Consultants, Financial Consultant, vol. 1, No. 3, p. 7-11, Fall/Winter 1996, ISSN 1091-644X, Dialog File 15, Accession No. 01395382.Applicant
- McConnell; Gauging Software Readiness With Defect Tracking; IEEE; May/Jun. 1997.Applicant
- Programmer'S Guide; Monitor Client Library 12.5; Document ID 32865:01-1250-01.Applicant
- Yu, et al.; An Analysis of Several Software Defect Models; IEEE Transactions on Software Engineering, vol. 14., No. 9; Sep. 1988.Applicant