WO2011009141A1 - System and method for conducting transactions from third party sites - Google Patents

Abstract

A method and system for enabling consumers to identify, mark for purchase and pay for items from ecommerce sites directly from third party sites, without requiring that the user navigate away from the third party site for any portion of the purchase transaction In an embodiment, a rich media component cooperates with a translation server, an administrative server and a configuration database to permit third party websites to provide consumer access to items available for purchase on ecommerce sites In an embodiment, the translation server can include a plurality of translation modules for providing appropriate interfacing with ecommerce sites having different characteristics. Other aspects of the invention include developing πch media documents for embedding in web pages such as online auction or catalog pages compπses providing a Flash-based template together with a plurality of widgets for placement on the Flash page

Description

System and Method for Conducting Transactions from Third Party Sites

INVENTOR

David Vogt

Menlo Park, California

U.S. Citizen

SPECIFICATION

Related Application

[001] This application claims the benefit of U.S. Provisional Patent Application S.N. 61/226,655, filed July 17, 2009, having the same title and inventorship as the present application, and which is incorporated herein by reference.

Field of the Invention

[002] This invention relates generally to systems and methods for permitting users to initiate and complete transactions with ecommerce sites directly from third party websites without any requirement to navigate to the ecommerce site with which the transaction is conducted. Other aspects of the present invention enable the display of rich media documents within a browser-based environment on a computer system, and more particularly relates to systems, methods and techniques for management of software tools therefor.

BACKGROUND OF THE INVENTION [003] Conventional purchasing in an ecommerce environment has typically comprised one of three approaches: in the most common, a purchaser finds the item he wants to purchase on a website, marks it for purchase, and pays for it, all without leaving that website. While this approach works well in many instances, many potential buyers will never see the website, let alone the desired item, and thus both the buyer and the seller lose the opportunity to acquire/sell the item the buyer wants. The latter is particularly true of large ecommerce websites such as eBay, where the many millions of items listed make it virtually impossible for a purchaser to identify more than a few of what can be many items of interest. Even sites such as Amazon offer a staggering multitude of goods where the likelihood of finding an item of interest is frequently closely related to knowing, before even beginning a search, the exact manufacturer and model of the item the consumer wants.

[004] In other approaches, either the finding of the item or the payment for the item is managed from a third party website. Thus, in the case of third party payment, the buyer may conduct his purchase on one website, but is redirected to another website to pay for the item. This can, in many instances, cause the buyer to back out of the transaction for a number of reasons, including concerns about the security of the payment website, or the simple inconvenience of having to go through multiple verifications simply to purchase an item. As a result, there has been a need for a system and method which permits consumers to identify, purchase and pay for items available on an ecommerce site from a third party site without ever requiring the consumer to leave the third party site.

[005] Many internet web sites permit users to display information on those web sites. Included among these are YouTube, Myspace, eBay, and so on. Many such websites, for example eBay, permit users to create their own pages on the host website. [006] In general, most such user-created web pages are HTML-based, with the optional inclusion of small rich media components. While these web pages attract significant viewers, the functionality provided in the prior art approach does not permit the user the initiate and complete transactions with third party ecommerce sites from those web pages. In this, and other ways discussed hereinafter, the prior art approach limits flexibility, limits the manner in which changes can be made, and further can require undesirable repetitiousness if multiple web pages having similar content are to be constructed.

[007] To understand some aspects of the invention, it will be helpful to understand the data structures typically used in managing ecommerce sites. Like many online "catalogs", "stores" or websites, the data structure for the data comprising an eBay auction comprises a key field with a plurality of associated fields. The particular fields vary depending upon the desired presentation for that particular website or store, but typically the use of a key data field enables access to the remaining data. Thus, while it will be appreciated by those skilled in the art that the present invention has application in the construction of many web pages, for purposes of simplicity and clarity the present invention will be described within the eBay context.

[008] In the prior art, the key field is typically used just within a particular ecommerce site. In most if not all cases in the prior art, this limits access by external links, and thus limits the ability to conduct transactions with that ecommerce site. Moreover, the combination of web pages structured in

HTML combined with inefficient use of available data structures has limited the development of new methods for both offering goods for sale on ecommerce sites such as ebay, and also for conducting transactions with such ecommerce sites. Thus, there has been a need for a new method and system structure that permits efficient and effective listing of items on ecommerce sites, and also permits easy conducting of transactions with such ecommerce sites. SUMMARY OF THE INVENTION

[009] The present invention overcomes many of the aforestated limitations of the prior art. In an aspect of the invention, a shopping widget is embedded in a third party website that enables a consumer to purchase items from a linked ecommerce website without needing to visit the ecommerce site. In some implementations, the system includes a translation server for interfacing among differently coded websites. [0010] In another aspect of the invention, a rich media description page is provided for permitting more robust descriptions of items offered in e-catalogs or other ecommerce sites. In an aspect of the invention, the rich media page can be described substantially entirely in Flash. In some embodiments various techniques for populating the rich media page are provided, including the use of a variety of widgets and related techniques such as a selection of frames, rotation, resizing, shadowing, opacity, fills, video playback, a plurality of selectable image qualities, the use of combined widgets, among others. In a related aspect, various techniques for monetization of the rich media page are provided, including proximity-based pricing, color-based pricing, image- quality pricing, among others. In an aspect of the invention, a visual shopping cart is provided whereby the total of a variety of pricing elements found in the rich media page is substantially continuously updated at rich media elements are added to or subtracted from a rich media page under construction. [0011] In still other aspects of the invention, an auction widget is provided.

In these and other aspects of the invention, a structured data approach is implemented through the use of at least one key field and related linked fields, thereby providing a reusable document which can be thought of, in some respects, as a dynamic template where data for filling in fields of the template is dynamically fetched upon entry of appropriate data in a key field.

The auction widget can, in some implementations, be configured to interact with remote and/or third party sites. The use of indirection is implemented in some embodiments. [0012] The invention can be better understood from the following detailed description of the invention, taken in conjunction with the appended Figures. THE FIGURES

[0013] Figure 1 illustrates a computer network comprising one or more servers, wherein an exemplary ecommerce site is hosted on a first server, a third party website is hosted on a second server, and a consumer has access to both through his computer connected to a network such as the internet.

[0014] Figure 2 illustrates a shopping widget embedded in a third party website that enables a consumer to purchase items from a linked ecommerce website without ever having to visit the ecommerce website for either purchase or payment.

[0015] Figure 3 illustrates an alternative to the arrangement of Figure 2, wherein a translation server is provided. [0016] Figure 4 illustrates a shopping platform including a translation server.

[0017] Figure 5 illustrates in flow diagram form an embodiment of a purchase process associated with the shopping widget of Figure 2 in accordance with the invention, including identification of the item to be purchased from an ecommerce site, committing to buy, and payment, without ever navigating to the ecommerce site.

[0018] Figure 6 illustrates in flow diagram form an embodiment of a login process for use with the shopping widget of Figure 2.

[0019] Figure 7 illustrates a computer displaying an internet browser page, with the page editor of the present invention displayed on that page. [0020] Figure 8 illustrates the page editor for the rich media description page of the present invention.

