Universal user interaction module for web transactions with user controlled conditions

A universal user interaction module for web transactions with user controlled conditions. Initially a request is received from a user to begin an order. Upon receipt of the request, user information is collected from one or more data repositories. The user information is consolidated and a determination is made as to what additional data is required to complete the order. The additional data is requested from the user and is received from the user. The additional data includes one or more user conditions for placing the order. The order is then stored. The order for the product includes the one or more user conditions, and the order is placed only after all of the one or more user conditions have been met.

BACKGROUND

This invention relates generally to processing within a computing environment, and more particularly to universal user interaction module for web transactions with user controlled conditions.

Much of today's content and functions on the web must be custom programmed to be consumable by end users. The typical user interaction model is for synchronous web transactions. Currently, when users invoke an action to initiate a web transaction, the initiation of the transaction must start immediately. The web transaction cannot be a long running process and must respond within certain timeframes per the HTTP protocol. There is no capability to allow users to schedule the start of a Web transaction based on time or conditions, or to start a long running web transaction on their behalf. In addition, the user interaction model for today's web transactions is inconsistent and requires custom coding for each different web transaction data type.

BRIEF SUMMARY

An additional embodiment includes a system for implementing a universal user interaction module for web transactions with user controlled conditions. The system includes a processor configured to execute a universal user interaction model module, the processor configured to receive a request from a user to initiate an order. Upon receipt of the request, user information is collected from one or more data repositories. The user information is consolidated and a determination is made as to what additional data is required to complete the order. The additional data is requested from the user and is received from the user. The additional data includes one or more user conditions for placing the order. The order is then stored. The order for the product includes the one or more user conditions, and the order is placed after all of the one or more user conditions have been met.

A further embodiment includes a computer program product for implementing a universal user interaction module for web transactions with user controlled conditions. The computer program product includes a tangible storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method includes receiving a request from a user to initiate an order. Upon receipt of the request, user information is collected from one or more data repositories. The user information is consolidated and a determination is made as to what additional data is required to complete the order. The additional data is requested from the user and is received from the user. The additional data includes one or more user conditions for placing the order. The order is then stored. The order for the product includes the one or more user conditions, and the order is placed after all of the one or more user conditions have been met.

DETAILED DESCRIPTION

An embodiment of the present invention implements a universal user interaction module for web transactions with user controlled conditions.

In an embodiment, a user interface is generated based on a data definition, and is presented to a user. The interface is incorporated into a website order process and allows for the creation of orders that are fulfilled asynchronously based on conditions specified by a user. The data is input by the user and is combined with other previously saved user data to fulfill the order when the user's conditions are met.

In an embodiment, the user may request a confirmation after the conditions have been met, but before the order is placed, or may allow the system to place the order automatically when the conditions have been met. The user may also place a recurring order by specifying the frequency of the order along with the conditions.

Because the user interface is generated based on a data definition, the user interface can be implemented quickly and within an existing order flow.

Traditionally, in order to allow users to purchase a product only when a certain condition such as price is met, websites provide an “Add to Price Watch” or “Add to Watch List” action. Users are then left to their own devices to monitor the condition and act on it. That is, when the condition is met, users need to read the notification and manually go back to the website to purchase the product. If the condition is time sensitive, users will need to rely on random luck to complete the web transaction.

In some instances, a user is required to upload data as part of an order (e.g., a photo order, which requires users to upload photos before placing the order.) In these cases, a user is required to wait an extended period of time while the data is uploaded. The user experience would be enhanced if users could quickly specify the data to upload based on a subset of the data, or other data indicators, start the web transaction and let the web application complete the full upload of all of the data and place the order when the upload is complete. Users would then be freed from waiting hours to upload all of the data (e.g., high resolutions in a photo order) to the site before they can specify what order they would like to place.

In traditional web applications, because ordering mechanisms are customized for each site, there are inconsistencies between various user interaction models for a “purchase” action (e.g., “Pre-Order”, “Add to Cart” and “Rent Now”.) For the emulated conditional purchase action, there are inconsistencies as well (e.g., “Add to Price Watch”, “Add to Watch List,” etc.) Each of these web transaction data types, such as a camera or a movie, requires custom coding.

