So You Want to Negotiate A High-Tech Deal

 

I have been practicing law for approximately 25 years and concentrating my practice in the area of negotiating and drafting contracts for the purchase or sale of High Technology for the last 13 years. I recently came across Mark Grossman’s guest blog posting in IP In Brief entitled, “A How-To Guide for Negotiating Tech Deals”. This is a must read. If you are considering making any high-tech purchase, I highly recommend that you take the time to read this article in order to gain an insight and perspective that is little discussed but impacts your deal greatly. As a practitioner in this area, I found myself one early Saturday morning sitting in my office reading Grossman’s article and shouting “Yes, Yes, Yes”. I was fist-pumping and if anyone was near to me they would have gotten a high-five. His approach is straight-forward and no nonsense.

Andrew Berger’s introduction sets the stage and reveals to the reader for the first time the concepts of “unwritten industry norms” and “choreographing your concessions around areas where you’re not likely to win the battle anyway”. Grossman starts his analysis by pointing out the obvious (i.e. the first drafts of the agreements are poorly written). I think this was my first “Yes” that I heard myself say out loud while reading in my office all alone. I can’t tell you how many times I’ve received new templates or first drafts of proposed new agreements which were simply a mishmash of cuts and pastes from older useless documents. My second “Yes” and my first fist-pump was Grossman’s admission that the sales teams are in charge of the deal. I freely admit, and in the spirit of full disclosure I happily accept that the sales team is the entity that brings the deal to me. Without them I would be out of work. However, Grossman points out, without actually stating it, that the sales team views the attorney as an obstacle that must be overcome. Perhaps it was the way he explained the process of requesting a revision to some contract language to more accurately describe the issue and then commented,

“All the while, I can feel the sales team seething at me because of my absurd requirement that the contract accurately state the deal”.

That comment garnered fist pump number two and a loud chuckle. I would have enjoyed it if Grossman had discussed the mirror image on the buy side. I have represented both Buyers and Sellers. By the time the deal comes to me from the buy side (i.e. the Project Team), there is what is commonly called a “love affair” with the functionality of the proposed software package. In essence the Project Team “has been sold” and they know that they cannot live without having this software in their repertoire.   As an attorney, I get that same glare from the Buyers when revisions for clarity are requested.

Grossman has a very salient section on the “Norms in the Industry”. To put it simply, why waste your time arguing points that will not be changed. These “Norms” need to be understood simply due to their peculiarity. He has an excellent section explaining Warranties in the industry and how they differ from what would be expected. Limitations on Liability is another section worth reading because it goes against what a Buyer expects and readily requires from its vendors. I must confess it was good for me to read these sections simply because I have been so inculcated with these industry “Norms” that I needed a refresher on why outsiders would consider these absurd.

He concludes his article by stressing the practical side of mutuality. A software vendor can and usually does readily accept revisions to sections to make the obligations mutual. One must remember that the parties are usually starting from paper that was first drafted by the vendor and so the natural urge to make the language one-sided must be addressed and overcome where possible.

 

Is Software Patentable

 

Recently, I was attending a get together of some old school friends from my youth. We try to see each other every once and a while. I was chatting with a friend of mine and invariably the question is raised “Well Sam, what is it that you actually do”. Having fielded this question before I said, as I have many times in the past, “I negotiate and draft contracts for the licensing of software and I also draft the consulting contracts to implement that software”. My friend, who is a software engineer and a very intelligent man, countered with “I thought you couldn’t get a patent for software”. He relayed his experience of 15 years hence writing code for software games and not being allowed to patent the algorithms. Well, he had me back on my heels and flat-footed. I wasn’t sure how to answer him. I relied on my experience as a Law Professor and being asked questions where I did not have the answers at my finger tips. The secret is to ask rhetorical questions in a sort of Socratic manner and get to the answer. I did not feel comfortable at first stating definitively that “Yes, of course software can be patented”. My discomfort came from the knowledge of asking this very question in the past and not getting a conclusive and authoritative response. So I began asking the questions and stating that when I draft a software license and I am representing the buyer I include indemnification language to protect my client similar in tone to the following:

“Seller shall indemnify Buyer against all claims, liabilities, and costs, including reasonable attorneys' fees, reasonably incurred in the defense of any claim brought against Buyer by third parties alleging that Buyer's Use of the Software infringes or misappropriates any United States patent; a copyright; or trade secret rights, provided that: such indemnity shall not apply if the alleged infringement results from Use of the Software in conjunction with any other software, an apparatus other than a designated apparatus, or unlicensed activities and so long as Buyer promptly notifies Seller in writing of any such claim and Seller is permitted to control fully the defense and any settlement of such claim as long as such settlement shall not include a financial obligation on Buyer.   Seller may settle any claim on a basis requiring Seller to substitute for the Software alternative substantially equivalent non-infringing programs.”

And when I am representing the Seller I include language in the license to protect my client that limits its liability for any claims of patent infringement with language similar in tone to the following:

