This article by Hunter Jensen, CEO of Barefoot Solutions, was originally published in the July 2008 edition of PHP Architect, a print magazine for PHP Professionals. It is the fourth article in a five part series on some of the different legal issues surrounding the web development industry. Modern day patents originated from a specific form of Letters Patent. These were decrees handed down by a monarchy granting exclusive monopoly rights to the recipient for a specific and often broad range of business activities. Patent laws have come a long way since then, but the basic premise is the same. A government provides monopolistic rights to the creator of an invention for a limited time. The justification here is to provide an incentive structure that is conducive to promoting progress and innovation. But why, as professionals working with PHP, do we need to care about patents? Most small software development shops and startups will run their entire course without ever securing a patent. We should care because most small software development shops will infringe upon a software patent during the ordinary course of business. Patent infringement lawsuits, regardless if you win or lose, are expensive propositions. Further, we should care because they are threatening the software development industry as a whole. They are stifling innovation and creating massive barriers to entry. Major changes need to be made to fix the current system in the U.S. and across the world. First, a little background on intellectual property laws and patents. The U.S. system will be discussed here because it has one of the broadest covering patent systems in the world, and is the basis for many of the software patent issues that are affecting the industry globally. The United States Constitution states that: “Congress Shall Have Power To […] promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries”. This one sentence contains the entire justification for the U.S. copyright and patent system. Patents are not the right to use your invention, but rather the right to exclude others from making, using, selling, or importing patented goods and services. Inventors must apply for patents which are then reviewed by government officials and awarded or denied based on their merit. In the United States, this is handled by the U.S. Patent and Trademark Office (U.S.P.T.O). They base their judgments on three main criteria. In order to be awarded a patent, the idea presented must be novel (new), useful, and nonobvious. A patent will not be considered new if: The invention was publicly known before it was supposedly “invented” by the patent applicant The invention was explained or described in any publication more than one year prior to the date that the application is filed The invention was used or offered for sale in a public manner more than one year prior to the filing date. The actual rules are more detailed than this, but are fairly clear in their application. The Useful requirement for patents is generally used only to throw out frivolous applications and is most often very easily met for software patent applications. The Nonobvious requirement is by far the most difficult to predict and judge properly. The rules state that not only must the invention be different from any prior art (novel), but it must also be a nonobvious extension or improvement on any prior art. This is judged by determining whether a person “of ordinary skill in the art” would consider something obvious. For example, as a person of excruciatingly ordinary skill in the art of computer programming, it seems obvious to me that, in an online shopping system, the less clicks required to checkout the better. Therefore, given prior art of a two-click checkout process, a one-click process seems to be an obvious extension. Unfortunately, as we will see, the judgments of the USPTO do not always follow my intuition. A common misconception is that you have to actually copy another person’s invention in order to infringe on a patent. While this is true for copyright, it is possible to infringe on a patent while being completely unaware of its existence. Lack of knowledge is considered irrelevant in a patent infringement case. Another area of confusion is where exactly patents are enforceable. While it is true that patents are only enforceable in the country in which they were issued, international trade agreements make it very reasonable to obtain similar patents in many other countries, thereby making them internationally enforceable. Software patents are only one specific form of patents. Surprisingly, they are available in most countries with a mature set of intellectual property laws; Even those countries that specifically do not allow them. This is achieved by working around the letter of the law and ignoring the spirit entirely. For example, in the United States software patents were not valid in the 1980s because they were regarded as “printed matter”. The federal government ruled that they were simply written instructions on how to perform a task and therefore outside the scope of the patent office. Further, the USPTO has always held that scientific truths or algorithms expressing those truths cannot be patented. No corporation can own e=mc2. In the mid-90s the “Beauregard Claim” was developed and shown to be lawful, and it changed the landscape of software development for the worse. While it was still unlawful to patent a set of written instructions, the Beauregard claim sought patent protection for a computer readable storage device (hard drive, floppy disk, CD-ROM) which contains the specific written instructions. This patent was awarded, creating a precedent that was further litigated, and now nearly all software patents contain some form of the Beauregard claim. Armed with some general knowledge on software patents, we can now examine where the problems lie. As I said above, the purpose of patents in the United States is to promote progress. Most generally, the problem is that software patents do not achieve their purpose. In fact, the argument can be made that they actually stifle innovation, having the opposite of the intended effect. They are stifling innovation because the USPTO awards patents for very standard software development methodologies. Techniques that any PHP programmer uses in their day-to-day coding can quite often be patented. This makes creating web applications an intellectual property minefield where one misstep could lead to a patent infringement lawsuit. The most highly publicized case that illustrates this issue is the notorious Amazon one-click patent. The invention they claimed was the concept of storing a user’s personal and payment data so that, in one click, they could complete a checkout. They considered this idea so innovative that they applied for a patent. The scary part is that it was awarded. No prior art could be found, and it was considered nonobvious by a patent reviewer. Later, Amazon sued Barnes and Noble for patent infringement for providing similar functionality on their application. The lawsuit ultimately ended in a settlement requiring Barnes and Noble to remove this feature from their website. It now takes at minimum two clicks of the mouse to checkout on barnesandnoble.com. Anyone can imagine the millions of online stores which could benefit from this feature, but the Amazon patent prevents this from happening. As developers, an example that might hit closer to home would be the lawsuit filed by Eolas against Microsoft Corporation. The lawsuit claimed that Michael Doyle, the president of Eolas, successfully developed a manner to seamlessly embed content into a Web page. We know these as the <embed>, <object>, and <applet> tags. Because of the victorious lawsuit and Microsoft’s failure on appeal, Microsoft was forced to change the functionality in Internet Explorer 6 surrounding how they activated ActiveX controls. Microsoft released the patch in 2006, and many websites stopped functioning correctly. Microsoft’s solution was to require the user to click any ActiveX control first to activate it, and then they could interact with it. My company, Barefoot Solutions, was managing several projects at the time that were affected. Most notably, embedded video players now had to be clicked twice in order to be played – once to activate, and again to play. This was infuriating. Fortunately for developers and users, someone developed a workaround in which Javascript was used to output the embed tags, and Microsoft never plugged that hole. But as Tim Berners-Lee pointed out in a letter to the Director of the United States Patent and Trademark Office in 2003, the problem was severe considering the millions of websites with historical significance that are no longer being managed. These were affected and never updated. Regardless, we see how much damage one patent can have on the Web. These are only two examples of software patents with major implications in which ultimately the common internet user is the loser. Netcraft estimates that as of January 2007, 155,583,825 websites are violating at least one software patent. When these magnitudes of people are violating the law, it is natural to suspect that the law itself might be the problem. Another major issue with software patents is that avoiding liability is impossible. Not just difficult, but literally impossible. First, there are millions of patents. The idea of reviewing all patents to ensure that your new invention does not infringe on one is just not feasible. The tools for patent research are still very ineffective. More importantly, in the United States, patent applications are not publicized. Even if it were feasible to research every patent to ensure that your invention did not infringe upon one, it would still be possible for a patent to finally be awarded – the application review can take several years – in which case your invention would then be infringing on a valid patent. This is a major flaw in the logic of the U.S. system and is unfair to any inventors, including software developers. Finally, software patents are causing a huge drain on resources that otherwise could be used on innovation. The End Software Patents project estimates that 15% of all new patents are software patents. Their report shows that approximately $11.2 billion is spent annually on software patent litigation. This number refers only to those lawsuits which actually make it to litigation. Legal fees in the many lawsuits or licensing agreements that are reached before ever getting to litigation are not included, so the actual expense is much higher. One significant cause for this drain on resources is the existence of so-called patent trolls. These firms buy up patents and seek out infringement cases as their primary means of revenue. Bruce Perens, a leader in the Free Software and Open Source community, dubs these firms patent parasites. Yet we cannot place the blame with these firms, but rather the system that incentivizes this behavior and makes it lawful. These parasites force patent holders to spend their resources on legal fees, as opposed to research and development, thus stifling innovation on a large scale. Many would say however that we need software patents in order to protect inventors and provide incentives for major investments in innovation. There is evidence however that innovation will occur without the existence of software patents. Through the 1980s, software patents did not exist in the United States. Some of the most important concepts that we rely on today were created during this time, showing that we do not need a software patent system to allow for progress. These concepts include: the word processor, spreadsheet, database, email, the World Wide Web, audio-video compression/decompression, the basic elements of the graphical user interface and the fundamentals of all modern operating systems. Why then do we continue to support a system that stifles innovation and is unnecessary? As Bill Gates wrote, “If people had understood how patents would be granted when most of today’s ideas were invented, and had taken out patents, the industry would be at a complete standstill today.” This paints a dismal picture for the future of the web development industry. So as developers, what can we do to protect our business? Unfortunately, the answer is not very promising. First, many lawyers will advise you to not read up on software patents. This seems counterintuitive, but is often the safest play. The reason is that willful infringement of a patent can involve much larger damages awarded in an infringement lawsuit. Further, U.S. law states that only patent attorneys can judge whether or not your concept infringes on a certain patent. Laymen are unable to properly determine the scope of a claim in any patent. So, if you were to read a patent and decide that your concept does not infringe, the federal court would not agree that you were able to make this judgment, and you could then be sued for willful infringement. Thus, in nearly all cases, the risks greatly outweigh any benefits, and it is best to not educate yourself on the current patents in software development. Another recommendation is to be sure to place the liability for patent infringement in the hands of the owners of the intellectual property. In an earlier article I suggested that for a freelance PHP programmer, your development agreement should include a ‘Work for Hire’ clause that provides all intellectual property rights to the client. It is also important to include an Indemnity clause stating that the client will pay any legal fees or damages awarded due to a lawsuit for copyright or patent infringement. This will help shield you from some of the liability in the case that you unknowingly infringed upon a patent. Another method of shielding yourself or your company is to purchase patent infringement insurance. These policies will pay for legal fees and/or any damages that are incurred as a result of an infringement lawsuit. Unfortunately, the premiums for this kind of policy are often very high, and as such this is not very feasible for freelance developers and small businesses. In reality though, there is not much you can do to fully protect yourself from liability. In medicine, malpractice lawsuits are just part of the risk of being a doctor. In software development, patent infringement lawsuits are currently part of the risk as well. Ultimately what we must do is get involved to fix our broken system. Supporting organizations like End Software Patents (ESP) and the Free Software Foundation that fight software patents is a good start. Our very livelihood is in danger, and it is our responsibility to protect ourselves, our business, and the Web.