An embodiment provides for users to schedule the start of a web initiated transaction based on user controlled conditions. An additional embodiment allows users to start a long running web transaction on the user's behalf. A universal user interaction model is provided for back-end application developers to define the presented unit of function for various web initiated transaction data types. This functionality is provided without custom coding on a per function, or per data type basis.

In an embodiment, a user's shipping and billing information is previously stored in the back-end system. When a user selects the order button, the user is not prompted for this information, instead the information is retrieved from the backend. As a result, the user is only prompted for conditional parameters specific to the executing of the web initiated transaction.

In an embodiment, there are three categories of parameters requested from the user. The first are the simple required parameter input for this order, such as, for example, a quantity of the order (i.e., how many of the selected item does the user want to order). The second category is the conditions for executing the order. These conditions include, for example, the price at which to execute the order. The third category is the when to execute the order, for example, synchronously (i.e., initiate the order right away), or asynchronously (i.e., schedule initiation of the order at a later time.) In an embodiment, a user additionally selects if the order is to be repeated.

In an embodiment, a condition may be a simple value threshold, or a complex object with Boolean expressions. The user may choose if they want to confirm the order once the condition has been met, or if the condition will automatically initiate the order without additional confirmation after it has been met.

Turning now toFIG. 1, a system100for implementing a universal user interaction module for web transactions with user controlled conditions will now be described. In an embodiment, the system100includes a host system computer102executing computer instructions for implementing a universal user interaction module for web transactions with user controlled conditions. Host system computer102may operate in any type of environment that is capable of executing a software application. Host system computer102may comprise a high-speed computer processing device, such as a mainframe computer, to manage the volume of operations governed by an entity for which the implementing a universal user interaction module for web transactions with user controlled conditions is executing. In an embodiment, the host system computer102is part of an enterprise (e.g., a commercial business) that implements the implementing a universal user interaction module for web transactions with user controlled conditions.

In an embodiment, the system100depicted inFIG. 1includes one or more client systems104through which users at one or more geographic locations may contact the host system computer102. The client systems104are coupled to the host system computer102via one or more networks106. Each client system104may be implemented using a general-purpose computer executing a computer program for carrying out the processes described herein. The client systems104may be personal computers (e.g., a lap top, a personal digital assistant, a mobile device) or host attached terminals. If the client systems104are personal computers, the processing described herein may be shared by a client system104and the host system computer102(e.g., by providing an applet to the client system104). Client systems104may be operated by authorized users (e.g., programmers) of the universal user interaction module for web transactions with user controlled conditions described herein.

The networks106may be any type of known network including, but not limited to, a wide area network (WAN), a local area network (LAN), a global network (e.g., Internet), a virtual private network (VPN), and an intranet. The networks106may be implemented using a wireless network or any kind of physical network implementation known in the art. A client system104may be coupled to the host system computer102through multiple networks (e.g., intranet and Internet) so that not all client systems104are coupled to the host system computer102through the same network. One or more of the client systems104and the host system computer102may be connected to the networks106in a wireless fashion. In one embodiment, the networks106include an intranet and one or more client systems104executing a user interface application (e.g., a web browser) to contact the host system computer102through the networks106. In another embodiment, the client system104is connected directly (i.e., not through the networks106) to the host system computer102and the host system computer102contains memory for storing data in support of implementing a universal user interaction module for web transactions with user controlled conditions. Alternatively, a separate storage device (e.g., storage device112) may be implemented for this purpose.

In an embodiment, the storage device112includes a data repository with data relating to a universal user interaction module for web transactions with user controlled conditions by the system100, as well as other data/information desired by the entity representing the host system computer102ofFIG. 1. The storage device112is logically addressable as a consolidated data source across a distributed environment that includes networks106. Information stored in the storage device112may be retrieved and manipulated via the host system computer102and/or the client systems104. In an embodiment, the storage device112includes one or more databases containing, e.g., system data and corresponding configuration parameters, values, methods, and properties, as well as other related information as will be discussed more fully below. It will be understood by those of ordinary skill in the art that the storage device112may also comprise other structures, such as an XML file on the file system or distributed over a network (e.g., one of networks106), or from a data stream from another server located on a network106. In addition, all or a portion of the storage device112may alternatively be located on a client system104.