[0021] Figure 9 illustrates a search tool page in accordance with the invention.

[0022] Figure 10 illustrates the addition of a widget from the search tool page to the palette on the user interface page. [0023] Figure 11 illustrates the selection of a widget from a palette and its addition to the page description.

[0024] Figure 12A-12D and 13A-13G illustrate various properties of widgets and the associated controls.

[0025] Figure 14 illustrates in flow diagram form an embodiment of the calculation of page cost using the visual shopping cart process of the present invention. [0026] Figures 15A-15B illustrate an embodiment of an image quality pricing algorithm in accordance with the invention.

[0027] Figures 16A-16B illustrate a color-based pricing algorithm in accordance with the invention.

[0028] Figures 17A-17C illustrate an embodiment of combining widgets to form more complex object descriptions.

[0029] Figure 18 illustrates an example of proximity relationships among selected widgets as a basis for proximity-based pricing.

[0030] Figure 19 illustrates in flow diagram form an embodiment of the calculation of proximity-based pricing. [0031] Figures 20A-20B illustrate a example of determining sets in accordance with an embodiment of a proximity based pricing algorithm.

[0032] Figure 21 illustrates a gallery widget.

[0033] Figure 22 illustrates an image picker widget.

[0034] Figure 23 illustrates the construction of an exemplary rich media document.

[0035] Figure 24A illustrates the operation of an auction widget in accordance with the invention.

[0036] Figure 24B illustrates the use of structured data in connection with the invention.

Detailed Description of the Invention

[0037] The present invention is, in part, directed to methods and systems for permitting consumers who have navigated to a third party website to identify, purchase and pay for items offered for sale on an ecommerce site, without requiring that the consumer navigate to that ecommerce site for any portion of the transaction. [0038] To appreciate this aspect of the invention, Figure 1 illustrates a computer 100, operated by a consumer, which has access to a network such as the internet. Through the internet 110, the consumer's computer can access a third party website such as YouTube, Facebook, MySpace, or any other website. For the sake of convenience, such third party websites are illustrated as being hosted on server 120, although in reality such websites are typically hosted on many servers located in geographically disparate locations, and quite often a single large website is hosted across multiple servers. In addition, through the internet the third party server has access to an ecommerce website 130. Importantly for understanding the present invention, while the consumer is typically, although not necessarily, able to access the ecommerce website directly, in accordance with the present invention he is not required to do so to be able to engage in purchase transactions of the sort contemplated by the present invention.

[0039] Referring next to Figures 2-6, an embodiment of certain aspects of the present invention can be better appreciated, as well as an alternative approach. In many instances, even consumers seeking to purchase an item will never successfully find a website that sells the item they want, nor the item itself even if they find the website. However, if the item is available on a site that they do encounter, they are likely to purchase the item, especially if the item can be both bought and paid for without ever leaving the site where they discover the item.

[0040] This is made possible by the arrangement of Figures 2-6. In Figure 2, a rich media component 200, which can be thought of as a shopping widget, is embedded into a third party site 205 such as Facebook, MySpace, or any other website. The widget 200 links the user to an ecommerce website 210, such as eBay, Amazon, or any other ecommerce site, and performs the functions of extracting from the ecommerce website appropriate data to permit a user visiting a third party site 205 such as Facebook (in the illustrated example) to see the item for sale on the ecommerce site without ever visiting the ecommerce site, as indicated at 215. In addition, the widget permits the user to mark an item for purchase, shown at 220, again directly from the third party site where the widget such as Facebook without visiting the ecommerce site 210. Still further, the widget 200 permits the user to pay for the item directly from the third party site 205, again without visiting the ecommerce site, as indicated at 225. [0041] In Figure 3, an alternative embodiment to the arrangement of Figure 2 is shown, wherein a translation server is used to perform the functions of interacting with the ecommerce site to determine inventory and pricing data, as well as to complete payment. Thus, a translation server 300 is interposed between the rich media component 200 embedded in the third party website 205 and the ecommerce site 210. In such an embodiment, the translation server comprises a portion of a shopping platform 400, as shown in Figure 4, where an admin server 405 communicates with a configuration database 410, which in turn communicates with the translation server 300. The database comprises configuration data used to control the content in the rich media component/widget 200 as well as data used to extract product information from the ecommerce site and to exchange purchase or authentication data with the ecommerce site or its payments handler. [0042] The translation server comprises a rich media component handler

415 that manages incoming requests from the widget 200 for configuration, inventory, and purchase-related data. The rich media component handler communicates as well with one or more translation modules 420, 425, that interact with a particular target site to query inventory and pricing data and exchange purchase data with the ecommerce site. In a typical arrangement, the translation modules communicate with the target ecommerce site by any suitable means, including published API's or proxy and screen scraping, or any other suitable means, but in each case the consumer is permitted to complete purchases directly from a third party website using a widget 200 embedded in that website.

[0043] The operation of the shopping platform typically entails two primary types of interaction. First, a seller whose goods are available on an ecommerce sight, and who seeks to make his goods available on the third party site, enables the viewing of his goods on the third party site by configuring what content is displaying by the rich media client on the third party site. To accomplish this, the seller configures a translation server by logging into the admin server 405 and configuring a rich media component profile. The profile comprises target independent data such as component look and feel options, and also target dependent data such as target site (i.e., the ecommerce site 210) credentials and item selection data. It will be appreciated by those skilled in the art that the target-dependent configuration data can vary widely depending upon the method of integration with the target site as well as that site's feature set. Once the profile is configured, that profile is assigned a key value, which enables the seller to embed the rich media component into another website while maintaining the correct configuration.

[0044] The second interaction with the shopping platform is when a consumer seeks to view an item using the rich media component 200. This process can be better appreciated from Figure 5. When a user loads a web page containing the embedded rich media component 200, the component is loaded from the translation server on the shopping platform, as shown at step 505 in Figure 5. Once loaded, the rich media component 200 uses the profile key from the embed tag to request initial display properties from the

translation server 300, followed by a display of initial inventory data, as shown at steps 510 through 540 of Figure 5. Thus, the extracted ID obtained at step 510 permits a query of inventory at step 515, which causes a lookup of the target website, the associated translation module such as 420, and identifies any inventory constraints, with the data typically being provided by a local database, as shown at 520.

[0045] An SDK for the target website is used at step 525 to request related inventory, with the inventory being supplied by the SDK backend at 530. The results are converted to a suitable format for display, which can be a generic format or any other suitable format, as shown at 535. The inventory is then displayed to the user as shown at step 540. As the user interacts with the displayed inventory, as shown at step 545, either more inventory data is requested, in which case the process loops back to step 515, or a purchase decision is made, such as by adding an item to a virtual shopping cart as shown at 550.

[0046] For some ecommerce sites, it is necessary to login to make a commitment to purchase an item. The login process is illustrated in Figure 6, and will be discussed hereinafter. Once login is completed, as shown at step 555, the selected item is marked for purchase as shown at 560, which is executed by looking up the target website and associated translation module, and storing the item information in a transaction record on the local database. The target website's SDK is then used to and the item to a virtual shopping cart or other marking/selection method as appropriate for the ecommerce website 210, after which the SDK back end 530 replies with a confirmation that the object has been marked for purchase.