Move over millennials, the next generation is here. Generation Z are youth born between the mid-1990s and the early-2000s. Unlike millennials who will remember dial-up internet or earlier, Generation Z’ers may have a challenge recalling the time when they were not connected to the outside world via computer or smartphone. This means they look at technology and apps differently — and more often. A recent study found that 12% of youth between the ages of 13 and 17 check their phone every few seconds. It’s up to companies to build apps that will keep this generation engaged. Here are a few apps currently making it work. Social Media and Messaging A predictable first app to mention, Snapchat is insanely popular among Generation Z. The photo and video messaging app has more than 100 million active daily users, with 45% of those users between 18 and 24-years-old. This demographic uses Snapchat to document every cool, funny, and interesting moment in their lives, leading to a generation that can have vicarious experiences unlike any group in the past. Snapchat taps into two defining elements of Generation Z: a love of selfies and a fear of missing out (often known as FOMO). Through its ever-changing filters in which users can adorn themselves with flower crowns and dog faces — as well as the simple and short-term shareability of pictures and videos through private messages or public stories — Snapchat meets this demographic’s core app desires. Generation Z loves secret identities. That’s perhaps why an app called Whisper is so popular. Whisper users can send messages anonymously and receive replies which are posted publicly or sent to them by a user with a pseudonym. (However, it’s important for developers to consider that secret identity apps like this have the potential to open up a door to cyber-bullying and may need to be monitored heavily.) The messages — also known as whispers — are questions or confessions users may never share in the real world and are displayed to the app’s 30 million monthly users, with replies coming from around the world. While emojis continue to dominate smartphone messaging, an app called PopKey allows users to easily send GIFs in addition. The app installs a GIF keyboard to your phone, so users can easily select a trending GIF. There’s never been an easier way for Generation Z to send a virtual “face palm.” [gravityform id="9" title="true" description="true" ajax="true"] Photography and Video As mentioned, selfies are a big part of life for Generation Z, and photo sharing app Instagram can be the perfect outlet for those shots. The Instagram app of today has started to resemble Snapchat, with Instagram Stories allowing users to share momentary glances into one another’s lives. The fact that 76% of teenagers use Instagram shows there’s merit in allowing Generation Z the ability to add filters to their photos and easily engage with their friends, community, and celebrities. Live video streaming app Periscope has also gained traction among Generation Z’ers. If you thought Snapchat was an overshare, think again. Periscope is akin to The Truman Show, where users become famous by live streaming every moment of their life. Twitter acquired Periscope before its launch in 2015 in an effort to capture the attention of younger users, and it worked. One of the reasons Periscope is so popular is that it’s a more authentic look at someone’s day. Unlike Snapchat and Instagram where users can add filters and take hundreds of photos before finding the right one, there’s a level of vulnerability and exposure that comes from a live streaming app like Periscope. Music When it comes to music, the apps that are popular with Generation Z are the ones popular with millennials: namely Spotify and Pandora, with respectively, 39% and 21% approval ratings from this demographic. One of the reasons these apps may be popular is because of a user’s ability to curate content, i.e. create their own playlist or station. App developers considering the audio and music industry should consider designing their app as a streaming platform rather than one based on downloads. What Makes Apps Popular? Generation Z grew up on the internet, and they understand that there are no (or at least very little) secrets. This doesn’t mean that youth don’t want privacy and security, though. Apps targeting Generation Z’ers should incorporate some element of a confessional or ability to share — but should consider masking that information or the user’s location with some sort of disguise. An element of immediacy will also help with popularity, as Generation Z wants to find out what’s going on in real-time.

