Regulations to be Aware of When Starting a Peer-to-Peer Money Transfer Company

ZackRobockBlogPicDetectiveTransferring money between friends can be a big hassle, and a number of startups are seeking to offer new peer-to-peer money transfer options.  However, given the fungibility of money and increasing concern with terrorist financing, money laundering and fraud, there are a number of regulatory requirements to be aware of.

Companies in the peer-to-peer money transfer industry are generally referred to as “money transmitters.”  Federally, money transmission is defined as “the acceptance of currency, funds, or other value that substitutes for currency from one person and the transmission of currency, funds, or other value that substitutes for currency to another location or person by any means.”  This does not include a company that sells a product or provides a service and accepts money electronically; rather, it applies to the business of facilitating funds transfers from one customer to another customer.  PayPal, Venmo, Western Union, and MoneyGram are some common examples.

First, a money transmitter must comply with state regulations in every state in which it does business – not just the state in which it is organized.  In Michigan, for example, this would entail compliance with the Money Transmission Services Act (“MTSA”), which requires registration and licensing with the Department of Insurance and Financial Services (“DIFS”).  Among other requirements, the MTSA requires that a money transmitter:  (a) have a net worth of $100,000 or more, depending on number of locations (§487.1013(1)); (b) have a surety bond of at least $500,000(§487.1013(5)); and (c) submit a list of all criminal convictions, material litigation and bankruptcy events for each control person of the money transmitter (§ 487.1012(2)).  Money transmitters must pay a $600 investigation fee upon application, plus a $2,500 base license fee, plus an annual license fee set by the DIFS.  Requirements in other states may vary from Michigan’s.


Second, on a federal level, a money transmitter falls under the broader heading of a money service business (“MSB”), which also includes currency exchange, check cashing, traveler’s checks, money orders, and stored value/prepaid cards.  All MSBs must comply with the Bank Secrecy Act (“BSA”), which is designed to prevent and detect money laundering and terrorist financing.  The Financial Crimes Enforcement Network (“FinCEN”) is the federal regulatory agency primarily responsible for BSA compliance.


Under the BSA and related regulations, MSBs must register with FinCEN.  This registration is a bit different than state-level registration; the FinCEN registration is meant to enable MSBs to electronically file certain reports required under the BSA.  MSBs must file currency transaction reports (“CTR”) with FinCEN for any transaction that involves more than $10,000 in currency.  This does not apply to money transfers conducted entirely electronically; it only applies to transactions in which more than $10,000 in physical currency is deposited, withdrawn or exchanged.

The next type of report, a Suspicious Activity Report (“SAR”) is more applicable than CTRs to online money transmitters.  A SAR must be filed with FinCEN if a single transaction (or related series of transactions) appears ‘suspicious’ and equals $2,000 or more.  A transaction is ‘suspicious’ if it appears to:  involve funds derived from or in furtherance of illegal activity; be structured to evade reporting requirements (i.e. the $10,000 CTR threshold); or serve no apparent business or lawful purposes.  An MSB is required to maintain a copy of every SAR filed and the accompanying supporting documentation for a period of five years after filing.  MSBs should also keep records of investigations that do not culminate in a SAR filing in order to demonstrate an effective SAR program.

In addition to SAR-specific recordkeeping, the BSA outlines a number of other recordkeeping requirements, both for recording transactions and identifying customers.  Notably, if the customer (sender or recipient) is not an established customer, then for every transaction, an MSB is required to obtain an identification number (i.e. social security number, alien identification number, passport number) or to record a lack thereof; for in-person transactions, the MSB must also verify the customer’s identity by checking a government-issued identification card.  If the customer is an “established customer” then the MSB need not verify this information for each transaction; however, the definition of established customer requires that customer information – including a social security number (or similar identification) – be kept on file.  ‘Know Your Customer’ (KYC) best practices include verification of customer information at the time of account opening – either by documentary methods (i.e. review of government document) or non-documentary methods (i.e. checking a customer’s Social Security Number against credit reporting agency records); however, an MSB is not explicitly required to verify customer information under the BSA regulations.

Finally, MSBs are required to implement a process to receive, process, and respond to law enforcement requests for information.  Under Section 314(a) of the Patriot Act, certain law enforcement agencies may request information through FinCEN from financial institutions regarding customers or transactions reasonably suspected of involvement in money laundering activities.  An MSB must designate a point person to receive such requests, provide that person’s contact information to FinCEN, and ensure that requests are handled in a timely manner.



New California “Do Not Track” Privacy Policy Requirements

Do Not Track ImageThe use of tracking software by websites is widespread. Advertising companies and social networks use technology such as cookies to track the websites consumers visit and the route they take from one website to another. For instance, tracking technology can tell the difference between whether you got to a website through a Google search or by clicking on a hyperlink in a news article. Companies can then use this information to build a profile on individuals in order to target advertising on different websites that they visit. Advertising companies are then able to discriminate to different consumers based on the profiles the companies build. Additionally, advertising companies are able to make money by selling these valuable profiles to websites.

The use of this type of tracking software is, as probably expected, controversial. Privacy advocates believe this tracking to be an invasion into web users’ privacy and that the companies doing this tracking fail to adequately disclose the full extent to which this tracking is taking place. These advocates are also concerned with the extent of information tracked, which can include highly sensitive and personal data about health issues, location, and finances. On the other hand, advertisers and companies using the data love the technology because it allows companies to target consumers more accurately and allows advertisers to charge more for better data. This data can be particularly valuable for startups looking to increase the number of users and grow their web presence.

As a result of these concerns, privacy advocates have taken some steps to try and remedy these concerns. Software developers have designed software to try and prevent websites from tracking user activity across the web. The technology works by placing a signal on the users computer that tells websites the user does not want to be tracked. This signal is currently ineffective because there is no requirement that advertisers follow the signal. The World Wide Web Consortium (W3C), an organization that sets standards for the web, created a working group composed of privacy activists, advertisers and others, to try and develop a standard approach to “Do Not Track” signals. In September 2013, however, the effort ended in failure when the constituent parties could not agree on an approach and decided to disband.