The host system computer102depicted in the system ofFIG. 1may be implemented using one or more servers operating in response to a computer program stored in a storage medium accessible by the server. The host system computer102may operate as a network server (e.g., a web server) to communicate with the client systems104. The host system computer102handles sending and receiving information to and from the client systems104and can perform associated tasks. The host system computer102may also include a firewall to prevent unauthorized access to the host system computer102and enforce any limitations on authorized access. For instance, an administrator may have access to the entire system and have authority to modify portions of the system. A firewall may be implemented using conventional hardware and/or software as is known in the art.

The host system computer102may also operate as an application server. The host system computer102executes one or more computer programs to provide the universal user interaction module for web transactions with user controlled conditions. The host system computer102includes a universal user interaction model module108. As indicated above, processing may be shared by the client systems104and the host system computer102by providing an application (e.g., java applet) to the client systems104. Alternatively, the client system104can include a stand-alone software application for performing a portion or all of the processing described herein. As previously described, it is understood that separate servers may be utilized to implement the network server functions and the application server functions. Alternatively, the network server, the firewall, and the application server may be implemented by a single server executing computer programs to perform the requisite functions.

It will be understood that the universal user interaction module for web transactions with user controlled conditions described inFIG. 1may be implemented in hardware, software executing on a general purpose computer, or a combination thereof.

In an embodiment, in order to implement a universal user interaction module for web transactions with user controlled conditions, website developers define user interface code, such as the following markup in the HTML file for the “Order” action on a product data object:

The “roh:hasAction” indicates the action that is available for the camera product object instance. In this example, “Order” is the label for the action. In addition, the “roh:hasMapping” lists all the simple required data input for this order. These parameters are collected and consolidated via linked data starting with order_camera.roh. Input parameters that have known values are encoded in this markup already, any parameters that do not have mapped values will be added in the “Order” button UI prompt as will be described in more detail below. The related link “roh:referenceResource” is the starting point for linked data traversal to find all required data input to initiate this order.

In an embodiment, the input form is created based on data that is provided by an XML schema document (XSD) such as:

The “Price” parameter is marked as a variable value field in the XSD, which means the value for “Price” may change over time. Therefore, “Price” will be shown as a conditional field in the UI prompt. The price parameter is used as a non-limiting example for purposes of clarity. In embodiments, the transaction conditions are declarative, and new conditions may be added by simply configuring the backend to add additional parameters to the XSD file. The additional parameters in the XSD file will cause the HTML file to dynamically change to include the additional parameters as condition options.

The schema in this example is for a camera product. There are two data elements that describe the camera product and are required to create an order for a camera. These fields will be mapped to a GUI, as will be described in more detail below, and with those fields there is enough information to initiate an order on user's behalf.

In an embodiment, a specialized JavaScript client code is used to process this markup to bring up a UI prompt and send the request to the back-end application when users hit the “Submit” button.

FIG. 2depicts a schematic diagram of an example unified order input mechanism in an embodiment. The input mechanism ofFIG. 2may be implemented, for example, in a web browser using code, or a data provided by a data definition document, such as an XSD retrieved from the universal user interaction model module108ofFIG. 1. In an alternate embodiment, the input mechanism ofFIG. 2is implemented as embedded code on a web page. The input mechanism includes one or more simple input parameters202. The simple input parameters202include the quantity or number of the specific item that a user wishes to order. The simple input mechanism additionally includes execution conditions204. The execution conditions204may includes a price condition, as shown, or any other condition for executing the order. In an embodiment, the execution conditions204may include conditions such as when the price reaches a 52 week low, or when the market price drops more than 10%. The conditions are specified at the backend without requiring code changes to the front end application, and are dynamically added to the front end user interface for entry by the user. The input mechanism additionally includes a processing time option206. The options include a synchronous “order now” option, and an asynchronous “order later” option. The “order later” option may include a date after which the order will be processed. In an embodiment, an order that is typically processed synchronously is configured to process asynchronously by adding a condition to the order. The fulfillment of the condition typically takes place in a point in time in the future. In an embodiment, the date may be used in conjunction with the price condition, or as the only condition.