This is a question that we go through with nearly every mobile client we work with at Barefoot Solutions. Mobile technology is progressing at breakneck speed right now and it's very difficult to keep up. So to start, what are the technology options for launching a mobile strategy? While there are an infinite number of variations, the options can mostly be put into 4 buckets: Mobile Websites Mobile Web Apps Hybrid Apps Native Apps Mobile Websites are simply websites that have been optimized for mobile devices. A good example of this can be found at http://m.techcrunch.com. Changes to the layout are made by recognizing the user agent as a mobile device and optimizing for its limitations. This can include removing ads, increasing the size of clickable areas, and most importantly, accounting for the smaller screen size. Mobile Web Apps are still mobile websites, and thus must be accessed via a phone or tablets web browser. The difference between a mobile website and a mobile web app is that mobile web apps are built to mimic functionality of native apps. By adding controls like date pickers, tab bar navigation, and other native feeling controls, this gives the user the experience of using a native app. Typically these are built using frameworks such as Sencha Touch or JQuery Mobile. These frameworks are effective because they have already built most of the common controls using HTML5 and Javascript. Building all of those controls from scratch would be a significant undertaking, but JQuery Mobile you can focus on functionality, rather than building the sometimes complex user interaction necessary for mobile devices. Hybrid apps also utilize frameworks, often built with HTML5, Javascript and CSS, to produce native-feeling apps. Some examples are Phonegap and Titanium Appcelerator. The difference between a hybrid app and a mobile web app is that the hybrid apps are actually compiled and treated as native apps. This means that, on your iPhone for example, a hybrid app must be downloaded from the app store, and will live as an app icon on your home screen. Hybrid apps are appealing because they allow you to develop only a single app, but then compile for the various app stores and be available on multiple platforms. Another benefit of hybrid apps is that they have access to the phone's hardware. Access to the accelerometer, image gallery, camera, bluetooth, and other sensors on the phone are often a requirement for the more advanced apps. Finally, we have purely native mobile apps. This means that they are written in Objective-C for iPhones, or Java for Android applications. They are compiled, and submitted to the app store for distribution for that devices particular users. Mostly, native apps have to be built as a separate piece of software for each platform, and are able to share very little code. So if the desire is to make your app available on iPhone, Android, WinPhone, and Blackberry, you would need to build four separate apps. So with those as the options, what factors should go into deciding on a platform? To start, it's important to identify the goals and limitations of your mobile strategy. Then you apply those goals to the four factors below to make a decision. Cost Mobile apps become more expensive as you get closer to the fully native experience. A mobile website can often be implemented by altering layout and stylesheets of an existing website, and as such is a low cost product that can be accessed on any phone or tablet with a web browser. Native apps, on the other and, require quite a bit more development time, which then gets multiplied by the number of platforms that need to be accessible. As such, native apps are the most expensive option, by far. User Experience If this decision was based entirely on cost, then a mobile website would be the obvious choice. But what about the user experience? Unfortunately, native apps, while the most expensive option, also provide the best user experience. By interfacing directly with the native SDKs, native apps have a very fast and responsive UX. Think of the difference between using a desktop app like Microsoft Word, versus Software as a Service like Google Docs. Because Microsoft Word is a compiled and installed application, it directly interfaces with your machine and allows it to be more powerful, and responsive. The same holds true for native apps. Further, native apps have controls like pickers, navigation tabs, action bars, and others that are immediately recognizable to users of a platform. When building a single app for multiple platforms, you must find commonality amongst those platforms and therefore can't entirely mimic a native experience. While this will work for some apps, others, particularly those that are entirely consumer facing, need the native UX to provide users what they have come to expect from their apps. Difficult to develop and maintain Many organizations now have in-house web developers, or at least people with some experience with HTML/CSS. This makes it possible for some organizations to build a mobile website or mobile web app without having to hire outside of the company. Native apps however require a very particular skillset. Objective-C developers, for instance, can be difficult to find and expensive to hire. While it may be feasible to hire a firm for the initial development of your app(s), there is also the matter of continually managing this relationship to account for updates, bug fixes, operating system upgrades, and other required maintenance over the lifetime of the app. Depending on resources this may not be feasible for some smaller organizations. Reach Mobile websites and mobile web apps are available on any device that has a web browser. This is basically any feature phone or smartphone these days. As such, they have the furthest reach with the lowest cost. Hybrid apps can also be available on multiple platforms for only the cost of building a single app. Further, along with native apps, they have the added benefit of placement in the various app stores. This allows apps to be discovered by users in a way that just isn't possible with the mobile web. This also allows the possibility of reaching high in search rankings, or earning a featured placement in an app store which can provide a serious spike in downloads. So what approach should you choose? It seems to be like the odds are greatly in favor of the non-native options, but very often that is not the case. As I mentioned, the user experience on non-native apps is just not where it needs to be. Even with hybrid apps, buttons can take a half-second longer to respond to a tap, and scrolling can get slow and choppy. In the beginning of 2011, Facebook's mobile app took a largely hybrid approach. They were faced with considerable user unrest, and suffered a fairly low rating in the app stores. In the middle of the year they re-architected to a much more native experience. Their apps are now faster, more responsive, and the user feedback has improved considerably. At Barefoot Solutions, we always recommend native for any purely consumer facing app. Period. If you want to have a chance at gaining significant traction, it is imperative that you provide the best User Experience possible. It is often better to launch on only a single platform, with an excellent user experience, versus launching a mediocre experience on all platforms. When we start talking about internal apps, mobile web apps and hybrid apps become a much more cost effective solution. For example, if you're building an app to help your sales staff in the field, and this staff uses a variety of devices, it often makes sense to build a hybrid app. This will allow most of your staff to use the app on their devices, and they will most likely be willing to look past the slight lack of performance. If you are a restaurant that just needs contact information, directions, and a menu available on customer's phones, then a mobile website is probably the right strategy for you. Overall, this is a decision not to take lightly. Jumping from one strategy to another often requires an entire rebuild, so it's important to get this right the first time. At Barefoot Solutions, we're happy to provide a free consultation to discuss your mobile strategy and provide an in-depth look at what might be best for your startup or existing company.