Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions
  • G06Q30/08—Auctions

Definitions

• the present invention is generally directed to the auction of items in a distributed computing environment. More specifically, the present invention provides a system and method for users of a distributed computing environment to easily create an auction for complex items consisting of multiple subassemblies.
• On-line auction systems can provide a mechanism for marshalling the auction process including activities for defining the item to be auctioned, posting the item description for review by all potential bidders, managing the bidding process via well established bid evaluation algorithms, selecting a winner based on the defined auction algorithm, and notifying the winner of the auction.
• An auction generally requires all participants to have a consistent understanding of the item(s) being auctioned.
• a consistent understanding enables participants to place a value on the item(s) with the same understanding of product requirements and features. This is easily accomplished for those items that are common or simple. If an item is composed of a single element or a few easily defined components, the chance of a successful auction is greatly increased.
• Bid evaluation for an auction varies based on the selected algorithm. There are several types of bid evaluation algorithms currently in use. These common algorithms are English, Reverse, Dutch, Fixed-price, and Sealed-bid. An English auction is an ascending-price auction where bids must be higher in price than existing bids to win.
• a Reverse auction is the same as an English auction except that the auction is a descending-price auction where the lowest price wins.
• a Dutch auction is technically an open-outcry, descending-price, multi-unit auction where bids are placed for partial quantity and the price decreases for the quantity remaining in the auction until all units are sold.
• a Fixed-price auction is one in which there is no bid increment. The price remains the same throughout the auction.
• a Sealed-bid auction is either an English or Reverse auction in which all bids are concealed.
• Bid evaluation is straightforward for simple item structures.
• the evaluation of prices for these structures typically involves a simple price-price and time-time evaluation. There is no associative information that must be assessed during the evaluation process.
• the present invention can receive a variety of data describing the subassemblies of a larger complex item and present this information in a format supporting a successful on-line auction. In response to presenting the item and subassemblies, the invention can receive and evaluate bids to determine a winner.
• the present invention is generally directed to the administration of on-line auctions for complex items. Specifically, the present invention can receive information about a complex item and the subassemblies that comprise that complex item.
• the information can include information describing the individual subassemblies as well as data identifying how the subassemblies are interrelated and how they are arranged into larger complex items.
• the auction software module of the present invention is capable of taking the supplied information and creating a hierarchy that organizes the complex item and the subassemblies in a format conducive for bidding by on-line bidders. Bids for individual subassemblies or entire complex items are input by bidding clients. The auction software module receives the competing bids, evaluates them, and selects winning bids.
• the hierarchy that can be created to organize the complex item and subassemblies can be viewed as similar to a family tree with many levels of generations.
• the most complex item can be labeled as a first parent.
• the subassemblies that comprise the first parent can be called first level descendants. Even simpler subassemblies that comprise the first level descendants can be called second level descendants and so the pattern continues until all of the subassemblies are identified.
• the auction software module can also verify the accuracy of the hierarchy by ensuring that no item is both an ancestor or descendant of itself.
• the present invention provides a method for organizing a complex item and its subassemblies.
• the method for auctioning comprises presenting each complex item and its subassemblies in a graphical interface so that they can be auctioned to bidders.
• the graphical interface illustrates the relationships between the subassemblies and the complex item.
• the graphical interface may present the complex item and subassemblies in an outline format with an indentation to indicate each level of the subassemblies.
• the graphical interface then permits bidders to submit bids on the complex item and the subassemblies.
• the present invention provides a method for an auction software module to present a complex item and its subassemblies to bidders.
• the auction software module presents the complex item and subassemblies to bidders in a hierarchy format so that the relationships between the complex item and subassemblies are evident.
• This hierarchy is stored on a server computer in a distributed computing environment so that bidders may access the hierarchy and place bids.
• the present invention operates in a distributed computing environment.
• the invention enables the auctioning of a complex item by first receiving data about the complex item from an authoring client.
• An auction software module processes the data and creates a hierarchy describing the complex item and subassemblies to be auctioned.
• Bidding clients in the distributed computing environment can access the hierarchy of a complex item and place bids on the complex item and its subassemblies.
• the auction software module processes these bids and selects a winner according to the desired auction type.
• FIG. 1A is a block diagram illustrating the operating environment for an exemplary hierarchical on-line auction system.
• FIG. IB is a functional block diagram illustrating the components of an exemplary embodiment of the present invention.
• FIG. 2 is a logic flow diagram illustrating operations of a complex item administration process showing the method to define and administer a complex item structure.
• FIG. 3 is a block diagram comparing the structure of a simple item, compound item, and complex item structure.
• FIG. 4 is a block diagram illustrating a highly complex item structure comprising simple items, compound items, and complex items.
• FIG. 5A shows a database structure for managing a highly complex item structure in accordance with an exemplary embodiment of the present invention.
• FIG. 5B shows a database structure for managing bid data and relating it back to the item data structure in accordance with an exemplary embodiment of the present invention.
• FIG. 6 is a logic flow diagram illustrating an exemplary process for constructing a highly complex item structure.
• FIG. 7 is an illustration of a display screen depicting a hierarchical item constructor for an exemplary embodiment of the present invention.
• FIG. 8 is an illustration of a display screen depicting a sub-item editor allowing a user to order quantities of a sub-item in an exemplary embodiment of the present invention.
• FIG. 9 is an illustration of a display screen depicting an item hierarchy for a complex item structure in an exemplary embodiment of the present invention.
• FIG. 10 is a logic flow diagram illustrating an exemplary process for generating an item hierarchy.
• FIG. 11 is an illustration of a display screen depicting a hierarchical bid page for entering quantity and price bids for an item in an exemplary embodiment of the present invention.
• FIG. 12 is a logic flow diagram illustrating an exemplary process for calculating the sub- assembly and total prices for a complex item to evaluate competing bids.
• the present invention supports the auction of complex items in a distributed computer network. Specifically, the present invention permits an auction author connected to a server in a distributed computing environment to create an auction for a complex item comprising multiple subassemblies. Bidding clients, also connected to the server, can submit bids for the complex item and subassemblies.
• the invention provides a format for receiving information about the item to be auctioned and its subassemblies. The information is used to assemble a hierarchy that explains the relationships between the item and subassemblies.
• the invention presents the item and its subassemblies to bidders in a graphical user interface in such a fashion so as to facilitate bidding and selection of winners.
• program modules may be physically located in different local and remote memory storage devices. Execution of the program modules may occur locally in a stand-alone manner or remotely in a client/server manner. Examples of such distributed computing environments include local area networks of an office, enterprise- wide computer networks, and the global Internet.
• the processes and operations performed by the computer include the manipulation of signals by a processing unit or remote server and the maintenance of these signals within data structures resident in one or more of the local or remote memory storage devices.
• Such data structures impose a physical organization upon the collection of data stored within a memory storage device and represent specific electrical or magnetic elements.
• FIG. 1 A illustrates various aspects of an exemplary distributed computing environment in which the present invention is designed to operate.
• FIG. 1A and the associated discussion are intended to provide a brief, general description of the computer network resources in a representative computer network supporting an on-line auction.
• FIG. 1A illustrates an architecture for an exemplary embodiment of the present invention.
• the authoring client 140 enables an auction author to connect to a distributed computing network 105 such as the Internet.
• a server computer 110 on which resides an auction software module 115, is also connected to the network 105.
• the auction software module 115 contains the instructions for conducting an auction of a complex item.
• Coupled to the server computer 110 is a database 120 which stores information provided by authors about complex items to be auctioned. In alternative embodiments of the invention the database 120 may be a part of the server computer 110.
• Bidders are able to participate in an auction of a complex item through bidding clients 125, 130 and 135 also connected to the network 105.
• Bidding clients 125, 130, and 135 receive information about complex items from and transmit bids to the server computer 110 via the network 105.
• FIG. 1A only portrays one authoring client 140 and three bidding clients 125, 130, and 135, the present invention can support multiple clients and conduct multiple auctions simultaneously.
• FIG. IB depicts the exemplary functions of the auction software module 115.
• FIG. IB depicts the auction software module functions that provide a system for defining, presenting, evaluating, and storing complex item structures in an on-line auction environment.
• the hierarchical item constructor 150 provides the tools for creating each item.
• the hierarchical item constructor 150 supports the collection, from the authoring client 140, of the basic information and attributes that define an item in the system.
• the hierarchical ite editor 155 is used to manage the relationships between the complex item and its subassemblies.
• a complex item is generally referred to as a parent, whereas the subassemblies that comprise a complex item are generally called the children.
• the term sibling is used to describe subassemblies of equivalent complexity that comprise the same larger complex item. This scheme of parents, children, and siblings can extend for many levels to describe a complex item comprising many subassemblies.
• the hierarchical bid collector 160 provides the functionality for accepting bids that conform to the hierarchical item structure. This function manages the association of bid (price) information with each item within the item hierarchy.
• the hierarchical data storage component 165 stores data for the hierarchical structures. Storage of the hierarchical item structure supports the maintenance of the information that relates one item to another.
• Hierarchical item display function 170 controls how the auction information is delivered to each bidding client 125, 130, and 135.
• Hierarchical item display 170 provides the formatting technology that displays the item structure in an easy to understand format illustrating the relationships between each item (parent, sibling, child).
• the hierarchical bid evaluator 175 provides the business rule validation for submitted bids according to the relationships implied by the hierarchical structure.
• the functions illustrated in FIG. IB for the auction software module 115 act in concert to reach the desired goal of selecting a winning bid in an on-line auction environment.
• FIG. 2 is an overview of the hierarchical item auction process showing an exemplary method for defining and auctioning a hierarchical item structure. The exemplary process begins with the definition of each item 205. Items are defined by the authoring client 140, using the hierarchical item constructor 150, by entering basic descriptive information such as name, number, description, manufacturer, and unit-of-measure.
• each of these item definitions can be saved by the hierarchical data storage function 165 for later retrieval during the item hierarchy display process 170 and the bid evaluation process 175.
• the process of building the item hierarchy is performed 210. This involves identifying the relationships between parent, sibling, and child items. As the process of identifying relationships is performed, the item data structure is formed. In order to use these item hierarchies in an auction, certain parameters are defined, in step 215, including the quantity desired for each item. Once the item hierarchy is built with the desired parameters for each item, the item hierarchy is displayed 220 to the bidding clients 125, 130, and 135. In step 225, the bidding clients 125, 130, and 135 submit bids for the complex item or its subassemblies to the server computer 110.
• step 230 the hierarchical bid evaluator 175 selects winning bid or bids according to the bid evaluation method being used for the auction.
• FIG. 3 and FIG. 4 illustrate exemplary structures of item assemblies which can be auctioned with the hierarchical architecture of the present invention.
• a simple item is a single item 305 with no children or siblings. The simple item 305 requires no relationships to be defined.
• a compound item 310 is a simple item assembly that has child items.
• a complex item 315 is an item assembly that has both child items and child item assemblies, also called subassemblies.
• a highly complex item 405 is an item assembly with multiple levels of child complex items (subassemblies).
• FIG. 4 represents a complex item 405 with 4 levels of subassemblies.
• Item Assembly 1 has a Sub Assembly ID, which has a Sub Assembly 1D2, which has a Sub Assembly 1D2A, which has a Sub Assembly 1D2A2.
• the storage of the hierarchical information typically requires a relational database management system such as Microsoft SQL Server. This structure allows the hierarchical information to be represented in tables that have relational keys allowing the parent/child relationship to be enforced.
• FIG. 5A shows an exemplary table structure for defining complex item data structures.
• the tltem table 505 provides the storage for the descriptive information about each item while the tltemBundle table 510 provides the storage for the information that relates items together.
• the ParentltemID field of the t l temBundle table and the ItemID field of the tltemBundle table each relate to the t l tem table and thus provide the mechanism for relating items together in a parent/child relationship.
• the tltemBundle table 510 contains information for defining quantity and display sort order. This information is specific to an individual relationship between items. If Item 1A is related to Item 1 as a child, then the quantity of Item 1 A as it relates to Item 1 is information that should be maintained. In addition, for display purposes, it is important to allow the user to control the display sequence of siblings that are related together.
• the display sort order field is where this information is maintained.
• the hierarchical bid evaluator 175 will process the bid data.
• the hierarchical data storage function 165 can record the bid data in a table such as the tBid table 515 and the tBidData table 520 shown in FIG. 5B.
• the tBid table 515 comprises fields that identify each and every distinct bid in a summary format.
• the bid data comprises the bid details and is represented in FIG. 5B as the tBidData table 520. It provides the information necessary to relate price and quantity information to the specific item for which it was entered. This is done through ItemID and Of f eringltemID fields. These provide specific identities for each of the items within the complex item structure.
• the Of f eringltemID identifies the top-level (parent) item for which the bid was placed while the ItemID identifies the sub-item (child) for which the bid was entered.
• the ItemQuantity field is the original quantity defined for the sub-item while the BidQuantity field comprises the quantity entered by the bidder. Bid quantity can be equal to or less than the ItemQuantity value.
• the BidPrice field contains the price entered by the user for the sub-item.
• the RollupPrice field includes a value for the calculated price of the total of all the sub-items and is generally only present for complex assemblies.
• the Children and ChildStatus fields are used in the display construction process, as discussed below in reference to FIG. 10.
• the hierarchical item constructor 150 and hierarchical item editor 155 support the grouping of items together to form subassemblies and the grouping of subassemblies to form complex assemblies.
• the grouping of items and subassemblies into complex assemblies is how the hierarchies that are presented to bidders are created. Two sub-items attached to a parent are both children of the parent as well as siblings of each other.
• additional information is collected that is relevant only to the specific relationship, such as the quantity of the sub-item attached and the display sort order of the sub-item.
• the information defining the items and item hierarchy is managed by the hierarchical data storage function 165 so that it may be retrieved for display.
• FIG. 6 is a logic flow diagram of an exemplary verification process. The verification process involves stepping through the entire item structure, examining each item with a consistent set of tests as follows:
• the first step is to determine if there are identical child and parent items.
• step 605 the item to be added is compared to a parent item. If the two are the same, the item is rejected in step 608. If they are not the same, the "No" branch is followed to step 610.
• step 610 the item to be added becomes the parent and the auction software module 115 retrieves a list of child items for the item to be added.
• step 615 the auction software module 115 queries the tltem data structure
• step 505 to see if the child item is the same as the parent item. If this is the case, the "Yes” branch is followed and the item is rejected in step 620. If this is not the case, the "No” branch is followed to step 625 and the examination of the structure continues with any existing children of the child item. If there are existing children, the "Yes” branch is followed back to step 610 and the examination is repeated. The verification process continues until the base of the complex item structure is reached.
• step 630 the evaluation continues by determining if the item is a child and an ancestor of itself. This begins by retrieving a list of parents of the parent item in step 630. The parent items are examined to determine if the parent is the same as the child in step 635. If there is a match, the "Yes" branch is followed to step 640 and the item is rejected. If the parent is not the same as the child, the "No” branch is followed to step 645 and the process continues with the examination of any parents of the parent item. If there are parents, the "Yes” branch is followed back to step 630 and the process is repeated. If there are no additional parents, the "No” branch is followed to step 650 and the item is added.
• FIG. 7 depicts an exemplary graphical user interface 705 for defining an item. Separate fields are shown for the entry of Item Name, Item Number, Description, Additional Information, Manufacturer, Manufacturer Item Number, and Unit of Measure. This screen shows a list of exemplary sub-items that have been related to this item.
• the auction author may add additional sub-items by clicking the Add New Sub-item button or may edit the sub-item attributes (i.e., quantity and display sort order) by clicking the Update Sub-items button.
• the auction author may access the complex item hierarchy by clicking the View Item Hierarchy button.
• sub-items are added, they are displayed in the sub-item list in the order as defined by their display sort order.
• the quantities assigned are displayed in the quantity column.
• the auction author may delete a sub-item by clicking the Delete button in the Action column. Deleting a sub-item will not remove the sub-item from the system but will simply delete the relationship of the sub-item to the parent item.
• FIG. 8 depicts an exemplary screen of a graphical user interface 805 for updating information about each sub-item associated to the parent item. This involves the entry of the display sort order and the item quantity. This screen displays each sibling item that is associated to the parent and provides fields for entering the display sort order and the quantity. The item name, item number and units of measure are provided for information. A Delete button is also provided that enables the auction author to remove a sub-item from the list. Once the auction author has made all the changes to sort order and quantity, she will click the Update Sub-items button to record the changes.
• FIG. 9 illustrates an exemplary screen of a graphical user interface 905 for displaying the item hierarchy in the hierarchical display format. This format enables the auction author or
• buttons to add a new sub-item and to update the sub-items which can be done at a display screen such as the one shown in FIG. 8.
• FIG. 9 shows within the display 905 the fully expanded hierarchy of a representative complex item structure called Item Assembly 1. It shows that Item Assembly 1 has 4 children related that are Item 1A, Sub-Assembly IB, Sub-Assembly 1C, and Sub-Assembly ID.
• Sub- Assembly IB is represented as a compound item with 2 children that are Item 1B1 and Item 1B2.
• Sub-Assembly 1C is represented as a compound item with 5 children that are Item 1C1, Item 1C2, Item 1C3, Item 1C4, and Item 1C5.
• Sub-Assembly ID is represented as a complex item structure with 2 children that are Sub- Assembly 1D2A and Item 1D2B.
• Sub- Assembly 1D2A is represented as a complex item structure with 2 children that are Item 1D2A1 and Sub- Assembly 1D2A2.
• Sub- Assembly 1D2A2 is represented as a compound item with 2 children that are Item 1D2A2A and Item 1D2A2B.
• the invention also supports additional levels of sub-assemblies.
• FIG. 10 A logic flow diagram illustrating, in greater detail, an exemplary process for constructing an item hierarchy is represented in FIG. 10.
• the exemplary process of FIG. 10 employs a scheme using indentation and graphical icons to represent a complex item.
• Alternative embodiments of the present invention may employ other graphical layouts, such as two-dimensional charts, circular charts, and three-dimensional pictorials, to represent a complex item.
• the process defined in FIG. 10 begins by retrieving the hierarchical recordset in step
• Each recordset row contains three columns used for rendering the user interface. These columns are Children, IndentLevel, and ChildStatus. Children represents the number of children in a row. IndentLevel is a range of numbers from 1 to n for the indention level of the row. ChildStatus is 1 for the first child, 0 for a middle child, 2 for the last child and 3 if the item is an only child.
• the auction software module 115 determines the row indent level for an item. If the indent level is different from the last indent level in step 1015, the "Yes" branch is followed to step 1020 where the indent level is corrected.
• step 1025 the auction software module 115 identifies whether the current row is a root row.
• a root is the highest level of complexity for an item and has an indent level of 1. If the row is not a root row, the row contains a child and the "No" branch is followed to step 1030 where the appropriate indentation and symbol are inserted into the hierarchy to represent a child row. If the row is a root row, the row does not need to be indented and the "Yes" branch is followed to step 1035 where the appropriate symbol for a root row is inserted into the hierarchy.
• step 1040 the item name and quantity are inserted into the row in the hierarchy.
• the auction software module is now ready to move onto the next item which will be inserted into the next row in the hierarchy.
• step 1045 the auction software module 115 queries the tltem data structure 505 to ascertain whether the row that was just completed has children. If the row does have children, the "Yes" branch is followed to step 1050 where the hierarchy is adjusted to create a next row of children descending from the row just completed. If the row does not have children, the "No" branch is followed and the flow chart proceeds directly to step 1055 where the indent level is saved as the last indent level. The last indent level is saved so it can be used as a reference point for starting the next row.
• step 1060 the auction software module 115 queries whether there is another row to create. If so, the "Yes" branch is followed and returns to step 1010 where the indent level for the next row is determined. If there are no remaining rows to be created, the hierarchy is complete.
• the on-line auction environment involves many bidding clients 125, 130, and 135 entering pricing information for each element within the item structure. This involves the process of displaying the hierarchical item structure to the bidder in a format that will show the relationships between all the items and allow the bidder to enter bid quantity and bid price information for each item in the structure.
• FIG. 11 represents a screen from an exemplary graphical user interface 1105 for displaying the item hierarchy and collecting the quantity and price information for each item.
• This screen provides pertinent information related to the specific auction being conducted at the top of the screen. This includes information that the bidder will require in order to place an appropriate bid such as Starting Price, Bid Increment, Low Bid Price, Reserve Price, Time Remaining, Status, and Bid Count.
• the Bid Information displays the items within the hierarchy.
• the Bid Information display constructs the item hierarchy according to the process described in FIG. 10.
• the bidder enters the price and quantity information associated with each item in the structure. In one embodiment of the present invention, price and quantity cannot be entered for subassemblies as this information is automatically calculated from bids for larger assemblies.
• bids may be made directly on subassembly items.
• the price and quantity information can be processed to calculate the sub-total for each and every sub-assembly in the structure.
• a total bid can also be calculated by adding the total price for each of the children for the parent item.
• FIG. 12 shows the process for calculating the price for each sub-assembly and the total bid price so that competing bids can be evaluated. It begins by retrieving the bid data from the tBid data table 515 in step 1205. The page is initialized with arrays of row data based on the item hierarchy structure. All subtotals are initialized to zero in step 1210. In step 1215, the auction software module 115 queries whether the current row corresponds to the correct indent level. If there is no correspondence, the "No" branch is followed to step 1220 where the auction software module 115 looks to the next row for a match. This step is repeated until a match is found and, in step 1225, the auction software module 115 verifies whether the bidder's entry is valid. If the bidder has entered data in the wrong row or the price and quantity data is not in the correct format, a validation error will be displayed in step 1230 and the auction software module will start over by moving to the next row in step 1220.
• the auction software module 115 computes the row subtotal in step 1235.
• the auction software module queries for children. If there are children of this row, those prices will be added into the row subtotal in step 1245. Otherwise, in step 1250, the auction software module 115 looks to see if the row is a child. If the row is a child, its subtotal must be added to a preceding parent row in step 1255. The auction software module 115 then proceeds to step 1260, to examine any remaining rows. If there are remaining rows, the auction software module 115 returns to step 1215 to begin working on another row. If there are no remaining rows, the subtotals and grand totals are displayed, as shown in FIG.
• the auction software module 115 repeats the entire process for any other bidding clients. Once the subtotals and totals are computed for all bidding clients, the auction software module can compare the totals and select the winning bids. Winning bids will be determined by several factors including the particular auction type and to what level of subassembly separate bidding is permitted. These factors may vary from auction to auction.
• the present invention enables and supports the auctioning of complex items in a distributed computing environment.
• the invention allows an auction author to submit information about a complex item and its subassemblies that are to be auctioned to multiple bidders.
• the invention can present information about the complex item and its subassemblies in a manner suitable for an on-line auction.
• the invention can accept bids on the complex item and its subassemblies from multiple bidders and determine the winning bid or bids.
• the present invention fulfills the needs of the prior art described herein and meets the above-stated objects. While there has been shown and described the preferred embodiment of the invention, it will be evident to those skilled in the art that various modifications and changes may be made thereto without departing from the spirit and the scope of the invention as set forth in the appended claims and equivalence thereof.
• the present invention can support the auctioning of items other than complex goods such as complex services or contract options.
• the invention can also be used in commercial contexts other than an auction such as the sale of inventory or bidding on contracts where there are multiple components.