The input mechanism additionally includes a repeat order option208. The repeat order option208allows a user to select if an order is to be repeated, and if so, the frequency. In an embodiment the frequency may be any temporal frequency (i.e. every hour, every day, weekly, monthly, quarterly, etc.). In addition, the input mechanism may include an option to reconfirm the order210. The option to reconfirm the order210allows a user to choose to be notified once all of the conditions have been met, and requires the user to reconfirm the desire to make the order prior to placing the order. If a user chooses not to reconfirm the order, then the order is placed automatically once the conditions have been met.

In addition, the input mechanism has action buttons212. The action buttons212include a submit button, which submits the user's input to the universal user interaction model module108for processing. The action buttons212also include a cancel button to stop the current ordering process.

The input mechanism ofFIG. 2is simplified for clarity and it will be understood that other implementation options are possible. AlthoughFIG. 2depicts an embodiment of an input mechanism, it will be understood that other input mechanisms may be used to input the order information. Other embodiments include more or fewer inputs. Additional embodiments allow the input fields for the various parameters to be embedded in a product page, or to be a standalone browser pop-up window. Further embodiments include a web service for transmitting a user's options directly to the universal user interaction model module108without requiring a windowed implementation.

In an embodiment, the fields of the input mechanism are generated according to a data definition, such as the XSD described above. Any data that is required by the XSD that is not available from other sources is added as a field in the input mechanism ofFIG. 2.

FIG. 3depicts a process flow that may be used to implement a universal user interaction module for web transactions with user controlled conditions in an embodiment. At block302, a user clicks on an “order” button on, for example, a product page in a web browser. At block304the required input is collected. The required input may include a user's billing and shipping information collected from a backend system such as a merchant data repository, a user registration database, and/or a centralized user database. In an embodiment, the centralized user database may be implemented to collect user data that can be used across a number of websites that implement the universal user interaction module108. The input may additionally include product information, and order information such as available parameters for user controlled conditions. In an embodiment, the input may be retrieved from disparate systems. At block306, all of the collected data is consolidated. At block308, a user interface, such as the input mechanism ofFIG. 2is displayed to the user, and the user is prompted for input. At block310, the user's input is received at the universal user interaction model module108ofFIG. 1. At block312, it is determined if the user has submitted the data, or canceled the transaction.

If the user has submitted the data, then processing continues at block314where the data is validated. If the data is valid, then processing continues at block316. At block316, the order is submitted to the backend for synchronous, or asynchronous processing depending on the options provided to, or selected by the user. At block318, processing ends. Returning to block314, if the data is not valid, then the user is prompted to correct the errors at block320. Processing then continues at block308where the user is prompted to input corrected data. Returning to block312, if the user cancels the order, then processing ends at block318without an order being placed or submitted.

Technical effects and benefits include providing users the ability to interact with a presented unit of functionality synchronously or asynchronously to carry out one or more web transactions. An additional benefit includes a universal user interaction model for back-end application developers to use to define the presented unit of function for various web transaction data types, without custom coding of each. Further embodiments include user specified conditions for a web transaction using a unified user interface. Yet another benefit is the ability to allow back-end developers to expose Web transaction conditional parameters declaratively, without new custom coding for each data type. An additional benefit is the ability to present end users with a consistent user interface for web transactions, wherein the contents of the user interface dialog prompt are filled dynamically with requiring custom coding to add and/or remove conditional parameters. A further benefit is allowing end users to invoke web transactions synchronously or asynchronously.

As described above, embodiments can be embodied in the form of computer-implemented processes and apparatuses for practicing those processes. In embodiments, the invention is embodied in computer program code executed by one or more network elements. Embodiments include a computer program product on a computer usable medium with computer program code logic containing instructions embodied in tangible media as an article of manufacture. Exemplary articles of manufacture for computer usable medium may include floppy diskettes, CD-ROMs, hard drives, universal serial bus (USB) flash drives, or any other computer-readable storage medium, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. Embodiments include computer program code logic, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code logic is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code logic segments configure the microprocessor to create specific logic circuits.