Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L49/00—Packet switching elements
  • H04L49/90—Buffering arrangements

Definitions

• any of the functions described with reference to the figures can be implemented using software, firmware (e.g., fixed logic circuitry), manual processing, or a combination of these implementations.
• the term “logic, “module” or “functionality” as used herein generally represents software, firmware, or a combination of software and firmware.
• the term “logic,” “module,” or “functionality” represents program code (or declarative content) that performs specified tasks when executed on a processing device or devices (e.g., CPU or CPUs).
• the program code can be stored in one or more computer readable memory devices.
• the illustrated separation of logic, modules and functionality into distinct units may reflect an actual physical grouping and allocation of such software and/or hardware, or can correspond to a conceptual allocation of different tasks performed by a single software program and/or hardware unit.
• the illustrated logic, modules and functionality can be located at a single site (e.g., as implemented by a processing device), or can be distributed over plural locations.
• Fig. 1 shows an exemplary system 100 for queuing events and then further advancing the transactions based on those queued events.
• the exchange of information between the components shown in Fig. 1 can be governed by any technology, such as, but not limited to, Universal Plug and Play (UPnP) technology.
• UFP Universal Plug and Play
• the system includes a collection of devices, including a media server 102, and one or more remote media devices (104, ... 106).
• the devices (102, 104, ...
• a "recipient-user” interacts with the representative remote media device 104, while a “follow-up user” interacts with the media server 102.
• the recipient-user may represent the same individual as the follow-up user, or may represent a different individual.
• the "users” may pertain to automated agents (e.g., logic functionality) which automatically perform the roles of individuals.
• the. media server 102 forwards information to one or more remote media devices (104, ... 106).
• One of more control points orchestrate the exchange of information among the components shown in Fig. 1.
• a control point can be integrated with any of the components shown in Fig.
• the media server 102 can represent any kind of device with processing capabilities.
• the media server 102 can be implemented by a personal computer, or other kind of computer.
• the functionality of the media server 102 which handles events generated by the remote media devices (104, ... 106) is referred to as an event handling module 110.
• the event handling module 110 can be implemented in software, hardware, a combination of hardware and software, and so on.
• the remote media devices (104, ... 106) can likewise represent any kind of device. In many cases, although not necessarily, the remote media devices (104, ... 106) represent devices that have fewer processing resources compared to the media server 102. In other words, the remote media devices (104, ...
• the 106) may represent "thin devices" (meaning that they have reduced processing resources compared to the media server 102).
• Exemplary types of remote media devices include any kind of portable or wearable processing device, a mobile telephone device, a set-top box, a game console, an audio playback device, an interactive television, an intelligent appliance, and so on.
• the functionality of the representative remote media device 104 which generates events for transmission to the media server 102 is referred to as an event generation module 112.
• the event generation module 112 can be implemented in software, hardware, a combination of hardware and software, and so on.
• the recipient-user can interact directly with a remote media device, such as remote media device 104. Or the recipient-user can interact with the remote media device 104 via some other device, such as exemplary remote control device 114.
• the remote control device 114 may itself comprise a device which is governed by UPnP technology. More specifically, the remote control device 114 can serve the role of a UPnP control point within the system 100.
• the network 108 can represent any kind of channel or combination of channels for exchanging information among devices. It can represent a local area network (LAN), a wide area network (WAN), or combination thereof. It can be physically implemented using any kind and combination of links, such as hardwired conductive links, wireless links, power lines, and so forth.
• the network 108 can also include any combination of network-related equipment, such as various routers, gateways, name servers, and so forth. Any kind of protocol or combination of protocols can be used to exchange information over the network 108, such as TCP/IP, SOAP, GENA, HTTP, and so on.
• the bolded arrows shown in Fig. 1 convey an overview of one exemplary manifestation pf the event queuing strategy.
• the queuing strategy is explained in terms of an interaction between the media server 102 and the representative media device 104:
• the media server 102 sends information to the remote media device 104.
• This information notifies the recipient-user of some resource concerning which the recipient-user may perform some action, and is thus referred to as "notification information" herein.
• This term should be broadly construed.
• the notification information can include specific instructions which invite the recipient-user to perform some action pertaining to a resource.
• the notification information may comprise a presentation of the resource itself, or some sample thereof (such as one track of a music album that may be purchased).
• the media server 102 can send the notification information to a recipient-user in unsolicited fashion (in the manner of random pop-up advertisements).
• the media server 102 can send the notification information to a recipient-user that fits into the context of the recipient-user's current interaction with the remote media device 104.
• the media server 102 can send notification information to the remote media device 104 in response to a request from the recipient-user (such as a browse or search request, made by the recipient-user). Still other approaches for sending notification information to the recipient-users are possible.
• the media server 102 can send a response to the remote media device 104 that identifies album art. More specifically, the media server 102 can return the exemplary metadata information:
• This metadata information comprises a link which points to album art resources located on the media server 102 (or located elsewhere), and enables the remote media device 104 to access and display the album art.
• This display operation can be performed in an automatic fashion (if the recipient device is appropriately equipped to display the album art) or can be performed optionally at the discretion of the recipient-user.
• an album art tag can be embedded inside an outer tag which describes a single media resource (such as a single song).
• the album art can represent the cover art for the album that includes the song as part of its contents.
• a single song can have multiple album art tags associated therewith. These multiple tags can present the same album art in different sizes, formats, and so forth, or the tags can possibly represent different albums that include the same song.
• the remote media device 104 can present the notification information in any manner, such as by automatically displaying it in a peripheral region of its display, a main region of its display, and so forth. Or the remote media device 104 can display the notification information as a hypertext annotation that can be activated by the recipient-user at their discretion to receive more information, and so forth. Still alternatively (or in addition), the remote media device can audible present the notification information, such as by presenting a message, "If you like this music, why not buy it?"
• the media server 102 can selectively send the notification information to only recipient-users who are pre-authorized to act on the information.
• the system 100 can maintain a database (not shown) which describes the characteristics of the devices in the system 100. The characteristics can be expressed using device profiles.
• the media server 102 can access this database to determine which devices are pre-authorized to receive the notification information, and then disseminate this information to only those devices that are pre-authorized to receive this notification information.
• the media server 102 can send notification information to all remote media devices (104, ... 106) without restriction, but only enable pre-authorized media devices to perform actions based on this information.
• the recipient-user In the most general terms, the recipient-user generates the commencement action by having some knowledge about the object which the user is acting on, and this knowledge can be imparted to the user in a great variety of direct and indirect ways.
• the recipient-user performs some action pertaining to a target object (e.g., comprising a resource identified by the notification information). Because this action initiates a transaction, it is referred to as a "commencement action" herein.
• a non-exhaustive list of possible commencement actions follows: • A recipient-user can issue an instruction to purchase a particular resource associated with the notification information.
• the notification information may include pictorial album art which identifies a music album that the recipient-user can purchase, or perhaps a musical excerpt from that album. In response to receiving this notification information, the recipient-user can issue an instruction to purchase that album. The recipient-user can purchase any other kind of resource in a similar manner.
• a recipient-user can issue an instruction to cancel a prior purchase request pertaining to an identified resource.
• a recipient-user can issue can instruction to create a reservation for a particular resource, such as hotel room, rental car, and so forth.
• a recipient-user can issue an instruction to print a particular resource identified by the notification information. For example, the recipient-user might be browsing through a collection of photo images. Upon finding a photo of interest, the recipient-user can issue an instruction to print this photo. In a similar manner, the recipient-user can issue an instruction to forward a resource to an identified target destination. For example, the recipient-user can flag a photo to be sent to her sister, and so forth.
• a recipient-user can issue an instruction to perform processing on an identified resource. For example, the recipient-user can issue an instruction to rotate a photo, crop a particular photo, change the coloring and/or brightness of a photo, remove redeye from a photo, and so forth.
• a recipient-user can issue an instruction to change the status of an identified resource. For example, consider the scenario in which the recipient-user is browsing through Emails on the remote media device 104. The recipient-user can issue an instruction to archive one of these Emails (to move the Email to long term storage), and so forth.
• a recipient-user can issue an instruction to back up an identified resource (e.g., a file) at the media server device 102 (or some other target device).
• an identified resource e.g., a file
• the recipient-user can issue an instruction through any kind of input mechanism.
• Possible types of input mechanisms include: physical control mechanisms (such as physical buttons, sliders, knobs, keyboards, joysticks, track balls, touch sensitive screen elements, data gloves, etc.), UI control mechanisms (such as graphical buttons, sliders, knobs, etc.), voice activated input mechanisms, and so forth.
• Fig. 3 to be discussed in turn, provides additional information regarding exemplary mechanisms that allow the recipient-user to perform a commencement action.
• Fig. 1 shows one scenario in which the recipient-user receives notification information via the remote media device 104, and then performs a commencement action using the same remote media device 104.
• the recipient-user can receive notification information via the remote media device 104, but can then perform the commencement action using some other device, such as remote control device 114.
• the remote control device 114 can include a series of physical or UI buttons that allows the recipient- user to perform a commencement action, based on notification information presented by the remote media device 104.
• the recipient-user may be listening to a sample of an album via the remote media device 104, and then issue an instruction to buy the entire album associated with the sample by actuating a button on the remote control device 114.
• a first remote device can present a sample of a musical piece
• a second remote device can present album art
• a third remote device can be used to issue a buy event.
• An event is created in response to the recipient-user's commencement action.
• An event refers to any kind of information which describes the commencement action, and which can be propagated to another device to alert that device to the nature of the action.
• the event can comprise at least two parts.
• a first part identifies the object that is the target of the event. For example, if the user seeks to perform some action on a resource, or to purchase the resource, then the object comprises the resource itself.
• a second part identifies the action to be performed on the object. Exemplary actions mentioned above include: the purchase of the object; the printing of the object; the transfer of the object to an identified recipient; the resizing, cropping, redeye reduction, etc. of the object, and so forth.
• the different actions can be represented using different respective codes, or by some other technique.
• the media server 102 receives the event and optionally logs the event in an event store.
• the follow-up user accesses the media server 102 to process any logged events.
• the follow-up user refers to anyone who completes the transaction initiated by the recipient-user. In one case, the follow-up user is the same as the recipient-user.
• the follow-up user is actively engaged with the media server 102 at the time that the event is received.
• the media server 102 can immediately notify the follow-up user of the receipt of the event (and, in which case, it may not be necessary to also log the event).
• the follow-up user may not be actively engaged with the media server 102 at the time that the event is received. This may be because the follow-up user is logged off of the computer which implements the media server 102, or because the follow- up user is not engaged in an active session with the media server, e.g., in the case where the computer supports Fast User Switching (FUS), etc.
• FUS Fast User Switching
• the media server 102 can alert the follow-up user to the existence of any events that have been received during their "absence" (however defined).
• the media server 102 can alert the follow-up user to the existence of the events in various ways, such as by providing graphical information, audio information, some combination thereof, and so forth.
• the media server 102 can alert the follow-up user to the existence of the events by providing a graphical bubble message.
• the information which the media server 102 imparts to the follow-up user is referred to as "prompting information" herein, to indicate that this information prompts the follow-up user to complete the transaction started by the recipient-user at the remote media device 104.
• the media server 102 can be configured to send prompting information to only authorized follow-up users. For example, assume that a parent acts in the role of a recipient-user by flagging certain resources to receive some kind of subsequent processing. These resources may be inappropriate for viewing by all members of the family, or it may be in appropriate for all members of the family to actually complete a financial transaction. Assume that a child of the parent logs onto the media server 102 as a follow-up user. The media server 102 can be configured to determine the identity of this user (e.g., based on the user's password), and determine whether this user is authorized to complete a transaction initiated by the recipient-user parent. This verification operation can be performed by consulting a database to determine whether the particular user is authorized to receive prompting information. In this manner, the media server 102 can prevent the child from receiving the prompting information.
• a parent acts in the role of a recipient-user by flagging certain resources to receive some kind of subsequent processing. These resources may be inappropriate for viewing by all members of the family, or it may be in
• the follow-up user can respond to the prompting information by activating it, e.g., by clicking on the graphical presentation of the prompting information.
• This can invoke one or more user interface presentations which allow the follow-up user to complete the transaction(s) or at least further advance the transaction.
• the media server 102 can invoke one or more user interface presentations which allow the user purchase resources, perform processing on resources, and so forth.
• These presentations can be hosted by the media server 102 itself or some third party entity, possibly accessible through a wide area network connection, or by some combination of presentations hosted by a combination of the media server 102 and third party entity.
• the media server 102 can present the follow-up user with a user interface presentation which gives the user the option of advancing with a sales transaction.
• the media server 102 can direct the user to a website hosted by a commercial entity which is selling the resource.
• the action taken by the follow-up user in further advancing the transaction that was initiated by the recipient-user is referred to as a "follow-up action" herein.
• the follow-up action can represent the final step in a transaction, or can represent another non-terminal step in a series of actions that comprise the transaction.
• the remote media device 104 is a separate device than the media server 102.
• the remote media device 104 can represent a thin client, meaning that it has reduced processing resources compared to the media server 102.
• the approach described above allows a relatively simple remote media device to incorporate more complex services, that is, by using the remote media device to flag transactions to be later completed by the more versatile media server 102. This strategy allows the remote media device to remain simple in design, yet incorporate advanced services.
• the four actions (1-4) described above can play out in the context of a single device. For example, a user can log an event using a first device, and then later return to the same device, access the logged event, and complete the transaction based thereon.
• FIG. 2 shows a more detailed depiction of the event processing module 110 deployed in the media server 102.
• the event processing module 110 includes a number of modules and data stores.
• a notification dissemination module 202 sends notification information to the recipient-user.
• the notification information can comprise any information which can somehow prompt the recipient-user to take an action.
• the notification information can alert the recipient-user to the existence of a resource, and the recipient-user can perform a commencement action pertaining to that resource. The commencement action generates an event.
• An event receiving module 204 receives the event created by the recipient- user. As explained above, the event may have two parts: a first part describes the object of the action; and a second part describes the action itself. The event- receiving module 204 can also optionally log the received event.
• An action advancement module 206 allows the follow-up user to further advance a transaction initiated by the recipient-user (again, the follow-up user can represent the same user as the recipient-user). For instance, the advancement module 206 can alert the follow-up user to the existence of one or more logged events. It can perform this task by sending prompting information to the follow-up user.
• a registration module 208 allows an administrative user (not shown) to set various operating parameters and other information that governs the operation of the event processing module 110. For example, the registration module 208 can allow the administrative user to set the conditions under which notification information is sent to the recipient-user, conditions under which prompting information is sent to the follow-up user, and so forth.
• a content information store 210 stores information that is disseminated to the users, such as notification information sent to the recipient-user, prompting information sent to the follow-up user, and so forth. This store can be implemented by the media server 102 itself, or some other entity (such as a remote website).
• a condition information store 212 stores information that governs the operation of the event processing module 110. For example, the condition information store 212 can store conditions under which notification information is sent to the recipient-user, conditions under which prompting information is sent to the follow-up user, and so forth.
• the user action information store 214 can store events received from remote media devices (104, ... 106). Such events can describe the target objects of the events, as well as the nature of the actions themselves. The user action information store 214 can store events on a user-by-user basis.
• the remote media device 300 can include one or more graphical UI controls (e.g., UI control 306) and/or or more physical controls (e.g., physical button 308) for allowing the user to generate an event.
• UI control 306 graphical UI controls
• physical controls e.g., physical button 308
• the remote user device 300 can include a buy button (or other kind of control).
• the remote user device 300 can include a print button, a rotate button (to rotate a photo), a redeye removal button (to remove redeye from the photo), and so forth.
• Fig. 4 shows an exemplary mechanism for providing prompting information.
• a personal computer 402 implements the media server 102.
• the personal computer ' 402 includes a graphical user interface which displays prompting information 404.
• the prompting information 404 takes the form of a graphical bubble message which alerts the follow-up user to the fact that they have events waiting for their attention. It is possible to present the prompting information in many other ways, such as by providing audio information, and so forth.
• the media server 102 can orchestrate the handling of follow-up actions (involving the presentation of prompting information based on queued events) through an automated playback routine (such as AUTOPLAY functionality of WINDOWS, provided by Microsoft corporation of Redmond, Washington).
• an automated playback routine such as AUTOPLAY functionality of WINDOWS, provided by Microsoft corporation of Redmond, Washington.
• Fig. 5 shows an exemplary user interface presentation 500 that can be invoked when the follow-up user activates the prompting information 404.
• the logged events pertain to purchase events.
• the user interface presentation 500 can list the purchase events and give the user an opportunity to complete these purchase events by actually buying the identified resources (or declining to purchase the resources).
• entry 502 in the presentation 500 identifies that the recipient-user expressed an interest in buying an album of Bach piano concertos. This entry 502 allows the user to find out additional information regarding this album, or to confirm purchase by actually buying the album. Clicking on any button in the entry 502 can optionally direct the follow-up user to a website which will actually handle the sale of the identified asset.
• Fig. 6 shows another exemplary user interface presentation 600.
• This presentation 600 emphasizes that the system 100 can be applied to many kinds of actions. For example, entry 602 gives the follow-up user the option to complete a print operation. Entry 604 gives the follow-up user the option to complete a redeye reduction operation. Entry 606 gives the follow-up user the option to complete an Email handling operation. Those skilled in the art will appreciate that many other operations are possible.
• Fig. 7 shows an exemplary XML excerpt (LobObjectEvent) that can be used to define the protocol for exchanging event information between the remote media device 104 and the media server 102.
• the excerpt defines the composition of an event, which includes a first part that identifies the target object of the action (ObjectID), and a second part which identifies the action itself (E ventType).
• Figs. 8-10 show procedures (800, 900, 1000) that explain an exemplary manner of operation of the system 100 shown in Fig. 1.
• certain operations are described as constituting distinct steps performed in a certain order. Such implementations are exemplary and non-limiting. Certain steps described herein can be grouped together and performed in a single operation, and certain steps can be performed in an order that differs from the order employed in the examples set forth in this disclosure. As the operations described in these flowcharts have already been explained in the context of architecture of the system 100, this section will serve primarily as a review of those operations.
• Fig. 8 shows a procedure 800 that allows an administrative user to set up various parameters and other information which govern the operation of the system 100.
• the administrative user can set various conditions which govern the dissemination of notification information, prompting information, and so forth.
• step 804 the administrative user can register content to be disseminated when the conditions defined in step 802 are met.
• the administrative user can define notification information (e.g., album art), prompting information (e.g., prompting bubble messages), and so forth.
• notification information e.g., album art
• prompting information e.g., prompting bubble messages
• Fig. 9 shows a procedure 900 that describes the solicitation, receipt and logging of an event (from the standpoint of the media server 102).
• the media server 102 determines whether to send notification information to the remote media device 104. For example, the media server 102 can ensure that only pre- authorized remote media devices receive notification information, or only pre- authorized remote media devices are allowed to respond to the notification information.
• the media server 102 sends the notification information to the remote media device 104.
• the media server 102 receives an event in response to the notification information, indicating that the recipient-user has performed some commencement action in response to the notification information.
• the media server 102 logs the received event in its event store (e.g., the user action information store 214 of Fig. 2).
• Fig. 10 shows a procedure 1000 that describes the processing of the logged event.
• the media server 102 determines whether it is appropriate to send a particular follow-up user the prompting information. Recall that the prompting information alerts to the follow-up user to the existence of the logged event.
• the media server 102 sends the follow-up user prompting information.
• the media server 102 receives a response from the follow-up user that indicates that the follow-up user has activated the prompting information, e.g., by clicking on a graphical representation of the prompting information.
• the media server 102 coordinates the advancement of the transaction that was initiated by the recipient-user. This step may involve eventually contacting a site which allows the follow-up user to execute the action, such as by purchasing an identified resource.
• the above discussion featured systems and procedures for handling transactions in a split manner, where part of a transaction is performed with respect to a device which serves a first role, and another part of the transaction is performed with respect to a device which serves a second role.
• the transaction was driven by one or more human users by virtue of their interactions with the devices.
• the devices were described in the exemplary and non-limiting context of UPnP media rendering devices and media server devices, or any kind of related components.
• a first device 1102 can maintain a first set of resources in a first data store 1104, and a second device 1106 can maintain a second set of resource in a second data store 1108.
• These resources can represent any kind of assets, such as files, etc.
• At least some resources in the first data store 1104 may represent the same resources stored in the second data store 1108, such that these data stores (1104, 1108) maintain redundant copies of the same resources.
• the purpose of the resource synchronization operation is to ensure that changes made to the first data store 1104 are duplicated in the counterpart resources contained in the second data store 1108 (and vice versa).
• a change made to a resource in the first data store 1104 can constitute a commencement action that invokes the generation of an event.
• the event can specify the nature of the resource that is being modified (or perhaps a copy of the resource itself), as well as a description of the change being made to the resource.
• This event can be sent to the second device 1106 by the first device 1002 in the manner described above.
• the second device 1106 can log this event in the manner described above.
• the second device 1106 can operate on the event immediately upon receipt of the event, or it can act on the event when the follow-up user resumes an active session with the second device 1106. Acting on the event can constitute duplicating the changes made in the first data store 1104 to at least one counterpart resource stored in the second data store 1108.
• reaction comprises a transformative act which is performed at the first device 1102 followed by a transformative act which is performed at the second device 1106.
• Resource synchronization is not limited to two sites (as in Fig. 11).
• a change made to any device can be duplicated in any number of other devices through the above-described eventing protocol.
• a device which serves a first role e.g., a first device
• a device which serves a second role e.g., a second device
• the first device and the second devices are not limited to media rendering devices and media server devices. Nor are these devices limited to UPnP devices.
• the impetus driving the transactions need not represent human user actions.
• Various actions can be performed in response to automatic triggering events, or at least in part in response to automatic triggering events. Still additional applications and variations of the above-described principles are possible.

Landscapes

• Engineering & Computer Science (AREA)
• Physics & Mathematics (AREA)
• Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• General Business, Economics & Management (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Finance (AREA)
• Economics (AREA)
• Accounting & Taxation (AREA)
• Development Economics (AREA)
• Databases & Information Systems (AREA)
• Mathematical Physics (AREA)
• General Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Data Mining & Analysis (AREA)
• Information Transfer Between Computers (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Telephonic Communication Services (AREA)
• Facsimiles In General (AREA)

Priority Applications (7)

Applications Claiming Priority (2)

Publications (2)

Family

ID=37695543

Family Applications (1)

Country Status (12)

Families Citing this family (16)

Family Cites Families (55)

• 2005
  • 2005-07-29 US US11/192,510 patent/US20070027808A1/en not_active Abandoned
• 2006
  • 2006-07-14 AU AU2006279124A patent/AU2006279124A1/en not_active Abandoned
  • 2006-07-14 CN CNA2006800266780A patent/CN101228548A/zh active Pending
  • 2006-07-14 EP EP06787194A patent/EP1913552A4/en not_active Withdrawn
  • 2006-07-14 RU RU2008103272/09A patent/RU2008103272A/ru not_active Application Discontinuation
  • 2006-07-14 BR BRPI0613048-8A patent/BRPI0613048A2/pt not_active IP Right Cessation
  • 2006-07-14 KR KR1020087002237A patent/KR20080035586A/ko not_active Withdrawn
  • 2006-07-14 WO PCT/US2006/027253 patent/WO2007018961A2/en not_active Ceased
  • 2006-07-14 MX MX2008001153A patent/MX2008001153A/es not_active Application Discontinuation
  • 2006-07-14 CA CA002613051A patent/CA2613051A1/en not_active Abandoned
  • 2006-07-14 JP JP2008523921A patent/JP2009503681A/ja not_active Withdrawn
• 2007
  • 2007-12-20 NO NO20076577A patent/NO20076577L/no not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events