Browse Prior Art Database

Block of Repetitive Action through Predefined or User Defined Constraints Disclosure Number: IPCOM000149858D
Original Publication Date: 2007-Apr-10
Included in the Prior Art Database: 2007-Apr-10
Document File: 2 page(s) / 25K

Publishing Venue



Database applications or web applications, such as applications that are used to administer a database, or web applications that are used for online shopping, do not prevent the user from repeating an action that has already been done in the same context. Consequently, the user would either receive an error message indicating a duplicate of action, or they have to manually keep track of the actions that they have previously performed in a given context to prevent any similar actions in that context. This invention blocks the second action by defining what makes an object unique. The uniqueness of the object can be predefined in the application, or can be a user-defined, customized specification. This solution helps applications to: 1. Use a predefined constraint in the application, to never repeat the same action in one application context twice, and therefore prevent issuing an error for an action that was actually successful in the same context. 2. Use a customized, user defined constraint, to provide a warning in case of the repeat of an action in one application context twice or more, and therefore prevent generating similar objects that are not desired by or wanted by the user.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Block of Repetitive Action through Predefined or User Defined Constraints

Case one, is most common in database applications, in which the database system's constraints on specific objects, rejects duplicate action on those objects and throws an error indicating that such an action is not possible.

A good example of this case is a wizard that lets the user submit multiple "autonomous" queries to find the objects of interest (e.g. they want to persist the results of each query in a separate list). In databases, tables are known by 2 part names: schemaname.tablename. So, the user might be searching a database and they want all tables with a schema of HR. This query would retrieve a set of tables to them. Autonomously, they also want all tables with a tablename that contains the string emp (employee, emp_resume, emp_dependents), etc. So, they are sending these two autonomous queries:

Find tables with schema = HR

Find tables with the string emp in the tablename

Note that it is likely that some of the tables with the string emp are in the HR schema, but not all of them, and vice versa. Since these queries are independent, the tool helps the user handle duplicates (e.g. the duplicate tables will be saved in one list only/their own list).

The second case that is covered by this art helps the user to avoid manual tracking of the previous actions. A good example for this case is web applications used by online stores such as Amazon. The user searches for an item or a set of items, browses through the retuned results, selects and adds the desired objects to their shopping cart/wish list. For small searches where the shopper is looking for a few items, the current application logic would suffice. However, when the user is shopping for more than a few items and the result of the searches return similar items, the user has to always manually compare and contrast the items in their shopping cart to what is returned in order to decide on adding a new item. A solution is needed here to define a customized user's preferences on the shopping cart item...