Despite the failure of the W3C efforts, once again California leads the way in regulating and shaping regulation of online privacy, this time as it applies to “Do Not Track” signals. California has taken an assertive stance in developing regulations concerning online privacy by passing the Online Privacy Protection Act (CalOPPA) and establishing the Office of Privacy Protection as part the California Department of Justice. Given California’s large and tech-savvy population it is incredibly important for startups to keep apprised of and comply with California privacy regulations as they will almost certainly be operating in the state. In October 2013, Governor Jerry Brown signed into law an amendment to CalOPPA that regulates the use of Do Not Track signals by websites operating within the state. The new amendment is applicable to websites that collect “personally identifiable information” which includes things like name, address, email address, telephone number, or other identifiers that allow the website to contact the user and went into effect January 1, 2014. Rather than requiring that websites comply with Do Not Track signals, the law now requires that websites describe in their privacy policy how they react to “Do Not Track” signals, and indicate whether third parties can collect “personally identifiable information”, if they track user activity, in addition to the previous CalOPPA requirements. Websites may also meet the new requirement by posting a “clear and conspicuous hyperlink” to a description of any program that the website uses to manage online tracking and give the consumer the ability to opt-out. As a result, websites are not forced to cease tracking user activity, but simply requires a website to tell the user what they are doing. Websites who do not comply, are subject to a warning from the California Attorney General requiring the operator to comply within thirty-days and also faces the possibility of lawsuits from the state government and private parties.

The new law has come under fire from both sides of the online privacy debate. Some, such as Eric Goldman, a Professor at Santa Clara University School of Law, argue that the law hurts websites and consumers by imposing additional compliance costs on websites, not providing true disclosure because consumers rarely read privacy policies, and failing to cover all tracking technologies. Others, such as Chris Cronin, an information security professional, argue that the law falls short because it is weak and does not require websites to protect user privacy or comply with “Do Not Track” signals. Regardless, given California’s de facto ability to set national privacy standards and the fact that compliance with the new law is simple, it behooves startups to comply with the new recommendations by amending their privacy policies.


COPPA: Protecting Children’s Privacy Online

COPPA is designed to protect the privacy of children, but complying with COPPA can be difficult for startups.

COPPA is designed to protect the privacy of children, but complying with COPPA can be difficult for startups.  Attribution: Mike Licht.

Do you operate a website or app that is targeted at children? Even if your website or app is targeted at a general audience, do you know that you collect some personal information from children? If you answered either of those questions with a “yes” or even a “maybe,” there is a good chance you are subject to the Children’s Online Privacy Protection Act of 1998 (COPPA). Under COPPA, operators of a website or online service directed to children under the age of 13, or who knowingly collect personal information from children under the age of 13, are generally prohibited from collecting this information without parental consent. While there are exceptions and safe harbors to this general rule, compliance can be quite burdensome for start-ups with limited resources.

The Trouble with Verifiable Parental Consent

The Federal Trade Commission (FTC), charged with regulating COPPA, proclaims, “the primary goal of COPPA is to place parents in control over what information is collected from their young children online.” Hence, compliance with COPPA requires some method of obtaining verifiable parental consent for the operator to use, collect, or disclose a child’s personal information. This is the hurdle that trips up most startups falling under COPPA. As you can see below, the process of obtaining this consent is burdensome and inconsistent with the startup’s efforts to onboard new users with as little friction as possible. One FTC-recommended approach requires operators covered by the rule to perform all of the following:

  1. Post a clear and comprehensive online privacy policy describing their information practices for personal information collected online from children;
  2. Provide direct notice to parents and obtain verifiable parental consent, with limited exceptions, before collecting personal information online from children;
  3. Give parents the choice of consenting to the operator’s collection and internal use of a child’s information, but prohibiting the operator from disclosing that information to third parties (unless disclosure is integral to the site or service, in which case, this must be made clear to parents);
  4. Provide parents access to their child’s personal information to review and/or have the information deleted;
  5. Give parents the opportunity to prevent further use or online collection of a child’s personal information;
  6. Maintain the confidentiality, security, and integrity of information they collect from children, including by taking reasonable steps to release such information only to parties capable of maintaining its confidentiality and security; and
  7. Retain personal information collected online from a child for only as long as is necessary to fulfill the purpose for which it was collected and delete the information using reasonable measures to protect against its unauthorized access or use.

As a writer, I will be lucky if you actually read through all seven steps, let alone comprehended what each required for compliance. Now, imagine trying to advise a start-up to implement each of those . . . yeah, right.

Why You Should Comply with COPPA

While there are exceptions to obtaining prior parental consent, they are too narrow for the scope of this post, and unlikely to have much impact on COPPA compliance. So, why should operators care about being subject to COPPA, and how can they reasonably comply? Violators of the rule can be held liable for civil penalties of up to $16,000 per violation, which can add up quickly and debilitate a cash-strapped start-up from moving forward.

Realistic Solutions for Complying with COPPA

1. Don’t Fall Under COPPA by Clearly Avoiding Children User’s – The cheapest and easiest way to comply with COPPA is to simply not fall under the rule in the first place—don’t target children under the age of 13, and ensure that you aren’t collecting personal information from children under the age of 13.

2. “Age-gate” to Avoid Falling Under COPPA – In order to avoid COPPA’s coverage, consider using one of the following free options that utilize an “age gate” function, which requires a user to enter their date of birth in order to certify their age, before entering a website or app:

  1. If the user is under the age of 13, you can just deny their access to the website or app.
  2. If the user is under the age of 13, you can also allow the user to only access the online service through a “safe-mode” that does not collect, use, or disclose a child’s personal information. This means prohibiting a child from setting up any type of account or profile, and requires close monitoring of a child’s activities. For example, any text or input of any kind from a child must be monitored to prevent identification of the anonymous user profile.

3. Use a Safe Harbor Program – One plausible route for obtaining verifiable parental consent is through the FTC-approved COPPA safe harbor programs. Examples of these safe harbor programs include iKeepSafe, KidSAFE, and TRUSTe. While there seems to be some uncertainty surrounding these programs, the prospect of having service providers handle companies’ COPPA compliance is appealing and most likely the direction we are heading. These programs can serve as a portal for parents to read the privacy policies of multiple websites and provide consent, all in one easy-to-use location. Of course, this comes at a cost.