[0047] At some point, if the object has been marked for purchase, the user will typically proceed to pay for the item. If login has not already occurred, and in at least some cases even if it has, the user must login as shown at step 580 to begin the payment sequence. Upon login, a query is made to determine the required checkout fields for the target ecommerce site, as shown at step 585, which causes a lookup of the target website using the translation module and transaction data from the local database as shown at 590. The ecommerce site's SDK is used to obtain appropriate checkout data, shown at 596, which the SDK 530 returns for display at step 600. The user provides checkout data as appropriate for that ecommerce site, step 605, which then is processed by the translation server at step 610 to be sent back to the ecommerce site by means of the translation module interacting with the ecommerce website SDK at shown at 615. The SDK 530 of the website confirms the completed payment and purchase, and returns a payment confirmation for recordation in a local database as shown at 620. The payment/purchase status is then displayed for viewing by the user at step 625.

[0048] The login process can be better appreciated from Figure 6. At step 630, the rich media component 200 queries whether the user is logged in. If yes, the process is done. If no, then at step 635 the user's credentials are requested. The credentials are typically defined by the particular ecommerce website, and can include user name or email, pin or password, plus other indicia that confirm the user's identity. The credentials are passed to the SDK back end via the translation server and the translation module using the configuration ID and the ecommerce website SDK, as shown at steps 640 and 645. Once the ecommerce site responds, the login is either successful or not, as determined at step 650. If successful, the process ends, and if unsuccessful an error message is generated as shown at step 655.

[0049] In other aspects of the invention, systems and methods are disclosed for creating rich media description pages for use in an internet environment, as well as systems and methods for the operation of a visual shopping cart, including a process for monetizing the creation of rich media description pages through the use of the visual shopping cart. For purposes of simplicity and clarity, these systems and methods will be described in conjunction with the creation of an auction page such as might be used on an internet auction site. However, those skilled in the art will recognize that the systems, methods and techniques described herein are not limited to the particular applications described and instead have broad application across a wide range of internet pages and shopping cart applications.

[0050] Overview of the Rich Media Viewer/editor [0051] Referring first to Figure 7, the operation of the page editing system and method of the present invention can be better understood. In Figure 7, a personal computer or other wired or wireless device 700 is capable of communicating with the internet 705. The device 700 includes a display. Loaded on the computer 700 and potentially visible on its display is a web browser 710 which provides access to an HTML page 715, such as an eBay auction page.

[0052] Also available for display on the computer 700 is a rich media viewer 730, which provides access to a rich media document 735. The rich media viewer 730 can, but need not in all embodiments, be accessible through a browser. However, the rich media document 735 created by the user through the rich media viewer is typically embedded in a webpage such as the HTML page 715. Such embedding can be accomplished with the following code:

start

<object classid="clsid:D27CDB6E-AE6D-llcf-96B8-44455354ΘΘΘΘ"

id="ViewerApplication" width="8ΘΘ" height="12ΘΘ"

codebase="http://fpdowriload.macromedia.eom/get/flashplayer/current/swflash .cab">

<param name="movie" value="${url}/ViewerApplication.swf" />

<param name="quality" value="high" />

<param name="bgcolor" value="#E6F6FC" />

<param name="allowScriptAccess" value="sameDomain" />

<param name="flashvars" value="docld=${docld}" />

<embed src="${url}/ViewerApplication.swf" quality="high"

bgcolor="#E6F6FC" width="8ΘΘ" height="12ΘΘ" name ="ViewerApplication" align="middle" play="true" loop="false"

quality="high" allowScriptAccess="sameDomain"

flashvars="docld=${docld}" type="application/x-Shockwave-flash"

pluginspage="http://www.adobe.com/go/getfIa

shplayer">

</embed>

</object>

end

[0053] The computer 700 communicates, again typically through the internet 705, with a third party host website 720, and in at least some embodiments can also access an API server 725, for example for providing real-time updating of data used in the rich media document 715, such as might be appropriate for use with dynamic widgets such as the auction widget described hereinafter. The rich media viewer is hosted by a rich media server 740, and the rich media documents are stored within a database 745 maintained in connection with the server 740. It will be appreciated by those skilled in the art that each of the servers can, and often will, comprise multiple servers.

[0054] The rich media application 730 provides as its user interface 800 the web page displayed in Figure 8. The page editor application 715 is a graphical tool used to construct a rich media description page for display on a website, such as a page describing an eBay auction. However, unlike existing eBay auction pages which are html based with the optional inclusion of small rich media components, the page editor application 715 allows a user to construct an entire page description as a single rich media document, linked to the data structure associated with an underlying website such as eBay. More specifically, a user (not shown) uses the steps and processes described hereinafter to construct a rich media document and insert that document into their eBay auction. [0055] Continuing to refer to Figure 8, the page editor interface 800 comprises three main sections:

• Content 805. The section on the left hand side contains a collection of widgets 810, discussed hereinafter, that the user has chosen to interact with. This section is divided into multiple sub-sections, or palettes 815, providing an easy way for the end user to switch among groups of similar widget types.

• Page 820. The section in the middle is a preview version of the visible page under construction as it will appear to viewers when the document is published. The user places widgets 810 or other components onto the page 820 and interacts with them to achieve the desired overall look. In a document with more than one page, this section also allows the user to switch among various pages in order to edit the individual pages. Multiple pages can be displayed in any suitable form, for example as layers, or tiles, or any other arrangement convenient for the particular

implementation.

• Properties 825. The section to the right contains a collection of properties relating to the currently selected widget. While some widget properties can be manipulated by interacting with the object directly (such as rotating a widget by dragging a corner), other properties available for manipulation use the specific tools displayed in the properties section.

[0056] A unique aspect of the page editor is that it is designed to accommodate a very large number of widgets without overwhelming the user. Just as a painter will use a palette to pre-select a subset of their total available paints for a given painting, the editor provides a per-widget palette that the user can utilize to organize commonly used widgets. In the image of Figure 8, the currently selected widget palette 815 is Clip Art and that palette is currently empty. [0057] Just as in the painter example, the palette can be populated from a large inventory of available widgets by opening the widget search tool. Within this example, the search tool can be launched by clicking the Add Clip Art button. The widget search tool is shown in Figure 9. [0058] The search tool 900 allows a library of widgets to be searched using a plain text search phrase entered in the "Search" field 905. In an embodiment, the search tool 900 searches a library of widgets using a text match of the search phrase, and displays the results in the "Search Results" portion 310 of the search tool page. The results are, in at least some embodiments, displayed in order of greatest relevance, or ranking, with regard to the search phrase and the user is then able to navigate through the result set. When the user selects a particular widget, the details of the widget are displayed in the Item Details section 915 on the right as shown above. In an embodiment, the search tool compares the search phrase with one or more of the following criteria:

