On June 2, 2006 the Supreme Court of Canada released two landmark decisions dealing with the extent of protection available for famous trade-marks. While in both cases the owner of the famous mark did not prevail, the Court made several pronouncements that could assist owners of famous marks in future cases.

The first case involved opposition proceedings by Mattel Inc. Mattel argued that its well-known BARBIE trade-mark, which is registered and used in association with dolls and doll accessories, was confusing with the mark BARBIE’S & Design which was applied for and used in association with restaurant services.

In a unanimous decision, the Court held that in assessing confusion between two marks it must consider all the surrounding circumstances. Depending on the specific facts, the different circumstances will be given different weight. While the fame of a mark is important, it is only one factor and it does not trump all of the others. Also important is the difference in the respective wares or services associated with the trade-mark. However, the Court expressly overturned the prior Federal Court of Appeal decisions involving the PINK PANTHER and LEXUS marks, to the extent that those decisions held that such a circumstance will always be the dominant consideration and that there must be a resemblance or linkage between the respective wares and services in order for there to be confusion. Other important factors to be looked at include the inherent distinctiveness of the marks, the length of time the marks were used and the extent to which they have become known, the nature of the wares, services or businesses, the nature of the trade and the degree of resemblance between the marks.

On the facts, the Court found that there was a great degree of difference between the goods and services of the two parties and the nature of their trade in that they appealed to very different sets of clientele, namely young girls for BARBIE dolls and doll accessories versus adults for BARBIE’S & Design restaurant services. The Court noted that the BARBIE mark was not inherently distinctive since it was a person’s given name. While the BARBIE mark had gained significant secondary distinctiveness as a result of massive long-term marketing and sales, at this stage its fame is not enough to "bootstrap" a broad zone of exclusivity covering most consumer wares and services. The Court pointed out that Mattel had provided no evidence of actual confusion in the marketplace despite co-existence since approximately 1992.

The Court went on to state that in the right case a famous mark might transcend the boundaries of the goods and services for which it is primarily known and used.

The companion decision Veuve Clicquot Ponsardin v. Boutiques Cliquot Ltee. arose out of an infringement action. VEUVE CLICQUOT and related trade-marks were registered and used in association with an expensive and well-known brand of champagne and were held by the Court to be famous marks. The mark CLIQUOT was used by the defendant in association with a chain of clothing shops selling mid-range women’s fashions. In this case, the Supreme Court of Canada held that the fame of the VEUVE CLICQUOT marks was for champagne and that it might transcend to other luxury goods but it did not transcend to mid-priced women’s wear which was "as different as chalk and cheese" from champagne and other luxury goods. The Court also found that the circumstances of the channels of trade and distribution were different and that there had been apparent co-existence for ten years with no evidence of actual confusion led by the plaintiff.

In addition to infringement, the plaintiff in this case argued that the use of the CLIQUOT mark by the defendant depreciated the goodwill attached to the VEUVE CLICQUOT marks, contrary to Sectionof the Trade-marks Act. In order to find depreciation the Court held that a four-part test must be met:

1. The defendant must use the plaintiff’s registered mark or a similar mark in association with goods and services. Such goods and services need not be competitive and the defendant’s mark need not be identical to the plaintiff’s mark, but consumers must make a link, connection or mental association between the two marks;

2. The plaintiff’s registered mark must be sufficiently well known to have significant goodwill attached to it. The plaintiff’s mark need not be famous or well known to be protected under Section 22;

3. The plaintiff’s mark must be used in a manner likely to have an affect on its goodwill. This requires a likelihood that consumers will have a linkage or mental association between the two marks; and

4. The likely effect of the above linkage or mental association would be to depreciate the value of or damage the plaintiff’s goodwill.

The Court also used this opportunity to list various factors that would be used in determining goodwill for the purpose of Section 22, such as the fame of the mark, the degree of recognition of the mark within the relevant universe of consumers, the volume of sales and the depth of market penetration of the products associated with the mark, the extent and duration of advertising and publicity, the geographic reach, the degree of inherent or acquired distinctiveness, whether the channels of trade for the mark are narrow or specialized and the extent to which the mark is identified with a particular quality. Based on consideration of the above factors, the Court held that the VEUVE CLICQUOT marks had developed considerable goodwill.