Understandably, some operators will fall under the umbrella of COPPA due to their business model. In this case, it is highly recommended that you consult a COPPA compliance attorney before launching the online service. However, if it is possible to exclude children from your online service, consider the aforementioned approaches for bypassing COPPA.


Avoiding Inequitable Conduct and Meeting the Duty of Candor and Good Faith

If entrepreneurs are not careful in their communications with the Patent Office, their valuable patents may later be found to be worthless.

If entrepreneurs are not careful in their communications with the Patent Office, their valuable patents may later be found to be worthless.

What is Inequitable Conduct?

As a fledgling startup, maximizing the value of the company is important when attempting to obtain early funding. For many startups the lion’s share of their value comes from their intellectual property. Obtaining and keeping that IP is critical. With that in mind it becomes crucial for entrepreneurs to consider issues of inequitable conduct and duties of disclosure when applying for patent protection for their intellectual property.

Inequitable conduct is a judge-made doctrine that allows the court to render a patent unenforceable if the patentee engaged in certain prohibited conduct during the application and prosecution of a patent. Inequitable conduct requires the patentee to intentionally misrepresent or omit material information from the patent office, as discussed here. This includes:

  • Failure to submit documents, including material prior art known by the applicant or explain/translate foreign language references
  • Misstating facts or affidavits of patentability
  • Incorrectly or incompletely identifying inventors

Further, the USPTO has enacted Rule 56, which holds that “each individual person “associated with the filing and prosecution of a patent application has a duty of candor and good faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to patentability.”

In the case of withheld prior art, under the Therasense standard, a defendant would need to show that a plaintiff patentee or their counsel:

  • Intentionally withheld or misrepresented information; and
  • The information was material.

To be material the defendant must show that the patent would not have been granted “but-for” the omitted prior art.

The penalty for inequitable conduct is invalidation of the entire patent. In addition, the lawsuit often becomes “exceptional” which can force the losing party to pay the other side’s attorney’s fees.

Defending against a charge of inequitable conduct can significantly increase the costs of litigation and patent ownership, even if one defeats the charges.

How Do I Avoid it?

First and most importantly, it is imperative that a startup ensure correct inventorship on any patent application. USPTO rules require all inventors to be listed on the patent application. An inventor is any person that participated in conception of the invention. That is, anyone who helped come up with the idea and form of the invention. Persons who simply helped build the prototype or who contributed ideas and knowledge that was not used in the version that is being patented need not be included.

Startups often have numerous founders or others who are involved in the conception of an invention. Be sure to keep track of these people and name them on the patent application. Further, do not intentionally omit a person who should be listed as an inventor in an attempt to avoid ownership issues (for example if a professor assisted in creating an invention and the startup is concerned about the University claiming title). While it may be the easier solution now, it risks the entire patent being unenforceable later.

Second, entrepreneurs must be diligent in preparing their application or in working with their counsel to prepare an application to ensure all prior art known is considered and disclosed if relevant. The USPTO does not require applicants to perform prior art searches, so applicants and their attorneys are only responsible for disclosure of prior art that is known to them. However, it is the responsibility of the applicants to ensure that no relevant information is being withheld.

If in doubt about the materiality of a reference, it is always better to err on the side of disclosure. Further, the duty of disclosure extends through grant of a patent, and if any prior art becomes known to an applicant it should be disclosed to the USPTO. Keep in mind that the duty of disclosure extends to the inventors, their counsel, and anyone involved in preparation of the application or anyone to whom there is an obligation to assign the patent. Entrepreneurs should be sure to check with every person meeting those criteria to ensure no prior art is being withheld. Keeping records of any prior art searches and of personnel having knowledge of an invention is extremely helpful when it comes time to apply for a patent.

Finally, the new patent reform act created a new administrative procedure called supplemental examination. This procedure can be used to cure inequitable conduct for a patent that has issued. A patentee may present new information to the USPTO and the examiner will consider whether the patent should have been issued in light of the information. If the patent is allowed in light of the new information, it cannot be later held to be unenforceable due to failure to disclose that information in the original application (but could still be held unenforceable for failing to disclose other information that was not included in the supplemental examination). Essentially it is a patent amnesty program. Entrepreneurs who have already obtained patents and are concerned about inequitable conduct should speak with counsel regarding supplemental examination.

By keeping records of the persons involved in conception of a new technology and their roles, as well as keeping track of what references were consulted or searched, it can save time and headaches when it comes time to apply for a patent and can make all the difference if the patent one days ends up disputed in court. For those entrepreneurs who already have a patent and are concerned about false or omitted disclosures, supplemental examination can be extremely useful.


Trade Secret vs. Patent Protection for Software Startups

In light of recent changes in the law concerning software patents, software startups should more heavily consider trade secret protection to protect their technological and operational advantages.

In light of recent changes in the law concerning software patents, software startups should more heavily consider trade secret protection to protect their technological and operational advantages.

So you’ve launched a software startup. You know that if you are to have any hope of becoming the next Google, Facebook, or Twitter success story, you need to take steps to protect your technology and your brand. Making the choice to invest some resources into obtaining intellectual property protection can be a great decision, but the specifics of how to carry out such a plan might be a little elusive. The question is what kind of protection do you actually need, and how do you go about getting it.

Two types of IP protection that most startups will want to consider are patents and trade secrets. What works best will vary from startup to startup depending on each ones own unique circumstances. However, there are several factors that all startups will want to consider when implanting an intellectual property protection strategy. First, let’s consider the basic types of IP protection that the patents and trade secrets provide, and then we can better understand factors that might encourage you to choose one or the other.


One type of IP protection that most people have heard of but few people fully understand is patent protection. There are several categories of patents, including utility patents, design patents, and plant patents. Plant patents and design patents give inventors rights in specific areas as defined by statute. However, the most common type of patent is the utility patent.