• Name 920. Each widget in the inventory has a user-visible name, for

example, 'sticky note'.

• Description 925. Each widget has a user-visible description such as

'Yellow sticky note with one corner folded over'.

• Price 930. Each widget has a price associated with its use on a page.

• Category. Each widget can be logically associated with one or more

categories such as 'Halloween' or 'musical instruments' or 'New York City'. The name of the category is used for comparison.

• Keywords. Each widget can be associated with an arbitrary number of keyword phrases. Keywords are used to capture relevant semantic data that would otherwise not be included in a description such as 'golf, 'ball', 'dimple', 'round', 'shadow', 'sport', 'small', etc... The text of the keyword phrase is used for comparison. [0059] Depending upon the embodiment, additional search criteria can include widget type, author, popularity and any other suitable criteria.

Depending upon the implementation, any or all of the available criteria can be displayed in the Item Details section. [0060] The user can then add the widget to the palette of their page editor

800 by clicking the Add button on the search tool page 900. This causes the selected widget simply to be added to their open palette 815 in the Content portion 805, but does not commit the user either to use or to pay for the widget. Figure 10 illustrates the clip art palette with a single widget 1000 installed. When the widget is added to the palette, the cost of using the widget in the page is displayed adjacent the widget, as shown in the red oval 1005 adjacent the widget 1000.

[0061] Once located in the palette 815, a widget 1000 can be copied into the current document by simply dragging and dropping the widget into the page area 820 as shown in Figure 11. Once the user drops the widget into the page, the widget is left in the selected state with control handles in the form of a bounding box 1100 as shown. In addition, the act of dropping the widget into the page adds the widget to the user's shopping cart, as indicated at the bottom of the page area 820 by both the total page cost 1105 and total document cost 1110. If the user elects to remove a widget, the total is reduced by the value of that widget. The user is free to add or remove widgets until the page description is complete. In addition, the Properties portion 825 of the interface 800 changes to reflect the properties associated with the selected widget.

[0062] Widget functionality

[0063] Once a widget is placed on the page 820, the user can interact with its properties. Depending upon the particular widget in an embodiment, properties that are available to be manipulated include rotation, resizing, shadowing (with selection of color, offset and fuzziness), opacity, border (style, color and weight), and streaming video content.

[0064] Rotate

[0065] To rotate a widget, the widget is first selected to display the bounding control box. Once selected, any of the round handles can be dragged with the mouse to rotate the widget as shown in Figure 12A.

[0066] Resize [0067] To resize a widget, the widget is first selected to display the bounding control box. Once selected, any of the square handles can be dragged with the mouse to resize the widget as shown in Figure 12B. [0068] Shadow

[0069] For those widgets that support a drop shadow effect, a drop shadow is created by displaying another copy of the widget in a different color behind and slightly off center of the original as illustrated in Figure 12C. [0070] The shadow effect has several related properties that control look of the effect:

• Shadow color. This is the color of the copy of the image that appears behind the original.

• Shadow offset. This is position of the shadow relative to the position of the original.

• Shadow fuzziness. This is the amount of blurring to apply to the copy of the image before it is rendered. The fuzzier the shadow, the softer the shadow appears to be.

[0071] These properties can be manipulated through a control in the properties section of the editor as shown in Figure 12D.

[0072] The controls are as follows: [0073] This checkbox enables/disables the shadow effect for the widget.

[0074] This slider controls the degree of fuzziness of the shadow.

[0075] This is the currently selected color for the shadow. Clicking the box will display a color palette allowing the user to select a different color.

[0076] By clicking in this box, the offset of the shadow from the image is the same as the offset of the mouse click from the center cross in the box. The light grey cross behind the darker cross illustrates the currently selected offset.

[0077] Opacity

[0078] Opacity is the degree of transparency of the widget. By increasing the opacity the image becomes more visible while decreasing the opacity causes the image to become more translucent. Figure 13A demonstrates opacity by displaying two black boxes 1305A-B over an existing widget 1100, one with a high degree of opacity and another with a low degree of opacity.

[0079] The degree of opacity can be manipulated through a slider control 1310 as shown in Figure 13B.

[0080] Border

[0081] A number of widgets have a border property. When enabled, the border property causes the widget to be framed in a bounding box using a configurable line style. Figure 13C illustrates a widget with a dashed line border 1315. The border effect has a number of configurable properties: • Style 1320A. This determines the visual look of the border. For example, a solid or dashed line.

• Color 1320B. The color of the visual border applied to the widget.

• Weight 1320C. How large the visual effect should appear. When a border is a line, this may simply refer to the width of the line.

[0082] These properties can be manipulated using a control in the properties section as illustrated in Figure 13D. The controls are as follows: Dropdown 1320A selects the border style, including the option of no border at all. Color Box 1320B shows the currently selected color for the border.

Clicking the box will display a color palette allowing the user to select a different color. Numerical sealer 1320C controls the weight of the border. Larger numbers tend to make the border appear thicker or larger.

[0083] Fill

[0084] Several widgets contain voids that can be filled with a color or pattern. These widgets, typically shapes, support a fill property. The fill control is illustrated in Figure 13E. The controls are as follows: fill type 1325A, including solid, linear transition, radial transition and no fill at all; transition fills start with one color and end with a second color; starting color 1325B, or in the case of a solid fill, the only color of the fill; ending color

1325C, used in the case of transition fills.

[0085] Video Playback

[0086] The video widget allows streaming video to be embedded into the document page. Since the end user typically needs to interact with video

(play, pause, rewind, etc.), the video widget contains several properties specific to the video aspects. The video playback control is illustrated in Figure 13F. [0087] The controls are as follows:

[0088] Checkbox 1330 determines whether the video starts playing as soon as the page is displayed to the end user or whether the user needs to manually start the video by clicking on a play button in the controls.

[0089] Play/Pause/Stop buttons 1335 allow the user to play the video while it is in the editor so they can visualize how the video will appear to end users.

[0090] Dropdown 1340 selects the type of on-screen controls for the video widget. On-screen controls allow the user to start, stop and scan through the video. There are several styles of on-screen controls including the option for no controls at all.

[0091] "Show time" checkbox 1345 determines whether the running time of the video is displayed in the corner. This allows the user to describe key moments in the video such that the end user can find them.

[0092] Auto-Hide Checkbox 1350 determines whether the controls remain visible at all times or only when the user places their mouse over the widget.

[0093] Color Box 1355 displays the color of the running time display.

Clicking the box displays a color chooser to select an alternate color.

[0094] Slider 1360 controls the overall size of the on-screen controls, allowing them to be made smaller so they obscure less of the video, or larger so they're easier to interact with.

[0095] Color Box 1365 indicates the color of the on-screen controls.

Clicking the box displays a color chooser to select an alternate color.

[0096] Shopping cart functionality

[0097] The visual shopping cart is unique in that the choice to purchase an object does not require an explicit purchase-related action, but rather is implied by the natural use of the object in the final page description, where the page description is an embeddable webpage. For example, in the case of the page editor 715, the user's desire is to construct an appealing and engaging page description. To that end, the user adds (or removes) visual elements in the form of widgets to their document and arranges them such that the overall collection and arrangement results in a way that is valuable to the user. While a running total is provided automatically during the