“Buyer's sole and exclusive remedies for any damages or loss in any way connected with the Software furnished by Seller, whether due to Seller's negligence or breach of any other duty, shall be, at Seller's option: (i) to bring the performance of the Software into substantial compliance with the functional specifications; (ii) re-performance of services; or (iii) return of an appropriate portion of any payment made by Buyer with respect to the applicable portion of the software or services. Seller will not be responsible under this Agreement if the Software is not used in accordance with the documentation; or (ii) if the defect is caused by Buyer, a Modification, third-party software, or third party database. ANYTHING TO THE CONTRARY HEREIN NOTWITHSTANDING, EXCEPT FOR DAMAGES RESULTING FROM UNAUTHORIZED USE OR DISCLOSURE OF PROPRIETARY INFORMATION, UNDER NO CIRCUMSTANCES SHALL SELLER, OR BUYER BE LIABLE TO EACH OTHER OR ANY OTHER PERSON OR ENTITY FOR AN AMOUNT OF DAMAGES IN EXCESS OF THE PAID LICENSE FEES.”

So this little exercise helped me to raise my confidence level in order to respond to my friend that yes in the US software is patentable. But just why is there such an open question on this issue. There is no definition of software from the US patent office.   As of today in the US it is readily accepted that software embodied in a physical computer readable medium and aiding an innovative process or machine is considered patentable. If you seek such a patent you must “subtly claim the software as employing or performing certain functions or processes and as embodied in a computer readable medium”. Please see http://ezinearticles.com/?A-Soft-Introduction-to-Software-Patents&id=593392

“Software patents have a very recent history as the first software patent granted was in 1981, in the legal case of Diamond v. Diehr. The claimed invention is a heat treatment of rubber, wherein software code is employed to compute the optimum time duration for the treatment. In another case of State Street Bank & Trust v. Signature Financial Group, a software business method was granted a patent in the year 1998, redefining software patentability. Software patentability has been a topic of debate world over. The first question an inventor, who wishes to patent his invention, asks is "Is software patentable". The short answer is that the US patent office does grant software patents, and there has been a surge in software patenting in the US.” Id.

In my research I found some very interesting facts.

·         A classification of software patents is virtually nonexistent, although a majority of recent patents are software patents based on the above criteria and

·         There are about 1400 patents purely on computational software.

·         IBM possesses 31,995 US patents.

·         HP possesses 21,000 patents worldwide as on 2003.

·         Microsoft possesses 5000 US patents.

·         Siemens possesses more than 10,000 issued and pending US patents.

·         In the USPTO database there are about 25,123 claimed software patents and about 284,978 granted patents that disclose the use of software in their inventions.

For further reading on this subject please see several articles listed at the following URL http://ezinearticles.com/?expert=Ash_Tankha

Please note that the above discussion is on US patents only. In Europe this is still an open question. See European Patent Office quiet on whether software can have a patent. And in Asia and the rest of the world it is anybody’s guess.

 

4 Tips on How to Start a Software Company and Succeed

 

Shashikant Chaudhary is the current Vice President of GlobalLogic (formerly known as IndusLogic).  He recounts his journey from founder of Lambent Technologies, a provider of mobile solutions, through his trials and tribulations as the company grew, to the eventual sale of his company in an opinion article in SandHill.com entitled Growing a Software Company on a Shoestring.   Along the way he developed what he considers the 4 most important points that any software entrepreneur should keep in mind on his/her way to financial success.  Isn’t this everyone’s dream?  Doesn’t everyone wish they could start a software business, watch as it builds to a crescendo and then sell it on the upswing?  Bet you thought all you’d have to do is read this posting, take note of a few tips and/or tricks, and soon you would be rolling in the money faster than you could count it.  Well they are no guarantees in life.  In fact I have this Blog loaded with disclaimers, but let me add just one more: the 4 tips included in this posting do not guarantee success.  These tips are merely a recounting of how one person did in fact start a company and helped it grow and then eventually cashed out.  I do admit that his story is quite compelling and his “Tips” although not groundbreaking theory, do provide any interesting twist to some age old formulas.  When writing this posting for this Blog I wasn’t quite sure which category to place it in because it is only tangentially related to software licensing and outsourcing.  The story of the business discussed and how it grew and was eventually sold has an element of Telecom, but I decided that it is most likely best considered as “Other Interesting Items” and so that is how this posting wound up here.

I like that Chaudhary starts off in his article by identifying the stakeholders in his business as the employees, investors, and customers.  Too many times business people center their efforts on the investors (usually shareholders in a publicly traded company) and relegate the employees to a second tier.  Customers are sometimes not even considered stakeholders.  They occupy some other category maybe on a par with stakeholders, but not quite the same.

Chaudhary wastes no time and dives right in with his 4 key success factors for the software services entrepreneur.  These 4 key success factors are:

·         Talent:  Putting together the right team is essential

·         Employee Loyalty:  One must be able to keep the talent.  Chaudhary used an innovative stock plan to keep his employees loyal.

·         Find your niche:  As a small company Chaudhary took some inspiration from Al Ries and Jack Trout, authors of “Marketing Warfare”, and sought to attack his bigger competitors at their weak points, hence “win battles” but not the whole war.

·         The CEO or Owner must be the sales leader.  This is too important a role to be left to anyone else.

He tells an interesting story on how he identified potential customers.  He describes his strategy of face to face meetings and the absence of email or the phone as part of that strategy.  He did target seven cities in the US and visited them on a regular schedule.  The word “frugal” does not even begin to describe his approach.  His strategy worked and he identified people of influence and companies who had a need for his services.  His article concludes with a very brief discussion on the pitfalls that can lead to failure.  It’s not an indepth discussion on pitfalls.  Perhaps it didn’t need to be since his company was merged long before any of the pitfalls he identifies had time to get a foothold.