Utility patents grant the holder an exclusive monopoly on inventions of “new and useful process, machine, manufacture, or composition of matter, or a new and useful improvement thereof.” For example, someone could obtain a patent on a new and improved hair trimmer as long as it was different than and not obvious in light of previous hair trimmers. Last year, over 500,000 utility patent applications were filed at the U.S. Patent & Trademark Office.

Patents, utility patents in particular, enjoy popularity for several reasons. First, they grant the rights holders a very strong form of protection. This protection – the right to prevent others from making, using, selling, offering for sale, or importing the patent holder’s invention – is given in exchange for a publication that explains how to make and use the invention. After twenty years anyone is allowed to make and use the invention. When considering whether or not to apply for a patent, a software startup should evaluate whether or not the exclusive protection is worth having in exchange for giving up their invention after twenty years. In many instances, this will be a good tradeoff to make given the rapidly evolving world of software and technology.

Another benefit of utility patents is that the patent holders will not lose their rights due to the actions of third parties, assuming that they justly received the patent in the first place. This may not necessarily be true with trade secret protection. For example, a person who has trade secret protection in a manufacturing process can not prevent a third party from independently discovering and using such a manufacturing process. But if the original inventor of that manufacturing process acquired a patent, the third party could not use the process even if they independently discovered it (assuming that the patent holder had a valid patent that was not acquired through fraud).

While there are some significant upsides to obtaining a patent, there are costs as well. One downside that was already mentioned is the limited duration of patents. Another potential downside is the cost and difficulty of obtaining a patent. As discussed in our recent post, in recent years, it has become more and more difficult for inventors to obtain patents on software, and the scope of granted software patents may be more limited. Getting a patent can also be quite expensive. Depending on how many jurisdictions (i.e., countries) your startup is applying for patents in, the price tag can reach into the hundreds of thousands of dollars. See our prior post outlining the costs of obtaining patent protection.

Trade Secrets

Unlike patents, trade secrets are creatures of state law rather than federal law. This means that specific trade secret regimes will vary some from state to state; however, there are generally accepted principles regarding how trade secret law should work. One attempt to compile some of these generally accepted principles is the Uniform Trade Secrets Act. This document defines trade secrets as follows: “’Trade secret’ means information, including a formula, pattern, compilation, program, device, method, technique, or process, that: (i) derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by, other persons who can obtain economic value from its disclosure or use, and (ii) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.” In short, a trade secret is information that is valuable because it is kept secret. State laws prevent the “misappropriation” of trade secrets. This basically means that people aren’t allowed to steal your secret sauce. They can, however, independently create or reverse engineer it. This is one of the main disadvantages to trade secrets.

There are several benefits to weigh this disadvantage against when considering whether or not to rely upon trade secrets as your chosen form of IP protection. One benefit is that trade secrets can be relatively cheap compared to patents. There are no government filing fees for trade secrets, and the main costs result from taking measures to make sure your secret information remains secret. Trade secrets also can last forever assuming the information remains secret. This can be advantageous if you believe your invention will have commercial value for a long time to come.

Choosing Trade Secrets or Patents

One form of protection or the other will not be right for every startup. The following are some factors to consider when choosing between the two: (1) Will the invention be useful beyond 20 years? (2) Is it possible for companies to reverse engineer the invention? (3) Is the invention likely to be discovered independently in the near future? (4) Can you afford more expensive patent protection given your goals? (5) What is the risk that competitors design around a patent? (6) Are you interested in licensing/cross-licensing with competitors? (7) Would you be able to detect if someone was infringing your patent?

Let’s look at a couple of examples in order to understand how these factors can play out.

Example 1:

A software startup has developed a technology that has never been seen before, but as soon as you sell it, everyone will understand how to make it. They believe that this technology will be relevant for 5-10 years, but are not sure beyond that. Finally, the startup thinks there a lot of potential competitors who will likely be interested using this technology.

In this example, the startup would likely want to obtain a patent because all the factors lean in that direction. It will be easy for other competitors to develop similar products once they see the startup’s new technology; this will greatly reduce if not eliminate the value of any trade secret protection. The indefinite duration of trade secrets wouldn’t really be that valuable even if competitors couldn’t reverse engineer the product. The technology will only be relevant for 5-10 years, well less than the time frame protected by patents. Finally, because there are a lot of potential competitors that might be interested in using the technology, the startup could potentially operate on licensing business model to obtain revenue or cross-licenses.

Example 2:

A software startup has made a discovery that they believe is so foundational in nature that they believe it will revolutionize the industry for many years to come. They’re a little low on cash right now, but they expect that to turn around in the next year or two. Finally, the discovery should improve the ease with which current products are made, but the final products themselves won’t necessarily be changed.

In this example, the startup will likely choose to rely on trade secret protection. Given the foundational nature of the discovery (think F=MA2 rather than a bulldozer applying the principal of F=MA2), it is not even clear that the discovery would be patentable.  Further, the startup does not have a lot of money to try and convince the USPTO that the discovery is in fact patentable. Finally, it looks like the manufacturing processes for widgets will change, but this will not be detectable in the final widgets themselves. Thus, it might be very difficult to tell if a competitor was infringing a patent. Relying on trade secret protection will mitigate these concerns and allow the startup to profit for the discovery for many years to come.

It is important to note however, that deciding between a patent and trade secret does not necessarily have to be an either or proposition. It might be possible to go the trade secret route at first, and then obtain a patent further down the road. However, this is a one way street. Once you obtain a patent, you can never go back and rely on trade secret protection. Also, you can split up various aspects of your business. Certain aspects of the business might be appropriately covered by patents while other aspects would be great candidates for trade secret protection.


Startups creating an IP protection strategy should make decisions in light of their business model and technology. If it is not a clear decision to go one way or the other, the startup will need to make a calculated decision as to what factors are more important to them. Finally, when appropriate, startups should consider using patents and trade secrets in a hybrid form of protection.


Biotech Ventures Beware! The Industry May Need a Different Kind of Cure.

Last year's Supreme Court decision in Myriad and the USPTO's subsequent change to its examination guidelines make it more difficult to protect certain biotech innovations

Last year’s Supreme Court decision in Myriad and the USPTO’s subsequent change to its examination guidelines make it more difficult to protect certain biotech innovations


