You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


Archive for April, 2012

For decades, more than three to be more precise (e.g. see http://www.dei.unipd.it/~pettarin/fsfs2/fsfs2.xhtml), the anti-software patent zealots have been declaring the uselessness of patents on machine-implemented processes, or predicting the end of the software industry as we know it. First, the battle cry was “software patents are useless because software technology evolves too fast for patents to be of use.” But that criticism was soon proved to be false, as a great number of pioneering inventions lasted longer or nearly as long as the 20 year patent term. When the viability of patent protection for programmed computers became evident, the mantra became “software patents will destroy software innovation.” That mantra obviously proved wrong again! Interestingly, some of the most intensive patenting efforts have been undertaken in the mobile computing/smart phone market, where patent protection is now being aggressively used by various innovative companies to fend off unfair copying by imitators or outright intellectual property thieves. Again, far from destroying the smart phone market, the smart phone market continues to grow rapidly, in no small part due to the ability of innovative companies to obtain a fair return on investment in the ground-breaking R&D that has helped fuel that market’s growth.

So one is left to wonder, why do certain elements of the software industry continue to insist that patents on programmed devices such as smart phones, tablet computers or personal computers in general should not be entitled to patent protection simply because they operate in accordance with a sequence of computer instructions instead of being hard-wired?

Recently, it occurred to me that there is indeed a difference, but it is not a difference in the nature of software vs. other technologies, a differentiation that does not stand up to unbiased scrutiny, particularly now that virtually all electronic devices are in large part programmable on one level or another, but rather in the nature of the relationship of inventor to manufacturer. More particularly, in most industries inventors are largely separated or insulated from the management of intellectual property rights – i.e., the typical inventor is told what he or she is permitted to copy or imitate, follows those rules, and generally needs to worry no further concerning the risk of his or her company being sued for misappropriation of another party’s IP.

On the other hand, computer programmers see themselves in a different way: almost all of them see themselves as actual or at least potential manufacturing entities (even if only as a hobby), exposed directly to the responsibilities and risks of a complex system for protecting innovation from being unfairly copied. However, the risk and complexity of the patent system is a cost of doing business beyond the means of the typical programmer. The barrier of the patent system thus becomes personal to a great many software developers, who see it as an infringement on their personal rights, as opposed to a business challenge or opportunity. Again, these business challenges rarely are taken personally by inventors in other disciplines — they almost universally work for the entities that manufacture products and manage the attendant IP rights.

While in the main it is rare for a mom and pop software manufacturer to face ruinous patent threats, as I have pointed out in a prior posting, perhaps the answer to the perpetual software patent debate lies not in trying to reduce intellectual property protection in an age where intellectual property forms a larger and larger part of our nation’s wealth (not to mention playing right into the hands of unscrupulous competitors in copycat countries that are licking their chops at the possibility to clone iPhones, iPads and more), but rather in addressing what is probably the real cause of most software patent consternation by volume – programmers who take patent infringement risk personally. For example, Section 35 U.S.C. 287 (c) of the US patent law provides a limited exemption to surgeons who may infringe a US patent in the course of treating a patient. Perhaps a similarly styled exemption could relieve micro-entity software programmers or companies from liability for producing infringing computer programs until they are given fair notice detailing the basis for infringement, and a reasonable period of time to design around the patent or challenge it in a reexamination proceeding. Of course there would be many loopholes to consider that may make this approach difficult to enact, but I think perhaps this proposal may get the hopelessly deadlocked software patent debate off dead-center and create a win-win situation for all parties.

Last week, an Eastern District of Texas judge granted in part Apple’s motion to intervene in Lodsys’s patent infringement suit against eleven application-developing entities. Lodsys filed the suit in late May 2011 (amended July 2011) and Apple filed its motion to intervene only nine days later. After ten months, the court granted Apple permissive intervention: “Apple is permitted to intervene in this suit, but such intervention is limited to the issues of patent exhaustion and licensing.”

The summary in the public record states:

“SEALED MEMORANDUM OPINION and ORDER – Apple has satisfied each of the four requirements for intervention as a matter of right under Rule 24(a)(2). The Court finds that permissive intervention is also appropriate under Rule 24(b). To avoid any potential prejudice to Lodsys rights under the License Agreement such intervention shall be and is hereby limited to the issues of license and patent exhaustion. Apples Motion to Intervene is GRANTED-IN-PART to the extent and as specified herein. Motions terminated: [4] MOTION to Intervene filed by Apple, Inc.. Signed by Judge Rodney Gilstrap on 4/12/12. (ehs, ) Modified on 4/12/2012 (ch, ).”

Apple’s interest in this suit extends beyond gratuitous defense of its application (app) developers. Apple has an economic interest, having already paid licensing fees to Lodsys for rights to the disputed patents. Apple asserts that the licensed rights cover developers who create apps which are sold and distributed from Apple’s App Store. The developer typically retains 70% of the app’s revenue, while Apple takes 30% for payment processing, hosting services, and content management. Apple contends that its rights extend to developers, giving them the freedom to create applications using Apple’s licensed technology without worrying about claims of patent infringement. Thus, a judgment in favor of Lodsys would give them “two bites at the ‘Apple’” by generating licensing revenue from Apple and infringement damages from Apple’s app developers.

This is the essence of patent exhaustion theory, upon which Judge Rodney allowed Apple to intervene in this suit. Patent exhaustion means that an initial sale of a patented invention severs the patent owner’s rights to that item. More complex issues arise with respect to licensing. A typical example is an upstream supplier licensing a patent such that downstream firms do not have to. This is efficient from both cost and administrative perspectives, but much depends on the language of the license itself. Here, Apple is the “upstream supplier” and the developers are the “downstream firms” that Apple claims to cover.

Apple hopes to succeed in this litigation, as much of its success can be attributed to the “There’s An App For That” culture it fosters. In February 2008, Apple released a software developer’s kit (SDK), opening its iOS operating system for third party app development. Recent figures from Apple illustrate how successful this strategy has been. To date, over 25 billion apps have been downloaded, from the currently available 650,000 apps by 150,000 active developers. This enables Apple to distribute not only apps that nearly every user downloads (e.g. Facebook, Skype, etc.) but also apps that are narrowly tailored to few users (e.g. app for users of the Hennepin County Library). It does so by lowering some of the technical barriers to entry, namely by allowing developers to “copy and paste” certain software objects from Apple into the app itself. For example, if an iPhone app requires a user to type on a keyboard, the app developer is not required to write the code for a keyboard. Rather, the developer can simply “paste” Apple’s keyboard-object into the app. This not only simplifies app development, but increases uniformity across app interfaces.

This is the essence of the Lodsys dispute. Some of these software objects are supposedly patented by Lodsys and licensed to Apple, for example the “App Store” button in the Labyrinth app illustrated in Apples motion to intervene. Lodsys contends that only Apple (and not third-party developers) is covered by the license. Apple disagrees, asserting that its licensed rights protect third-party developers from suits like this one.

Although the outcome of this dispute likely depends on the exact terms of the licensing agreement, some industry watchers believe that a Lodsys triumph this would be a major blow to app developers. Albeit a distinct possibility, Apple would most likely renegotiate its licensing agreement with Lodsys. App developers and Apple have a symbiotic relationship wherein each depends on the other for mutual financial gain. Apple is in a much stronger position to negotiate licensing agreements than an individual developer. If Apple allowed Lodsys (or other similarly situated companies) to obtain judgments against developers, this could limit the very innovation that contributed to Apple’s success. Apple is too smart to kill the goose laying the golden eggs and will most likely continue to defend its app developers.

Yesterday, news broke that Microsoft purchased 800 AOL patents and pending applications for $1.056 billion and also obtained a non-exclusive license to the remaining AOL patents. This amounts to $1.2 million per patent, which is a new high point among recent patent sales. The Motorola and Nortel sales amounted to $700,00 to $750,000 per patent.

This move by Microsoft occurred about a month after AOL hired Evercore Partners to help it find a suitable buyer for its patent portfolio. It is interesting that the initial valuation for the patents, made in February by activist investor, Starboard Value LP, was $1 billion.

Several patent analytics companies have publicly opined on the value of the AOL patent portfolio. M-Cam’s review of the AOL patent portfolio concluded that 71% of AOL’s US patents have “potential commercial impairment.” http://www.m-cam.com/sites/www.m-cam.com/files/20120329%20-%20AOL_0.pdf . M-Cam put a valuation of $290 million on the AOL patent portfolio. M-Cam determined that 76% of the AOL patent portfolio will be in effect for at least another ten years. Four of the patents were reissued. Twenty percent of the AOL patents were originally issued to other entities, in particular, Netscape Communications.

The M-Cam report identified that the technology space surrounding the AOL US patents is dominated by patents owned by IBM, Microsoft, AT&T, Sony, Sun Microsystems, and Cisco, respectively. These companies have substantial numbers of patents that have pre-1991 patent intersections to AOL patents. The term “patent intersections” relates to technology and citation relationships identified by M-Cam analytics. M-Cam ranked Google as number eleven on this list. Google has no patents with early patent intersections in this area but has over 11,000 patents with AOL intersections that are post- 1991. M-Cam concluded that companies with pre-1991 patent intersections “could have leverage over AOL” as they hold patents with similar claims that predate AOL. M-Cam concluded that companies such as Google, Yahoo!, Digimarc and JP Morgan Chase could be licensing targets because of the high incidence of citation to AOL patents. .

The approach of these two companies shows the importance of context in patent valuation. MDB started its analysis by considering likely buyers and what the patent portfolio would mean to them, as well as the “heat” of the market. M-Cam, on the other hand, looked at the details of patents within the AOL portfolio and made its determination based upon the quality of patents within the portfolio. Both approaches have merit. The MDB approach is based upon business factors such as expectations regarding markets, and, “heat”, that is, a knowledge of desires to covet by particular company managements. The M-Cam approach provides an objective analysis of a patent portfolio once the game is played, a particular company wins, and the “heat” cools.

With this move, Microsoft has increased its arsenal of basic internet infrastructure patents and may be in a better position to compete with Google. Time will tell whether the AOL patents purchased are worth the price.

The Court of Appeals for the Federal Circuit will focus on the legal standard for joint infringement in the forthcoming McKesson and Akami opinions. Because of software’s inexorable transition from computer-readable media to network and internet distribution, these opinions significantly affect joint infringement for software inventions.

1. If separate entities each perform separate steps of a method claim, under what circumstances, if any, would either entity or any third party be liable for inducing infringement or for contributory infringement?

2. Does the nature of the relationship between the relevant actors—e.g., service provider/user; doctor/patient—affect the question of direct or indirect infringement liability?

1. If separate entities each perform separate steps of a method claim, under what circumstances would that claim be directly infringed and to what extent would each of the parties be liable?

Akami

At issue in Akamai is Akamai’s Patent No. 6108703 (“’703”), which uses the term “tagging” to describe prepending a URL, as suggested by Limelight’s brief: “www.provider.com/…/story.gif” may become “ghost1467.com/www.provider.com/…/story.gif”. Limelight infringes every step but one of ‘703 by hosting the content and providing an alternate server name to its customers; the customers perform the final step by prepending the server name onto the URL.

Arguing for Akamai, Mr. Dunner’s oral argument proposed three tests:

“One test is direction or control, not ‘and control,’ ‘or control.’ The second test is concert of action. The third test is knowingly combining steps with another. So there are three separate tests, and in each case, there has to be knowledge of what is happening.”

Arguing for Limelight, Mr. Panner cited § 271’s sharp distinction between § 271(a)’s establishment of patent infringement as a strict liability tort, and that knowledge of infringement is required for indirect infringement under § 271(b) or § 271(c).

Judge Newman was clearly uncomfortable with this strict reading of § 271 to Limelight’s admitted desire for the customer to perform the final step. Judge Lourie also indicated discomfort with this outcome. However, this is exactly the arm’s length transaction contemplated by Judge Rader in BMC: “This court acknowledges that the standard requiring control or direction for a finding of joint infringement may in some circumstances allow parties to enter into arms-length agreements to avoid infringement.” (498 F.3d at 1381.) Indeed, that Limelight intended the result and that this portion of Limelight’s website seems to have no substantial noninfringing use (to borrow language from § 271(c)) seems to imply some degree of inequity.

McKesson

At issue in McKesson is McKesson Patent No. 6,757,898 (“‘898”), which covers a method of communication between a patient and a healthcare provider. Defendant Epic’s software “MyChart” infringes every step of the method claim except for the first step: “initiating a communication by one of the plurality of users to the provider for information . . . .”

Mr. Joseffer restated the BMC “direction-or-control” test McKesson advanced in its brief. He was immediately peppered with questions about his assertion that McKesson can prevail under either § 271 (a) or (b) (where § 271 (b) inducement generally requires direct infringement under § 271 (a)), but he clarified that the direction-or-control test broadens legal attribution to cover either (a) or (b).

Judge Dyk inquired about whether this method patent could be enforceable if it had been written entirely from the perspective of the doctor. Mr. Joseffer replied that such a patent could be circumvented if the doctor asked someone in IT to perform at least one step, and explained that requiring a claim construction solution would expand multi-step method claims to an unworkable number of party subcombinations, and that no such construction could be expected to anticipate every possible scenario.

Arguing for Epic, Mr. Moore held to the Supreme Court’s decision in Aro (previously cited against Mr. Joseffer by Judge Moore), which requires performing all steps of a method patent to satisfy § 271 (a) infringement. Mr. Moore went on to explain that § 271 (b) and (c) were created to encompass negligent or intentional acts by secondary or tertiary parties, and that statutory construction interprets their separation to preclude multiple party inducement under (a).

Judge Moore asked, “Then why would you ever file for inducement if, in your theory, the direct infringer would be the same person as the inducer because he is, in the common-law sense, making them act as his agent. 271 (b) would be superfluous in your statutory interpretation because it would be entirely encapsulated under 271 (a).” Subsequent questioning, alas, did not clear up this apparent contradiction before the end of Mr. Moore’s time.

Conclusion

The Federal Circuit did not seem eager to adopt Akamai’s knowledge test, nor did they seem satisfied by McKesson’s argument that all patents must have a remedy. The Judges may not find explicit support in § 271 or previous method patent cases, but seem to be open to expanding the direction-or-control test to avoid circumvention of method patents. Though the oral arguments provided some insight the concerns of Judges Linn, Prost, Moore, Dyk, Bryson, and Newman, we are left to extrapolate the proclivities of the quieter Judges Lourie, O’Malley, Reyna, and silent Chief Judge Rader.

The outcome will have a significant effect on authoring method claims, especially as applied to software patents. As such, we eagerly anticipate the decision, expected later this spring.

Recently, the Supreme Court decided Mayo Collaborative Services (“Mayo”) v. Prometheus Laboratories, Inc. (“Prometheus”). Although it does not involve software patents, the decision clarifies the proper place of the Machine-or-Transformation test in section 101 analysis, discusses abstract principles of nature, and rejects a recent suggestion by the Federal Circuit to invalidate a claim under Section 101 only after it first passes muster under Sections 102, 103 and 112.

At issue here are two patents—U. S. Patent No. 6,355,623 (’623 patent) and U. S. Patent No. 6,680,302(’302 patent)—which, cover “processes that help doctors who use thiopurine drugs to treat patients with autoimmune diseases determine whether a given dosage level is too low or too high.” Id. at 3. Mayo Collaborative Servs. v. Prometheus Labs., Inc., No. 10–1150, slip op. at 5 (Mar. 20, 2012). “The claims purport to apply natural laws describing the relationships between the concentration in the blood of certain thiopurine metabolites and the likelihood that the drug dosage will be ineffective or induce harmful side-effects.” Id. at 3.

Claim 1 of the ’623 Patent is illustrative:
A method of optimizing therapeutic efficacy for treatment of an immune-mediated gastrointestinal disorder, comprising:
(a) administering a drug providing 6-thioguanine to a subject having said immune-mediated gastrointestinal disorder; and
(b) determining the level of 6-thioguanine in said subject having said immune-mediated gastrointestinal disorder,
wherein the level of 6-thioguanine less than about 230 pmol per 8×108 red blood cells indicates a need to increase the amount of said drug subsequently administered to said subject and
wherein the level of 6-thioguanine greater than about 400 pmol per 8×108 red blood cells indicates a need to decrease the amount of said drug subsequently administered to said subject.
’623 patent, col. 20, ll. 10–20, 2 App. 16.

Prometheus “is the sole and exclusive licensee of the ’623 and ’302 patents.” Id. at 6. “It sells diagnostic tests that embody the processes the patents describe.” Id. This dispute arose when Mayo stopped using the Prometheus test and “announced that it intended to begin using and selling its own test.” Id. The District Court found for Mayo, noting that although its test did infringe Prometheus’s patents, the patents were invalid as they claimed natural laws. Id. at 6–7. On Appeal, the Court of Appeals for the Federal Circuit reversed, noting that the invention met the machine-or-transformation test because the steps in the claims “involve the transformation of the human body or of blood taken from the body.” Id. at 7.

Upon review, the Supreme Court rejected the Federal Circuit’s analysis and held that the patents were invalid. Id. at 24. On the one hand, this decision can be read quite narrowly. The Court does say it is not persuaded that there is a relevant transformation here and, accordingly, the machine-or-transformation test fails. Id. at 19. There is, however, a lot more to this decision than a mere disagreement as to how the machine-or-transformation test applies to Prometheus’s claimed invention. The Court also says that “the ‘machine-or-transformation’ test is an ‘important and useful clue’ to patentability,” but it does not “trump[] the ‘law of nature’ exclusion.” The Court further explained, “all inventions at some level embody, use, reflect, rest upon, or apply laws of nature, natural phenomena, or abstract ideas.” Id.at 2. The question then becomes “whether the claimed processes have transformed these unpatentable natural laws into patent eligible applications of those laws.” Id. at 3.

Ultimately, we are left with little guidance from the Court. It is quite clear that analysis under Section 101 is here to stay. It also clear that the machine-or-transformation is now a useful clue rather than a test. But a new test was not provided. Only time will tell how the courts, the USPTO, and practitioners apply this decision.

Machine-or-Transformation is not always enough.
With a bit of sleight of hand, the Court cites Bilski v. Kappos for the proposition that the machine-or-transformation test “is not a definitive test of patent eligibility, but only an important and useful clue.” Id. at 7. It is helpful to look back at Bilski to spot the sleight of hand. “This Court’s precedents establish that the machine-or-transformation test is a useful and important clue, an investigative tool, for determining whether some claimed inventions are processes under § 101. The machine-or-transformation test is not the sole test for deciding whether an invention is a patent-eligible ‘process.’” Bilski v. Kappos, 130 S. Ct. 3218, 3227 (2010). Bilski never said that the machine-or-transformation was insufficient to determine whether a process was patent-eligible. Instead, it said that there might also be other ways to identify a patent-eligible process. After Mayo, the machine-or-transformation test is not really a test at all. Rather, it is, as the Court says, a useful clue.

The transformation branch of the machine-or-transformation test now seems less than dispositive. This suggests that software patents should, when possible, include claims that tie the invention to a machine. Claims that are tied to a machine are often more difficult to draft broadly than a process claim, so include both. More importantly, claims directed to software inventions should be described, as much as possible, in terms of actual electronic circuits that are programmed to carry out a series of electronic operations. The more detail provided at the electronic circuit level, the better.

Applying an abstract principal of nature is not enough.
It has long been understood that a principle of nature cannot be patented. See Mayo, at 1. The Court also explains that “to transform an unpatentable law of nature into a patent-eligible application of such a law, one must do more than simply state the law of nature while adding the words ‘apply it.’” Id. at 3. To cover patent-eligible subject matter, the claim must contain an “‘inventive concept,’ sufficient to ensure that the patent in practice amounts to significantly more than a patent upon the natural law itself.” Id. This again suggests that narrow claims are more likely to withstand judicial scrutiny. At times, the Court discusses algorithms in the same breath as principles of nature – as though algorithms are all laws of nature floating in the ether awaiting discovery. Claims tied to a machine do not ensure that the “invention” therein recited is patent-eligible, but could improve the odds that the claimed invention will be viewed as a Seciton 101 compliant “machine.”

Section 101 is not going away.
The Court also weighed in on the ongoing debate in the Federal Circuit on the judicial morass of section 101, which we have discussed previously. In rejecting a proposal offered by the United States as Amicus Curiae, the Court said that relying on Sections 102, 103, and 112 in place of Section 101 would be inconsistent with prior case law. Id. at 20–22. Further, this approach would “creat[e] significantly greater legal uncertainty.” Id. at 21. The Court did acknowledge that there at times may be overlap between Section 101 analysis and the other sections of the patent act. Id. But it also noted that the other sections are unequipped to deal with laws of nature. Id. It seems that Section 101 analysis and uncertainty is here to stay.