construction of the page, the cost of the inventory of items used on the page is generated automatically from the finished document, rather than at an intermediate step. [0098] To further illustrate this concept, consider an example from another context, such as food. Large collections of "food widgets" exist in a convenient to access format called a grocery store. However, the natural operations performed on food are to combine multiple ingredients in various ways to form a complete dish that has value and appeal to the user. A visual shopping cart analogy would be to setup a kitchen in a grocery store and allow the user to manipulate any of the inventory in the store in a natural way (cooking, mixing, etc) and only when their meal is complete is there a calculation of all the "food widgets" actually contained in the final meal. This completely eliminates the non-natural operation of placing food in a basket simply to transport it to a point of purchase before it can be used in the cooking process.

[0099] In addition, the elimination of the need to pre-select inventory before it is implemented eliminates the mismatch between the planning and implementation phases. That is, if you use corn in your meal, you weren't prevented from using it simply because you didn't consider it as an ingredient at the time you were in the grocery store. The visual shopping cart effectively places consumables as close as possible to the consumption process so that the barriers (such as adding to a cart or making a purchase before use) are minimized or eliminated.

[00100] In addition, because there is no explicit shopping cart, there is no explicit action required to remove items from the shopping cart. For example, if the user has a widget on their page that they no longer want to use, they can simply drag the widget off the page. Since the widget is no longer on the page, the process of generating the resulting inventory of items for purchase would ignore the discarded widget. [00101] The process of determining the total cost of items in a visual shopping cart is illustrated in the flow diagram of Figure 14. The process starts at 1400, at which point the page cost and total cost is zero, shown at 1405. Then, at step 1410, the first widget used in the page is identified, and its price is determined at step 1415. If the widget is used in the currently displayed page, as determined at step 1420, the page cost is incremented appropriately at shown at 1425. The total cost is then incremented at step

1430, as appropriate. A check is then made at step 1435 to determine if that widget is the last widget. If not, the process gets the next widget at step 1440 and then loops back to step 1415. The process continues through each of the pages until all pages and all widgets have been accounted for, after which the cost display is updated at step 1445, after which the process completes at

1450.

[00102] Within this particular flow, the process labeled Determine widget price can be implemented in a number of different ways to provide unique and powerful pricing models specific to a visual shopping cart environment.

Several alternative pricing implementations are discussed below.

[OO103] Property-based pricing

[00104] The use of the visual shopping cart of the present invention permits matching of the properties of the widgets selected for use in the page description by the user with the pricing of those widgets. To illustrate, consider a common prior art pricing model for digital images. When purchasing digital images it is typical to have a choice of different resolution versions of the same image where incrementally higher resolution images have incrementally higher prices.

[00105] In such a prior art arrangement, the user is forced to select a particular image quality for purchase before they actually use the image in their particular application. In the event that the user selects a lower resolution image, and then decides to scale the image to a larger size, the resulting work will look degraded. Conversely, if the user pays for a larger image, and then scales it down, image quality is preserved but the user has overspent.

[00106] In contrast, the visual shopping cart system of the present invention implements a pricing model where the price of the widget depends on how the user interacts with that widget. Thus, consider an image widget 1500A that can be resized among several resolutions 1500B-1500C via its property settings. In this embodiment, the user can increase the size of the low scale image and if they are dissatisfied with the resulting image quality they can use a property control to change the source image to a higher resolution version as shown in Figure 15A.

[00107] Alternatively, changes in image quality can occur automatically as part of the resize operation itself. This method of automatically selecting the optimal image to maximize image quality and minimize price during a widget resize operation is described in the flow diagram of Figure 15B. In the illustrated embodiment, the process starts at 1500, and advances to step 1505 where desired image size is calculated. If the desired size is larger than the current image's natural size, as determined at step 1510, then the process branches to step 1515 to determine whether a larger size is available. If so, the image is replaced with the larger size at step 1520, and the price is increased.

[00108] If, at step 1510, the desired size is found not to be larger, then a check is made at step 1525 to determine whether the desired size is smaller than the current image's natural size. If so, the process branches to step 1530 to determine whether a smaller size is available. If yes, the current image is replaced with the smaller image and the price is decreased. If no different sizes were available at the various checks, or upon substitution of the image in accordance with steps 1520 or 1540, the process advances to step 1545 where the now-current image is resized to the desired size, after which the process completes at step 1550.

[00109] In addition to facilitating the selection of image resolution, similar techniques can be used to apply variable pricing models to other widget properties. For example, consider the color property. In the retail world, and by extension, online sales such as eBay auctions, the color red is typically used to denote key sales information such as the price or item condition ("like new!", "great condition!"). This leads to the color red having a higher value than other colors in certain circumstances. This can be leveraged by applying a variable pricing model on the color palette.

[00110] Figure 16A illustrates a color selection palette with the areas of color closest to pure red marked with an explicit cost of one dollar. In addition the diagram shows the addition of a price attribute so the user can see the cost of the selected color as they drag their mouse around the color palette.

[00111] One implementation of variable priced color is to allow the widget creator to specify points in the color space and assign an individual price to each point as shown in Figure 16B.

[00112] When the user selects a point in the color space, an algorithm that sums the price-weighted distances to the price points is used to compute the effective cost of the selected color. This allows the widget creator to price valuable areas of the color space based on the individual characteristics of the widget. For example, consider a heart widget. When selected close to Valentine's Day the color red can have a much higher value to users than the color blue so a premium can be placed on the color red while still allowing users to utilize the widget at a much lower cost if they select a less desirable color. [00113] In general terms, if each property of a widget can be thought of as an axis in an N-dimensional space (where N is the number of properties), the resulting space is a complete representation of a possible widget

configurations. Within that space the value of the widget to an end user is not uniform. For example, a small brown heart rotated upside down is likely not as valuable to an end user as a large red heart right side up. If the perceived value of every possible configuration in the space were to be determined, the N-dimensional space could be considered a value space. This space tends to have areas of high value and areas of low value. Property-based pricing allows the high value areas of the value space to be priced higher than the low value areas which not only provides an opportunity for the widget author to maximize their return on the widget, but also provides the end user a great degree of freedom in optimizing the cost of a widget to meet their needs. In addition, because this process occurs interactively as the user manipulates widgets in a natural way, the user is not burdened by a purchase-related process, whether by being required to pre-select a particular widget configuration or by being required to add a widget to an inventory list before using it. [00114] Proximity based pricing

[00115] In some embodiments, proximity-based pricing is implemented. For example, a widget that comprises one of a collection of related images where any one of the images in the collection can be selected for display. Thus, Figure 17A illustrates a collection 1700 of related flower widgets.

[00116] Selected ones of such widgets can then be combined to create a decorative page element as shown in Figure 17B, where selected widgets 1705A-C are combined to create a bouquet 1710. These combinations of widgets 1710 can then be used to decorate other page elements such as the picture 1715 shown in Figure 17C. [00117] In an embodiment of the invention, the user is charged for a single use of the widget per document. In this case the user would pay for a single copy of the widget even though six copies were used on the page. If the widget cost $1 then the total cost would be $1.