On June 13, 2013 the Supreme Court handed down its decision in Association for Molecular Pathology v. Myriad Genetics, Inc.. In this landmark decision for life science patents, the court held that a “naturally occurring DNA segment is a product of nature and not patent eligible merely because it has been isolated.” In so holding, the court weaved a fine line between unpatentable subject matter – the long-standing rule that “laws of nature, natural phenomenon, and abstract ideas are not patentable,” as they are not any single inventor’s creation, but rather are the “tools of scientific and technological work,” – and patentable subject matter. The court indicated that “the rule against patents on naturally occurring things is not without limits, for all inventions at some level embody, use, reflect, rest upon, or apply laws of nature, natural phenomenon, or abstract ideas, and too broad an interpretation of this exclusionary principle could eviscerate patent law.”  After Myriad, practitioners were uncertain as to whether Myriad specifically made genomic DNA unpatentable or whether other “naturally occurring” entities were also unpatentable.

On March 4, 2014 the United States Patent and Trademark Office (U.S.P.T.O), the regulator of U.S. patent grants, issued guidelines determined to shed clarity on this Myriad ambiguity. In these guidelines, the Deputy Commissioner for Patent Examination Policy identifies 12 factors that must be considered by a patent examiner in determining whether the invention is “naturally occurring.” Some of the factors that weigh in favor of eligibility are:

a)  Claim is a product claim reciting something that initially appears to be a natural product, but after analysis is determined to be non-naturally occurring and markedly different in structure from naturally occurring products.

b)  Claim recites elements/steps in addition to the judicial exception(s) that impose meaningful limits on claim scope, i.e., the elements/steps narrow the scope of the claim so that others are not substantially foreclosed from using the judicial exception(s).

c)  Claim recites elements/steps in addition to the judicial exception(s) that relate to the judicial exception in a significant way, i.e., the elements/steps are more than nominally, insignificantly, or tangentially related to the judicial exception(s).[7]

Some of the factors weighing against patentability are:

g)  Claim is a product claim reciting something that appears to be a natural product that is not markedly different in structure from naturally occurring products.

h)  Claim recites elements/steps in addition to the judicial exception(s) at a high level of generality such that substantially all practical applications of the judicial exception(s) are covered.

i)  Claim recites elements/steps in addition to the judicial exception(s) that must be used/taken by others to apply the judicial exception(s).[8]

The large number of factors and their inherent ambiguity have resulted in unpredictable examinations. Practitioners have been surprised to receive 35 U.S.C. § 101 rejections, when they were expecting patent issuance notices for molecular biology and non-molecular biology based inventions alike. Patent examiners have thus been effectively reading Myriad’s prohibition on “naturally occurring” as not limited solely to DNA-based inventions. As pointed out in a recent article, what’s more is that products that are derived from a naturally occurring product might be considered to be naturally occurring as well, further stifling patent protection for life science inventions.

The result has been a siege of the biotech and pharmaceutical industries. For an industry so reliant on patent protection, that is fixed with high upfront research and development costs, patent ineligibility is a real scare. If these guidelines stand, the industry can no longer be assured that their R&D expenses will pay off down the road.

However, the Myriad-Mayo Guidelines have themselves also been under threat from those companies and practitioners most affected by them. July of this year marked the end of the public commenting period, in which biotech and pharmaceutical companies as well as universities voiced their consternations with the Myriad-Mayo Guidelines. The vast majority of the comments were extremely critical of the guidelines, incentivizing the USPTO to revise the Myriad-Mayo Guidelines. The revision is currently underway and it will be important for life science based startup companies to watch for what occurs at the USPTO in the immediate future. Will the USPTO cure the patent illness it began? Patent protection for your start-up may be at stake




Fallout of the Supreme Court’s Recent Alice Decision: Is Software Still Eligible for Patent Protection? (Part 2 of 2)

In Part 1 of this series, we examined the Supreme Court’s recent decision in Alice Corp. v. CLS Bank and how courts and the Patent Office have started to limit the scope of software patents as a result. In this second and final post, we’ll look at how an entrepreneur in the software space might be able to protect her intellectual property in light of this new guidance.

Software Implemented Inventions Can Still be Patented

Despite what some anti-patent advocates may have hoped, Alice did not invalidate all software patents, and software inventions can still be patented. In fact, the Alice decision, at most, delineated a boundary beyond which a computer-implemented idea becomes too abstract to be patented, without something more. Nor did the court hold that software inventions necessarily constitute abstract ideas and are therefore ineligible for patenting. In fact, nowhere in the court’s opinion is the word “software” even used. Without a doubt, many inventions that embody systems and methods implemented in software will continue to be awarded by the Patent Office and upheld by the court system.

The Scope of Patentable Software is More Limited

With the good news comes the bad for software inventors hoping for a new patent. The scope of patentable software inventions is now decidedly more limited than it was before Alice. Gone are the days where an inventor could program a generic implementation of Bingo and receive a patent for it. While the Supreme Court has not set any hard-and-fast rule on what, exactly, is considered “abstract,” we have an idea of the general shape of the boundaries: any program that simply takes a long-existing idea and generically implements it in code is too abstract to pass the Alice patent eligibility test. If you take your computer Bingo program, and mentally strip it down to its essential functionality, is it really just a Bingo game on a computer, or is it something more? Perhaps there is additional functionality that make it more than just Bingo. Maybe you’ve programmed some unique features within the code that take advantage of the hardware on a specific platform and make the program run more smoothly. If you have these sorts of features built-in to your program, even computer Bingo may be patentable under the second step of the Alice test.

 Carefully Consider Your Options Before Filing a Software Patent Application

Finally, as an entrepreneur, you should think very carefully about identifying the particular and novel aspects of your software before filing a patent application. Your attorney can help you narrow and identify these features, but in general, the following considerations are prudent:

  • Think about what, specifically, makes your software unique. Does it leverage a unique algorithm to create performance improvements? Is there a function that has never been accomplished before? Does the user interface create a new experience? If the novel aspects of your software currently exist, especially if they exist in a non-digital format (like the game of Bingo), is there something “extra” that makes the invention more than just converting it into a digital format? For instance, implementing Bingo on a generic computer is not patentable, but is there something really unique about the user interface that makes the Bingo card easier to interact with? Does the program take advantage of the memory architecture in a unique way to more efficiently store and retrieve data? Try to identify these features in as much particularity as
    possible, even before you sit down to develop the patent application language.