In this particular case, however, while the plaintiff’s VEUVE CLICQUOT marks had clearly developed significant goodwill, the plaintiff failed to prove the other three parts of the test and thus was unable to prevail in its action based on depreciation.

The scope of protection available for famous marks in Canada is now arguably somewhat greater than it was before these decisions. However, it remains for a later case, and perhaps for a mark more famous than BARBIE or VEUVE CLICQUOT, to take advantage of that increased protection.

Many technology companies will, at one time or another, find themselves contracting for the development of proprietary software, either for incorporation into a product, or as the product itself. Often, a software development company (or, occasionally, a research institution) will be engaged for the purpose of developing a program integral to the purchasing company’s business. Generally, both purchaser and developer will be focused on the technical needs of the purchasing company, and on the contract price. In doing so, the parties often overlook the potential legal issues that can arise in the event that the product that is eventually developed does not fully meet the needs of the company that paid for it. While this is perhaps understandable, as contracts are entered into optimistically and the parties plan for their contracts to be completed successfully, the reality in the software development world is that projects do not always turn out as planned, and in such cases, the parties must be prepared for the consequences of this.

Recently, Clark Wilson LLP handled two large cases where clients were engaged to develop software products for high-tech companies. One case involved a commercial contract for the development of an Internet search engine and algorithm specific to the purchaser’s appraisal business. The other involved a research project in which the client was hired to create a program for the wireless transfer of data. Both cases involved relatively modest contract prices, and both projects were expected to be completed in relatively short timeframes.

Unfortunately, the purchasers of the software were unsatisfied with the final products and commenced legal proceedings against the software developers, seeking millions of dollars in lost revenue and opportunities. In both cases, the software developers ultimately succeeded, but only after lengthy and costly litigation which diverted energy and resources away from their businesses. Each of these cases, however, might have been avoided had the parties sat down before the project began to establish a realistic set of goals and expectations. The following are some general suggestions for avoiding litigation arising out of software development, a process which is necessarily subject to some degree of uncertainty.

(a) Address the Parties’ Expectations Up Front

As every programmer knows, any new software program will include its share of glitches, commonly known as "bugs". This is particularly true of systems which are either designed to perform new functions or to advance existing technology to new levels of performance. A simple discussion of the anticipated difficulties involved in the project at the outset can ensure that expectations are kept to a realistic level, and will reduce the potential for a dispute if difficulties are encountered down the road.

Ideally, a contract between the developer and its client should include a provision setting out the parties’ understanding of the anticipated results, along with an acknowledgement of the risks involved in the project. With an experimental project, a "reasonable efforts" clause might be the most appropriate provision, though the purchaser of the software will in most cases prefer something more concrete. A clause disclaiming any warranties of fitness for the purchaser’s intended use may also be appropriate, especially in a project of an experimental nature.

While the inclusion of such clauses will have to be negotiated, and may not prevent a dispute if the project does not turn out as planned, such clauses will provide crucial guidance to the court or trier of fact in determining whether the project was performed to the standard anticipated by the parties, and reduce the liability risks if a dispute cannot be avoided.

(b) Liquidated Damages

Where a software developer is engaged to produce a program that will form part of the purchaser’s ultimate product, any delay or failure to create exactly what was contemplated by the purchaser could lead to a claim for business loss that is extremely difficult and expensive to prove or disprove. One way to avoid such costly battles is to include a "liquidated damages" clause in the contract, which limits the amount recoverable in the event of a breach to a fixed amount, thereby capping the developer’s liability risk. These clauses are often attacked on the basis that the level of performance was so far below the expected level that it constitutes a "fundamental breach", thereby negating the entire contract, including the liquidated damages clause itself. However, provided that the developer creates what it was hired to create, albeit to a level below that expected by the purchaser, it will be difficult to show a fundamental breach, and a liquidated damages clause, if it contains a reasonable estimate of the expected damages, will usually be enforceable.

(c) Termination Clause

While the goal in entering any contract is always to complete the contract to the benefit of both parties, there are occasions, especially in the context of experimental or novel software development, where it will become apparent to one or both parties that the project is not moving as anticipated, and that it would be in the interests of one or both parties to simply abandon the project altogether. Where one party holds the view that the project cannot be completed as contemplated and the other disagrees, disputes can arise. To protect against such instances, a termination clause can be included in the contract, which allows for the termination of the project in certain circumstances. The specific circumstances that may give rise to termination will depend on the nature of the project.