[00118] In another embodiment, the user is charged for each use of the widget. If the widget cost $1 then this would amount to $6 for the image of Figure 17C. [00119] If the widget creator expects that the multiple uses of the widget would be common, as would be the case with a collection of images, then the first model would require the widget creator to charge a higher price for the widget to monetize the expected multiple uses. This higher price may in turn reduce overall usage as the higher price may deter interest in the widget. On the other hand if the widget creator uses the per-use pricing model then they will tend to lower the price to keep the overall cost from being prohibitive. This in turn can result in lower returns when users do not use enough copies to overcome the low per-use cost. [00120] In yet another embodiment, proximity-based pricing is used. In this arrangement, the widget creator defines a proximity relationship, for example in terms of an area whose dimensions are defined in terms of pixels. Inside the defined proximity area, the single-use pricing model is used; and outside that area, the per-use pricing model is used. For example, consider a proximity value of 100 pixels relative to the example shown in Figures 17A-C.

We can illustrate the proximity 1800 for each instance of a widget by creating, for each widget, a circle with the specified proximity as the radius as shown in Figure 18. It will be appreciated that the proximity need not be defined by a circle, but can be defined by any shape or geometry. [00121] In this example, the three instances in the upper left corner are all within the 100 pixel proximity of each other meaning the group of three widgets should be charged using single-use pricing. Similarly, the three instances in the lower right corner are also within the 100 pixel proximity of each other so it is also charged an additional single-use price. If the cost of the widget is $1 then this sample configuration would cost $2 which is the sum of the two single-use groupings.

[00122] The algorithm to implement this style of pricing is illustrated in the flow diagram of Figure 19. The process starts at 1900, followed by the creation of an empty list at step 1905, and then, at step 1910, retrieval of the first instance of a widget on a page. Then, at step 1915, a set is created comprising all instances of the current widget within the defined proximity. Next, at step 1920, a check is made to determine whether there is an equivalent set already existing in the list. If not, the set is added to the list at

1925. If yes, a check is made at 1930 for more instances of the widget. If yes, the process retrieves the next instance at step 1935 and the loops to 1915. If there are no more instances, the process advances to step 1940 where the first set is retrieved.

[00123] Then, at step 1945, a check is made to determine if the retrieved set is a proper subset of any other set. If so, the set is removed from the list at 1950; if no, the next set is retrieved at 1955. If a next set is found at 1960, the process loops to 1945; if not, then the process advances to 1965 where the total number of sets is calculated, the appropriate pricing applied, and the total price determined. The process then completes at 1970.

[00124] The determination of sets is illustrated in Figures 20A-20B.

Consider the arrangement of widgets shown in Figure 2OA, with proximities indicated by circles. If we enumerate all the overlapping sets we get the following: • (A, B)

• (A₁ B₁ C)

• (B₁ C₁ D)

• (C₁ D)

[00125] Once we perform the subset elimination from the algorithm we're left with just sets (A₁B, C) and (B₁C₁D) which is graphically represented if Figure 2OB. This results in a final list containing two sets meaning the total price is two times the single-use cost of the widget.

[00126] One aspect of this algorithm is that if the proximity is set to the diagonal distance of a page (upper left to lower right for example) then every use of the widget on a single page will be within the proximity limit, but use on additional pages would incur additional use charges. This effectively creates a per-page pricing model without requiring any additional logic.

[00127] This pricing model allows the widget creator to select a somewhat higher single-use price as the user will not be penalized for creating decorative groupings. However it also allows the widget creator to monetize the widget when used to decorate different areas of the page.

[00128] Referring next to Figure 23, another aspect of the invention can be appreciated. While this aspect of the invention is illustrated in the context of an html environment such as an eBay auction description, those skilled in the art will recognize that the scope is considerably greater. More specifically, an aspect of the present invention is that it integrates into a unified environment a wide variety of functions from many different tools, thus allowing a user to construct a rich media document without needing to use other tools. [00129] Consider the auction description 2310 shown in Figure 23. This description combines elements 2300A-C into a single rich media document as shown in 2310. Using existing tools, the user would need to utilize multiple programs to generate this document as described below:

- Image 2300A is displayed slightly rotated in the final document as image 2312. Since html has no ability to handle image rotation the user would first need to pre-process the image using an image manipulation tool such as Photoshop. First the image would be loaded into Photoshop. Then, using the features specific to Photoshop, the user would rotate the image the desired amount and save it as a new image suitable for use within html. The image would then be placed into the document. If the rotation turns out to be wrong, the process must be repeated, and it is not uncommon to see many iterations of these processes, or else the use simply gives up and accepts a simpler result.

- Text 2300B is also displayed slightly rotated in the final document. Since html has no ability to rotate text, there is no way to insert this text into an html document. Instead, the user would need to use some type of image generation tools such as Photoshop or Illustrator to create an image containing rotated text and then save the text as an image suitable for use within html. Again, getting the correct rotation can easily require multiple iterations.

- The drop-shadow box 2300C is used to highlight the text in the final

document as element 2311. Since this element cannot be created in html and creating vector style shapes such as boxes with borders and shadows is not facilitated by Photoshop, the user can use a vector based drawing program such as Illustrator to create this element. In addition, since html does not have an easy way to overlay graphics on top of each other, the text 2300B would really need to be generated as part of 2300C in order to display correctly in the final document. - The final document 2310 needs to be constructed in html so that it displays as shown using a web browser. The user would need to use yet another tool to construct the actual html and would then need to verify that the resulting html actually displays as expected using various web browsers to ensure they all render the html substantially the same.

[00130] Using the rich media editor of the present invention, all of these steps can be performed in a single tool that provides a consistent and uniform user experience when compared with the prior art approach of using multiple programs, each with their own user interface.

[00131] An additional aspect of the present invention is the ability to edit text in Flash. A text widget can be added to the appropriate palette 815 of Figure 8. This causes a text box to be available to the user, which can be dragged and dropped onto the page being developed, as shown in Figure 23.

Once the text box has been placed, the user can add or edit text within the text box. Additional attributes that can be adjusted by the user include font as well as border, shadow, opacity, pop-up, link, and background color.

Likewise, various properties of each of these attributes can be selected by the user. Thus, the user can select or adjust font color, bold/underline/italic, font size, and justification. Border properties can include color, thickness and type, while shadow properties can include blur, direction and color.

[00132] To edit the text, in an embodiment the user double-clicks on the text box, and then selects the edit point within the text box. The text box can be rotated by selecting an appropriate handle, as discussed above, and the editing capability remains. Once the user has finished editing the text, the user selects a point outside the text box and the completed text box is displayed. The user can then proceed to edit, add, or place other portions of the web page, including selecting other widgets from the palettes 815 (Figure

8). [00133] Other Widgets and their properties:

• Shape

o Fill Void

^■ Color

^■ Fill type

o Border

^■ Color

^■ Thickness

^■ Type

O Shadow