Landscapes

• Business, Economics & Management (AREA)
• Finance (AREA)
• Accounting & Taxation (AREA)
• Marketing (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Entrepreneurship & Innovation (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=26931515

Family Applications (1)

Country Status (11)

Families Citing this family (3)

• 2001
  • 2001-10-05 MX MXPA03002987A patent/MXPA03002987A/es unknown
  • 2001-10-05 AU AU2002211856A patent/AU2002211856A1/en not_active Abandoned
  • 2001-10-05 BR BRPI0114422-7A patent/BR0114422A/pt not_active IP Right Cessation
  • 2001-10-05 KR KR10-2003-7004863A patent/KR20030057534A/ko active IP Right Grant
  • 2001-10-05 JP JP2002533196A patent/JP2004529399A/ja active Pending
  • 2001-10-05 CN CNA018176615A patent/CN1470036A/zh active Pending
  • 2001-10-05 EP EP01979946A patent/EP1323107A2/en not_active Withdrawn
  • 2001-10-05 WO PCT/US2001/042485 patent/WO2002029698A2/en not_active Application Discontinuation
  • 2001-10-05 IL IL15522001A patent/IL155220A0/xx unknown
  • 2001-10-05 NZ NZ525146A patent/NZ525146A/xx unknown
  • 2001-10-05 CA CA002425234A patent/CA2425234A1/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events