Under the new patent eligibility guidelines for software implemented inventions, patents must claim something more specific than functionality carried out by well-known programming techniques on general purpose computers.

Under the new patent eligibility guidelines for software implemented inventions, patents must claim something more specific than functionality carried out by well-known programming techniques on general purpose computers.

  • When you and your attorney do begin drafting the patent application, consider identifying the novel algorithmic aspects of the software and including flow charts or even representative source code or pseudo-code in the filing. This will help to demonstrate to the examiner that your code is more than just implementing an idea on a generic computer, which can be accomplished in a near-infinite number of ways. Including specifics about the algorithm (or several examples of a possible algorithm) in the application will give you the flexibility during the Patent Office review to narrow the scope of your claims and could potentially save the application from dismissal under an Alice rationale. Since the legal ramifications of Alice have yet to fully play out, this is an attractive way to preserve some (albeit narrow) patentable ground if the courts or the Patent Office further restrict software-enabled inventions.
  • Consider your overall business goals and, perhaps, reconsider the need to pursue a strategy of patenting. You may not need a patent to protect your competitive advantage. Implementing a strategy of keeping software a trade secret may be a viable alternative in some situations, and copyright generally protects unauthorized copying of software. The expense and hassle of obtaining a patent may not be worth the ultimate reward.


Fallout of the Supreme Court’s Recent Alice Decision: Is Software Still Eligible for Patent Protection? (Part 1 of 2)

In June 2014, the Supreme Court struck down a patent on a software implemented invention, perhaps narrowing the scope of software patents we will see in the future.

In June 2014, the Supreme Court struck down a patent on a software implemented invention, perhaps narrowing the scope of software patents we will see in the future.

The Supreme Court, Patent Eligibility, and “Abstract Ideas”

In June 2014, the Supreme Court issued a much-anticipated patent decision in Alice Corp. v. CLS Bank. The question was whether the claims at issue, involving a method for mitigating “settlement risk” between two parties in a financial exchange by using a computer system as an intermediary, are patent-eligible under 35 U.S.C. § 101. Justice Thomas, writing for a unanimous court, answered that question with a definitive “no.” But even though this particular computer-implemented method was struck down, are other software programs still eligible for patent protection? That’s a trickier question.

35 U.S.C. § 101 limits patentable subject matter to “any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof.” Laws & products of nature, physical phenomena, and abstract ideas are generally considered unpatentable subject matter. With the rise of software and software-based inventions, the line between abstract ideas and new and useful processes became somewhat unclear. Note that §101 addresses whether a particle technology is eligible for patent protection. Section 101 does not address whether an invention is new, nonobvious, useful, or sufficiently described. Those requirements are addressed in separate sections of the Patent Act and represent their own unique hurdles to patentability. Therefore, the question presented by §101 (and addressed in the Alice case) is, even assuming a particular invention is new, nonobvious, useful, and sufficiently described, is this the type of creation that should be considered for the powerful protection of a patent.

For a time, courts generally refused to invalidate software patent claims under the statutory language of § 101. In 2010, however, the Supreme Court unanimously held, in Bilski v. Kappos, that a patent claiming a software method for financial hedging against price fluctuations was invalid under § 101. Alice continued this line of decisions for the Court, confirming the Supreme Court’s position that “basic tools of scientific and technological work” should not be monopolized by a patent-holder. Alice communicated to lower courts that § 101 should be used to invalidate software and business methods that are so abstract that the award of a patent would “tend to impede innovation more than it would tend to promote it.”

In order to accomplish this goal, Alice puts forth a two-part framework, based on its previous decisions in Bilski and Mayo v. Prometheus, to determine whether a patent application describes an “abstract idea,” and if so, whether it still contains enough inventive material to meet the § 101 standard.

First, the court considers whether the patent claim is “directed to an abstract idea.” While on some level, every invention embodies at least one abstract idea, if the claimed idea is so broad such that awarding a patent would impede more innovation than promote it, it is likely to meet this first step. Examples of abstract ideas include fundamental economic practices like the ones at issue in Alice and Bilski, certain methods of organizing human activities, an idea of itself, and mathematical relationships/formulas.

Second, if the patent claim is directed to an abstract idea, the court examines whether anything in the patent “transform(s) that abstract idea into a patent-eligible invention. In other words, if there are features of the invention that go above and beyond simply implementing an abstract idea in software, it may still be patent-eligible. Improvements to the technology, improvements to the functioning of the computer elements and other “meaningful limitations” that go beyond simply implementing an idea on a computer are likely to qualify an invention in this way.

 The End of Patents for Generic Ideas Implemented on a Computer

The U.S. Patent and Trademark Office (PTO) took little time in heeding the new guidance from the Supreme Court. Less than a week after the Alice decision, the PTO issued new guidance to its examiners in applying the Alice decision. PTO examiners now employ the two-part test set forth in Alice to evaluate potentially abstract ideas, and if there are no “meaningful limitations” on an otherwise abstract idea, the PTO examiner is very likely to reject the application as non-patentable subject matter under § 101.