^■ Blur

^■ Direction

^■ Color

O Opacity

O Pop-Up

O Link

• Video

O Auto start

O Controls

^■ Style

^■ Color ^■ Play

^■ Pause

^■ Stop

o Border

■ Color

^■ Thickness

^■ Type

o Shadow

^■ Blur

■ Direction

^■ Color

o Opacity

ge / Picture - images uploaded by the user o Border

■ Color

^■ Thickness

^■ Type

o Shadow

^■ Blur

■ Direction

^■ Color

o Opacity o Crop o Pop-Up o Link

• Clip Art - images provided by default o Border

^■ Color

^■ Thickness

^■ Type o Shadow ■ Blur

^■ Direction

^■ Color o Opacity o Pop-Up o Link

• Slideshow - Multiple images displayed in the space of one. The images transition depending on the speed and style selected by the user o Transition effect o Transition Speed o Controls

^■ Play

^■ Pause

^■ Forward ^■ Back o Border

^■ Color

^■ Thickness ■ Type o Shadow

^■ Blur

^■ Direction

^■ Color o Opacity Gallery - A gallery widget is a widget that shows the user's other auctions, i.e., the other items that the user is selling on eBay, as shown in Figure 21. It can take many forms but the most common form is a line of images representing the user's auctions. Mousing over an image brings up details of that auction.

Clicking will take the user to the auction. o Border

^■ Color

^■ Thickness

^■ Type o Shadow

^■ Blur

^■ Direction

^■ Color o Opacity o Background Color

• Image Picker - The image picker is a version of a slideshow that consists of one large parent image and several smaller child images, as shown in Figure 22. Mousing over a child image will replace the parent image with a larger version of the child image. o Border

^■ Color

^■ Thickness

^■ Type o Background Color o Opacity

• Page - This is the canvas that the user works on. The user can have multiple pages in an auction. o Page Name o Background Color

^■ Fill type

• Frame - frames are special borders for images. The user can drop an image into a frame to make their images stand out. o Image Properties ■ Zoom

^■ Pan

^■ Crop

^■ Rotate o Shadow ^■ Blur

^■ Direction

^■ Color o Opacity o Pop-Up o Link

• Background - The background replaces the standard white canvas of a page with the image or design the user selects. Backgrounds are fixed and cannot be moved around the canvas. o Opacity

• Auction item - This widget is a version of a text widget but it has special

properties, as discussed below in connection with Figure 24. The user can specify information they want to auto fill into the Auction Item widget, such as a user's standard shipping policy, or their company information. Updating the user's standard shipping policy will update all of the user's auctions if use an

Auction Item widget in accordance with the invention. The content of the widget is controlled from the host website, not in the auction builder like a standard text box. This allows changes to be made to your global account and not just auction by auction. o Type - Here the user specifies the type of information they want to auto fill, such as "Shipping Policy". o Font

^■ Color

^■ Bold / Italic / Underline ■ Size

^■ Justification o Border

^■ Color

^■ Thickness

^■ Type o Shadow

^■ Blur

^■ Direction

^■ Color o Opacity o Pop-Up o Link o Background Color Feed - This widget is a special version of the scrolling text widget. Feeds allow the user to have a globally changed text box. Feeds are designed to scroll a standard message across all of the user's auctions. Setting up a "Sale" feed will allow the user to place a feed on all of the user's auctions, and also allow the user to update all of the users feeds from one central control panel on the host website. Users can have multiple feeds. o Feed Name o Speed o Font

^■ Color

^■ Bold / Italic / Underline

^■ Size ^■ Justification o Border

^■ Color

^■ Thickness

■ Type

o Shadow

^■ Blur

^■ Direction

^■ Color

o Opacity

o Pop-Up

o Link

o Background Color

olling text

o Speed

o Font

^■ Color

^■ Bold / Italic / Underline

^■ Size

■ Justification o Border

^■ Color ^■ Thickness

^■ Type

o Shadow

^■ Blur

■ Direction

^■ Color

o Opacity

o Pop-Up

o Link

o Background Color

• Audio

o Auto start

o Controls

^■ Style

■ Color

^■ Play

^■ Pause

^■ Stop

• Pen Tool - the pen tool allows the user to draw on the canvas with a mouse or other pointing device.

o Color

o Thickness o Opacity o Line type

[00134] It will be appreciated that some of the above widgets are passive visual components, while others offer more dynamic capabilities. For example, the video widget is a component that will stream video from a remote source at the time the widget is viewed. The use of such widgets is another aspect of the present invention. [00135] The benefit of a widget in accordance with the invention can be illustrated in the eBay context. An eBay auction contains a large amount of meta-data about the item for sale, where the data is structured according to the needs of the particular host website. For example, an eBay auction has a title, sub-title, shipping details, insurance details, tax information,

categorization information, etc. This data is provided to eBay at the time the auction is posted on eBay, but some of it can be changed over the course of the auction, but the data structure remains constant even if the data in a particular field changes. As one example, the user may want their rich media document, which comprises the auction description, to contain some information that is also part of the auction meta-data such as shipping options. Typically a user would need to enter this data twice, once when posting the auction to eBay and once when creating the auction description. Aside from duplication of effort, this also leads to problems where the auction meta-data and the description can get out of sync in the event that the user updates the data in one location but not the other.

[00136] To eliminate these problems, the present invention includes an auction widget which, similar to the video widget, fetches the data to display at the time the user views the widget as shown in Figure 24A and described below. This offers the useful capability of allowing the person constructing the page to select the source of the data rather than enter the data directly into the widget, as discussed in greater detail below.

[00137] The viewer, using their client computer 2400 navigates to eBay using their web browser 2405. The viewer selects an eBay auction that contains a Page Mage description embedded within it. As shown at 2491 , the auction page comes from the eBay website 2485. As the browser renders the description portion of the auction, the browser will fetch the document viewer 2415 from the rich media server 2450 as shown at 2492. Once the viewer 2415 loads, it will request the specified document 2420 from the rich media server 2450 as shown at 2493. The rich media server 2450 looks up the specified document from a document database 2460 as shown at 2494, and returns the document to the viewer for display. As the viewer renders the document, the embedded auction widget 2425 queries the rich media server 2450 for the configuration auction parameter (in this case the current auction price) as shown at 2495. The rich media server 2450 then checks to see if the requested eBay auction is in the internal memory cache 2455 of the server and, if so, returns the data. If the auction is not in the internal memory cache 2455, then the server will try to load the auction data from the local auction database 2465. If the auction is found, it will be added to the internal memory cache 2455 of the server and the data will be returned to the widget 2425. If the data is not found, or the data in the database is too old, the rich media server 2450 requests an updated copy of the auction meta-data from the eBay API server 2480 as shown in 2497. This data is then stored in the internal memory cache 2455 as well as the auction database 2465 and then returned to the widget 2425 for display on the client computer 2400.