(d) Ownership of the Technology

In most commercial situations, the purchaser of the software will become the sole owner of the technology, with the developer retaining either severely limited rights or no rights at all to its use. In the context of a research company or institution, the issue of ownership may be more complicated, with the developer retaining greater rights to further develop or exploit the technology and the purchaser obtaining some form of exclusive or non-exclusive license. The goals of each party in this regard should be addressed at the outset and included in the contract.

(e) Address Changes to the Contract in a Structured Way

Many contracts contain a standard term stating that any changes or modifications to the contractual duties of a party must be agreed to in writing and signed by both parties. This is a sensible requirement that can avoid all sorts of uncertainty, but it is also one that is ignored more often than it is followed. In one of the cases mentioned above, the parties agreed on several modifications of the project, by way of exchanging certain deliverables for new ones not included in the original contract. All these changes were made verbally, and not surprisingly, when the relationship between the parties broke down, there were disputes over what had been discussed and agreed to. In many software projects, the parties will come up with new ideas for improvement as matters progress, and often it will make sense for both parties to modify the deliverables originally agreed to. In such cases, it is always a good idea to confirm the change in writing and ask for an acknowledgement. While it is of course preferable to follow the contractual terms as set out, a simple exchange of e-mails confirming that one item has been modified in favour of another will also reduce uncertainty if a dispute arises.

(f) Obtain Insurance

Companies in the business of developing software products should maintain professional liability insurance, which will protect against claims of non-performance. Such policies are generally available on a "claims made" basis, which means that whenever it appears that a dispute may arise, the insurer must be notified (the policy should be reviewed for specific reporting requirements). Assuming a dispute is covered by the policy, the developer will be relieved from the cost of litigation, as the insurer will have a duty to handle and pay for the defence of the claim. This alone can be a significant advantage to a developer, as the costs of litigation can be substantial.

(g) Dispute Resolution Clause

Because there is always a chance that disputes will arise in the course of a software development project, it is advisable for the parties to spell out in their agreement a process for handling those disputes. Ideally the process will include a mechanism for internally escalating disputes that cannot be resolved by the primary contact persons. If the escalation procedure does not solve the dispute, mandatory arbitration may be a better course of action than relying on the Courts for two primary reasons: speed of resolution and keeping the dispute private. The public Court system is heavily backlogged at the moment and Court dates are typically taking two to three years to obtain. Also, it is normally in both parties’ interest to keep any dispute out of the public eye, which is generally not possible with a Court proceeding.

Conclusion

The matters discussed above are a sampling of issues that should be addressed when entering into a software development or integration project. The list is not meant to be exhaustive, and many other concerns may arise in a given situation. However, these issues are sufficiently general that they should be addressed in most, if not all, contracts, with the goal of avoiding a serious dispute if the contract does not proceed as planned.

For companies in the business of developing software products, it is recommended that a standard form contract be developed which includes the terms discussed above. Even if the form is modified through negotiation on a project-by-project basis, a standard contract will provide a starting point and will ensure that the issues are in the minds of the contracting parties. This, it is hoped, will reduce the potential for costly litigation in the event the project goes sideways. While the above suggestions will not prevent litigation in every situation, if the issues are addressed at the time a contract is entered into, the risk of litigation can be significantly reduced.

Please contact any member of our Technology and Intellectual Property Group to discuss any matters related to software development and contractual issues.

.mobi is a new top-level domain approved by ICANN, the Internet Corporation for Assigned Names and Numbers, and is aimed at directing users to sites and services accessed through mobile devices.

During the Sunrise Period, eligibility for a .mobi domain name registration is based on a trade-mark registered before July 11, 2005 or on a trade-mark application whose filing date is prior to July 11, 2005 but where registration is granted before the domain name is registered.

The Sunrise Period ends August 21, 2006. After September 27, 2006, General Registration commences and .mobi domain name registrations will be open to everyone. This period commences with a period known as Landrush, during which available .mobi domain names may be registered at premium prices.

Please contact any member of our Technology and Intellectual Property Group to discuss any matters related to .mobi domain name registration.

If you would like to be added or removed from this mailing service, please send requests to webmaster@cwilson.com.

KNOWLEDGE BYTES VIA EMAIL