Similarly, courts have wasted no time in implementing the Supreme Court’s guidance. The U.S. Court of Appeals for the Federal Circuit, which receives all appeals on patent matters, has invoked Alice in a number of recent cases to invalidate software and business method patents. District Courts hearing patent disputes, too, have seized the opportunity to invalidate claims that are too “abstract” to be patented. Some recent examples of inventions too “abstract” to be protected by a patent under the Alice rationale include:

  • “[A] process of organizing information through mathematical correlations and is not tied to a specific structure or machine . . . taking two data sets and combining them into a single data set” Digitech Image Techs., LLC v. Elecs. for Imaging, Inc., 758 F.3d 1344 (Fed. Cir. 2014)
  • “[C]reating a contractual relationship—a ‘transaction performance guaranty’—that is beyond question of ancient lineage,” implemented by a generic computer. buySAFE, Inc. v. Google, Inc., 2014 U.S. App. LEXIS 16987 (Fed. Cir. Sept. 3, 2014)
  • “[M]ethods and systems for ‘managing a game of Bingo,’ . . . ‘solv[ing a] tampering problem and also minimiz[ing] other security risks’ during bingo ticket purchases” using a computer. Planet Bingo, LLC v. VKGS LLC, 2014 U.S. App. LEXIS 16412 (Fed. Cir. Aug. 26, 2014)
  • “[A] computer program that allows the user to create meals from a database of food objects according to his or her preferences and dietary goals, to change those meals by adding or subtracting food objects, and to view the dietary impact of changes to those meals on a visual display” DietGoal Innovations LLC v. Bravo Media LLC (Div. of NBC Universal Media, LLC), 2014 U.S. Dist. LEXIS 92484 (S.D.N.Y. July 8, 2014)
  • “[A]sking someone whether they want to perform a task, and if they do, waiting for them to complete it, and if they do not, asking someone else. . . . performed ‘in connection with a computer system.’” Eclipse IP LLC v. McKinley Equip. Corp., 2014 U.S. Dist. LEXIS 125529 (C.D. Cal. Sept. 4, 2014).

So what does all of this mean for an entrepreneur with a potential software invention? Check out Part 2 of this series.


FTC Sues Amazon: Lessons for Startups Seeking to Monetize Through In-App Purchases

FTC Complaint

As has been widely reported, on July 10, the Federal Trade Commission filed suit against for allegedly failing to do enough to prevent unintentional in-app purchases by children.

Background on Consumer Protection by FTC

In its complaint, the FTC accuses Amazon of violating Section 5 of the FTC Act, which provides:

Unfair or deceptive acts or practices in or affecting commerce [ ] are [ ] unlawful.

The FTC Act defines “unfair” practices as acts that:

“cause[] or [are] likely to cause substantial injury to consumers which is not reasonably avoidable by consumers themselves and not outweighed by countervailing benefits to consumers or to competition”

The FTC’s website refers to Section 5 as the FTC’s basic consumer protection statute.

The FTC’s recent actions with Apple, Google, and Amazon, show the FTC is primarily concerned with the following aspects of company’s seeking to monetize through in-app purchases when children may be using the app.

(1) making sure account holders understand the nature of in-app purchase and the full scope of what an account holder is agreeing to when they download an app and enable in-app purchases;

(2) technological restrictions imposed at the time of an in-app purchase to reasonably prevent a child from making a purchase the account holder does not intend to make (e.g., a second entry of a password, or having to enter credit card information); and

(3) the notice provided to the account holder when and in-app purchase is made.

FTC’s Complaint Against Amazon

According to the FTC’s Complaint,, billed parents and other account holders for children’s activities in apps that are likely to be used by children without having obtained the account holders’ express informed consent.

Some commentators believe the “express informed consent” standard is too rigid and deprives an app designer of the ability to make its own design choices in deciding how to fairly engage with consumers.

The FTC’s “Express Informed Consent” Standard

Some commentators believe the “express informed consent” standard is too rigid and deprives an app designer of the ability to make its own design choices in deciding how to fairly engage with consumers.

In its January settlement with Apple, the FTC defined “express informed consent” as requiring an affirmative act communicating informed authorization of in-app charges that:

(1) is made promptly in relation to in-app activity;

(2) discloses material information related to the billing, including:

  • for a specific in-app purchase: the activity related to the charges; the specific amount of the charge; and the account to be filled; and
  • for potential future in-app purchases: the scope of the charges (including duration and apps to which consent applies); the account to be billed; methods by which an account holder may revoke or modify the scope of consent

(3) takes reasonable steps to verify that the person providing consent is the account holder;

(4) for consent related to potential future purchases, consent must be obtained at least once for each mobile device.

Current Lessons for Startups Related to In-App Purchases

The following are take-aways from the FTC’s recent activity related to in-app purchase:

1) Stayed tuned and see if Amazon prevails.  Amazon believes the FTC’s requirements are too stringent.  If federal courts agree, then the FTC will have to revise its policies concerning in-app purchases.

2) Use your “Terms of Use” to provide clear notice to account holders about what in-app purchases are available and (if applicable) that such purchases can be made without re-entering credit card information.  A clear warning to parents should also be provided if the nature of the app is such that children are likely to use it.

3) Reasonable restrictions on in-app purchases should be imposed.  The restrictions must be balanced with reasonable design and business considerations.  Possible restrictions include: (i) re-entering a password in order to make an in-app purchase; (ii) entering a different password; (iii) having to re-enter at least a portion of credit card information;  or (iv) asking identifying questions or using recognition technology on phones.

4) Provide prompt notice to an account holder of an in-app purchase and/or provide some ability for account holders to stop or reverse a purchase.

5) If you do not intend for children to us the app, take steps to prevent them from doing so, and make this intent clear in your terms of use.




The Rift Between Companies: Oculus v. Zenimax

ZeniMax Media and Oculus are embroiled in a dispute over the intellectual property rights incorporated in the Rift product.

ZeniMax Media and Oculus are embroiled in a dispute over the intellectual property rights incorporated in the Rift product.

Have you heard of the Oculus Rift (that loveable virtual reality company swept off its feet by Facebook)? How about legendary game designer John Carmack? If you haven’t by now, you absolutely should have! In any case, here’s your major takeaway: Beware the Employer! The situation playing out between Oculus and ZeniMax Media is an interesting one, and it is a useful lesson in what not to do. While we wait for this to unfold (either in the courtroom or behind closed doors), let’s see where things went wrong and learn from Oculus’s potential mistakes.

Our Legal Setup

On May 1, 2014, ZeniMax Media (the parent company of Carmack’s former employer, id Software), sent letters to Oculus and Facebook claiming rights in at least part of the IP in the headset. In other words, ZeniMax believes it owns rights in IP created by Carmack during the course of his prior work for ZeniMax’s subsidiary, and that some of that IP is embedded in the Oculus Rift headset.  On May 21, ZeniMax initiated a lawsuit against Oculus in the Northern District of Texas. The focal point of Oculus’s problems stems from two documents: John Carmack’s employment agreement (and other ZeniMax/id personnel as well) and a Nondisclosure agreement entered into between Oculus cofounder, Luckey, and Zenimax Media.