[00138] In an embodiment, one of the properties of the auction widget is a list of eBay auction meta-data fields. By selecting the desired field, whether it be title, shipping options, or even the item picture, the user can keep their auction description in sync with the actual auction details, while at the same time, avoid duplicate data entry. It will be appreciated that the particular properties of the auction widget can vary with the particular implementation, and can be implemented in non-auction environments such as on-line catalogs or other applications where retrieval of updated information is desirable or convenient.

[00139] For example, an auction has many properties that the user may want to display such as current price, title, shipping options, and so on. Some of this data, such as the title, tends to be static for the duration of the auction while other data such as number of bids is dynamic for the life of the auction.

In an embodiment of the present invention, the person adding the widget to their auction page can select a property of the auction to be displayed by the widget, rather than any specific data, and the data will be dynamically fetched and displayed at the time the widget is loaded. The person constructing the page can then focus on refining widget properties such as font, color, and so on.

[00140] The use of structured data typically includes a key field, together with a plurality of linked fields, and can be appreciated from Figure 24B. For an ebay auction, the key field 2500 can be, for example, the item number, with the remaining data (description, price, shipping, bid history, and so on) all serving as linked fields. The number of linked fields is limited only by the context and the implementation and can yield n linked fields 2505-2520.

Thus, by identifying a single key field, the data in all of the related linked fields can be called.

[00141] The use of structured data offers the ability for an auction widget to bind to an auction property, which is very powerful in the context of a template. In an embodiment, a user can design a reusable document called a template that can be used over and over with different auctions. By using auction widgets in place of regular text widgets the user can eliminate the need to edit the template every time they use it for another auction.

Specifically, consider the case where a user creates a reusable document that has the auction title in large red text at the top of the page. Using a text widget, the user would format the text as desired and type text to the effect of "title goes here". When the document was used for a specific auction, the user would need to edit the text and insert the text of the specific auction.

[00142] In contrast, consider the same document, but created using an auction widget in accordance with the present invention. In this arrangement, the auction widget is placed and formatted the same as a text widget. The person constructing the page configures the auction widget to use the auction title as a linked property. The auction title, or the text for any other property, is structured data and is available from a data source such as a linked database, typically maintained on a server. As a result, the auction title will be dynamically fetched when the auction page is viewed. However, unlike the text widget, when the same auction widget is placed into another auction page, where the title is different, the auction widget fetches the title of the new auction page without any additional interaction by the user. It will be appreciated that the auction widget of the present invention can be linked to multiple properties. Likewise, those skilled in the art will appreciate that the database to which the auction widget properties link can reside on any server. Thus, for an ebay auction, the linked database can be the ebay database, typically associated with the eBay website 720 shown in Figure 7, or can be a database maintained separately, such as the database 745 shown in Figure 7.

[00143] In some embodiments, a variation of the auction widget can be constructed such that the way an auction widget interacts with remote, third party resources or services is influenced by a property of the associated auction, such as, for example, primary category or title. Stated differently, the ability of the auction widget to extract live auction data and display it directly to the user can be extended to third party resources and services. For example, consider prior art third party widgets such as a Google map widget or a widget that displays product reviews for a specified product. These widgets, similar to the auction widget, provide a visual display of data relevant to some key search term. While the search term (such as title, or bids) can be set in an auction widget and be meaningful in the context of all auctions, a Google map or product review widget cannot. That is to say, if a user placed a product review widget in their document and decided to reuse the document for a different product, they would need to edit the document to change the search term for that widget to match the newly associated auction. This again creates the problem of requiring the person constructing the auction pages to re-enter the data for each specific auction, which is undesirable.

[00144] A unique approach to solving this problem is to use a level of indirection in the search term selection. For example, in an embodiment of the invention, consider a product review widget where the person configuring the widget selects an attribute of the associated auction for use as the search term, rather than selecting the search phrase directly (i.e., something like "ipod" or "nike shoes") This permits the person configuring the widget to select, for example, the primary category of the auction (or the auction title, or any other auction field) for use as the search term in the product review widget. This allows the person configuring the page to pre-configure the widgets such that when the documents are reused for another auction, those documents automatically start displaying relevant review results without any per-auction configuration on the part of the user. When utilized within templates, this provides a tremendous level of pre-configurability on behalf of the template author that appears to just magically work when the template is used to build a new auction document. [00145] Many applications existing for similarly functioning widgets, based on combinations of auction and user-supplied data. As one example, consider a sports themed template that is typically used to sell sports-related products.

[00146] A Google map widget, modified to permit property linking in accordance with the present invention, is placed into a template that lets the user enter their home address and combines that data with the product category to find related sporting activities or facilities close to the viewer. For example, the auction category may be hockey which can then be combined with the viewer-supplied address to locate hockey rinks in the area. [00147] Another example is a shipping rate calculator that uses the address of the person listing the auction as the source and the viewer-supplied address as the destination. Since the source address can be extracted from the auction, the widget would only need to know the destination address to accurately calculate shipping costs.

[00148] Having fully described a preferred embodiment of the invention and various alternatives, those skilled in the art will recognize, given the teachings herein, that numerous alternatives and equivalents exist which do not depart from the invention. It is therefore intended that the invention not be limited by the foregoing description, but only by the appended claims.

Claims

We claim:

1. A system for managing transactions on an existing ecommerce site from a third party site, where a consumer seeking to conduct a transaction with the ecommerce site is never required to navigate to the ecommerce site to initiate and complete the transaction, comprising

an embeddable webpage, adapted to be embedded in a third party website and viewable by a consumer accessing the third party website,

a database comprising configuration data for conducting transactions with the existing ecommerce site, and

a translation module responsive to the database and adapted to communicate with the existing ecommerce site and the third party website for providing sufficient data as provided by the consumer to identify, select and pay for items available on the ecommerce site without requiring the consumer to navigate away from the third party site.

2. A method for embedding rich media documents into a web page comprising the steps of:

developing a rich media document, wherein the entirety of the document is coded for viewing in Flash,

storing the rich media document in a database,

inserting into a web page a link to the rich media document,

retrieving the rich media document and rendering it in Flash when the web page is displayed.

3. A method for creating a rich media document comprising

providing a blank page,

providing to a user a plurality of widgets having different functions, embedding in the document the functions performed by those widgets selected by the user,

generating a final rich media document, and

linking the rich media document to a host web page for embedding in one or more of an online catalog, web-based auction, or online marketplace.

4. A method for dynamically retrieving data associated with a web page comprising

providing access to a database comprising structured data, the structured data having at least a key field,

providing a widget having a plurality of linked widget fields,

linking at least one widget field to the structured data,

embedding the widget in a rich media document,

adapting the rich media document to be retrieved when called from a web page, such that at least the data in the key field is fetched for display when the rich media document is retrieved.

5. The method of claim 4 wherein the structured data further comprises a plurality of linked data fields linked to the key field in the structured data, and further comprising the step of linking one or more of the plurality of linked data fields to an associated one or more of the plurality of linked widget fields.

6. The method of claim 5 wherein the web page is an online auction.

7. A method of editing text in a Flash-based document comprising

providing a Flash-based template,

providing a text box adapted to be compatible with the template, embedding the text box in the template,

selecting the content of the text box,

typing selected characters for display in the text box.