Employment Agreements: Be Cautious about who helps you

Entrepreneurs, if you seek someone’s help, be sure to have them take a look at their employment agreement! Almost always, an employment agreement will include provisions that immediately make the company the owner of rights in inventions created by the employee in the scope of his employment. Sometimes, there may be an out if the work is unrelated or outside the scope of the Employer’s work or agreement. However, that may be difficult to prove.

Prior to this whole mess, Luckey, a hardware developer had begun the development process on the “Rift” virtual reality (VR) headset. In 2012, John Carmack began corresponding with Luckey and asked for a prototype of the Rift headset to tinker with. This is where their trouble begins. In the complaint, ZeniMax constantly states that it was developing VR technology with Carmack heavily involved in that research. As a game company, ZeniMax researched VR technology specifically for game development. There exists some question as to whether or not they sought to bring a viable consumer hardware project to market.

Carmack’s specific employment agreement reads:

Employee agrees that all Inventions that (i) are developed using equipment supplies, facilities or trade secrets of id Software or the Company… or (iii) relate to the Company’s business or current or anticipated research and development will be the sole and exclusive property of the Company (ZeniMax) or its designee from the moment of their creation and fixation in tangible media…

In other words, even if Carmack did not use his employer’s resources in working on the Rift, his employment contract would still purport to transfer rights to the employer if the Rift relates to the employers “current or anticipated research and development.”  Additionally, Carmack and other ZeniMax employees are said to have used company resources and research to make both hardware and software (including the software development kit or SDK) improvements to the device.

According to ZeniMax, “Carmack made breakthrough modifications to the Rift prototype based upon years of prior research at ZeniMax.” When Carmack and his crew made improvements, the resulting intellectual property had been assigned to ZeniMax via the employment agreements. The complaint constantly tees up that ZeniMax (Carmack with id Software in particular) had been working on VR hardware and software research. However, record exists where Carmack states that this was his pet project.  [Is there something missing in the prior sentence?]

In any case, if the court sides with ZeniMax, these improvements become their property, including the SDK. Carmack had quickly taken to Twitter to protest saying that nothing he has ever worked on was patented. But that might not be the only issue. The code he wrote, which is automatically protected by copyright, became property of ZeniMax (under ZeniMax’s interpretation of the law and facts). Accordingly, it might be the case that ZeniMax owns certain parts of the code used in the Rift.  If ZeniMax was the owner of Carmack’s rights in code he developed, then Occulus would have had to reverse engineer its code, without incorporating any of the copyrighted content from the ZeniMax-owned code.  It might also be the case that Luckey and ZeniMax became co-owners in the software.

Nondisclosure Agreement: Now that it’s not yours, it’s not yours.

Under ZeniMax’s argument, the technology became confidential information and trade secrets of ZeniMax. This is what gives ZeniMax some ammunition (or rather a actionable claim). Their research and proprietary information that was confidential and not readily attainable had been used in the Oculus Rift. Oculus was using it to profit to the tune of a cool $2 billion from Facebook. This could constitute misappropriation, meaning ZeniMax’s proprietary information was stolen. Helping to solidify their claim, ZeniMax points to the NDA entered into between the Company and Luckey.

It was under this agreement that Carmack showed Luckey the improvements made to the Rift. This contract is what governed the relationship between Carmack’s team, ZeniMax, and Luckey. The definition of confidential information includes the work done by the employees of ZeniMax. If these facts are correct, Luckey would likely not be able to use the information without the permission of ZeniMax (for purposes other than those outlined in the NDA). If ZeniMax’s secrets are disclosed, they potentially lose any trade secret protection. Multiple times in ZeniMax’s complaint, the Oculus team is painted as having no software background and no particular VR experience. If these facts are true, this would help ZeniMax demonstrate that they did not reverse engineer the tech (an acceptable method of discovering trade secrets). Multiple email chains affirmed the notion that they needed Carmack. Only days after demonstrating the Rift improvements, Oculus LLC was formed in the state of California.


ZeniMax’s complaint does not paint a favorable picture of how Oculus handled its negotiations with ZeniMax. The only facts are those from the complaint, and we’ll have to wait for more to come to light to know the truth. It is understandable that an entrepreneur will desire to protect and profit from an idea they believe to be there own. But even if there is not a clear owner of intellectual property rights in an idea, an entrepreneur maybe able to secure clear title to important intellectual property by negotiating a business arrangement with others involved.  ZeniMax’s allegations outline what not to do in negotiating over intellectual property rights.  ZeniMax alleges the negotiations broke down in large part due to the Oculus team. According to the complaint, originally, Oculus was to grant ZeniMax some share of equity in the LLC. According to the complaint, Oculus demanded a worldwide exclusive license over the IP disclosed by ZeniMax pursuant to the NDA. Furthermore Oculus demanded marketing support from ZeniMax and 10,000 free copies of Doom 3 BFG edition (a game capable of showing off the Rift) for the Kickstarter campaign. In return, ZeniMax would receive 2% equity interest subject to a 3 year vesting schedule. Vesting would be dependent on Carmack’s ongoing involvement in the project. Oculus also proposed tht ZeniMax could pay an additional 1.2 million for another 3%. However, that term was eventually dropped.

In 2013, negotiations in total broke down. ZeniMax would eventually prohibit Carmack from working with Oculus. As a result, Carmack left the company to become the Oculus CTO. They then began poaching former members of Carmack’s team despite noncompetition provisions in his employment agreement specifically prohibiting this.  Again, this is all based on ZeniMax’s unproven allegations.  However, this provides an example of how aggressive negotiating posture and subsequent aggressive hiring decisions can inflame a situation and lead to litigation.


Clear title to fundamental intellectual property is typically critical to a startup’s success.  While Oculus was able to achieve a favorable exit, their outcome is likely the exception to the rule.  ZeniMax’s complaint in its recently filed litigation provides numerous examples of mistakes startups can avoid making in working with individuals employed by others or subject to NDAs.