Obviousness

Obviousness Analysis of U.S. Patent 9,824,408 under 35 U.S.C. § 103

This analysis evaluates the obviousness of U.S. Patent 9,824,408 (the '408 patent) based on the provided prior art, focusing on independent claims 1, 10, and 18. The central innovative aspect of the '408 patent, as highlighted in the prior art analysis, is the use of a "browser payment request API" for communicating payment data between a merchant site and a user's browser to streamline online purchases.

Combination of Prior Art References

A compelling argument for obviousness can be made by combining U.S. Patent Application Publication No. 2013/0290074 A1 ("Guest Checkout" by Google Inc.) with the general knowledge of a person having ordinary skill in the art (PHOSITA) regarding Application Programming Interfaces (APIs) and browser capabilities prevalent at the priority date of the '408 patent (March 31, 2014).

Primary Reference: U.S. Patent Application Publication No. 2013/0290074 A1 (hereinafter, "'074 A1")

• Disclosure: The '074 A1 publication describes a "guest checkout" process where a user, logged into a primary account (e.g., a Google account), can make a purchase on a merchant website without needing to create a separate account with that merchant. The primary account provider securely transmits the necessary payment and shipping information to the merchant to complete the transaction. This reference clearly teaches:
  • A user interaction with an object associated with a site (e.g., a buy button on a merchant's page) indicating an intent to purchase.
  • The concept of a central entity (the primary account provider) storing user payment data.
  • The secure transmission of this payment data to a merchant site for processing a purchase, thereby simplifying the checkout process and reducing repetitive data entry for the user.

Secondary Reference / General Knowledge of a PHOSITA (as of March 31, 2014)

A PHOSITA in the field of web development and e-commerce in early 2014 would have possessed the following common knowledge:

• Application Programming Interfaces (APIs): APIs were a well-established and widely used method for different software components, whether client-side (like web browsers) or server-side (like websites), to communicate, exchange data, and expose functionalities in a structured and programmatic manner.
• Browser Capabilities: Web browsers were recognized as sophisticated user agents capable of managing user-specific data (e.g., autofill for forms, cookies) and serving as the primary interface for user interactions with web content and applications. They were increasingly becoming platforms for richer applications and standardized functionalities.
• Motivation for Standardization and User Experience Improvement: The e-commerce industry constantly sought ways to reduce friction in the purchasing process, increase conversion rates, and standardize interactions across diverse merchant platforms. The problem of cumbersome form-filling for online purchases, especially outside of specific "one-click" environments like Amazon.com, was a recognized challenge, as explicitly articulated in the background of the '408 patent.

Motivation to Combine and Obviousness Rationale

A PHOSITA, aiming to improve upon the guest checkout system described in the '074 A1 publication, would have been motivated to integrate the payment data transmission directly into the browser's functionality via a standardized API.

1. Addressing Inefficiencies of '074 A1: While '074 A1 streamlines guest checkout through a primary account provider, its implementation might still involve custom integrations or specific backend interactions between each merchant and each primary account provider. This approach lacks universal applicability and can be complex to scale across the vast and varied landscape of online merchants.
2. Standardization and Ubiquity: A PHOSITA would recognize that by embedding the payment data communication mechanism directly into the browser itself, via a standardized API, a more universal solution could be achieved. The browser is the common client-side platform for all web interactions. A browser-native API for payment requests would enable any merchant site to leverage a user's securely stored payment information directly from their browser, eliminating the need for each merchant to integrate individually with numerous separate payment service providers or digital wallets. This would significantly reduce development overhead for merchants and provide a consistent experience for users.
3. Enhanced User Experience: Moving the payment data exchange into a browser-level API would allow the browser to act as a more direct and transparent intermediary. The browser could present standardized payment prompts, allow users to select from various stored payment methods, confirm purchases, and securely transmit the necessary data. This would provide a more seamless and intuitive user experience compared to relying solely on backend transmissions from a third-party account provider, directly addressing the "long-felt problem" of reducing user interactions (e.g., form-filling) in online purchases, as emphasized in the '408 patent. This motivation directly aligns with the objective of claims 1 and 18, which focus on the user agent's role in facilitating the purchase and autopopulating fields.
4. Security and Control: Placing the API within the browser would centralize user payment information management on the user's device (or within the browser's secure context), potentially offering enhanced user control and a perceived increase in security for managing payment credentials for online transactions.

How the Combination Renders Claims Obvious:

By combining the teaching of '074 A1 (streamlined guest checkout using centrally stored payment data transmitted to a merchant) with the general knowledge of APIs and browser functionality:

• Claim 1 (Method by User Agent): The '074 A1 teaches the interaction indicating purchase intent and the need to transmit payment data to the site. A PHOSITA, seeking to standardize and improve this transmission, would find it obvious to implement the request from the site and the subsequent transmission of payment data "via an application programming interface" within the browser (user agent).
• Claim 10 (Method by Site): The '074 A1 teaches a site receiving payment information to make a purchase. A PHOSITA, motivated by efficiency and standardization, would find it obvious for the site to "transmit, to an application programming interface, a request for payment account data" and "receive, at the site and via the application programming interface, the payment account data" from the user's browser, and then use this data to populate payment fields.
• Claim 18 (Method by User Agent with Autopopulation): Similar to claim 1, '074 A1 establishes the context of receiving a request and transmitting data for a purchase. The explicit step of "autopopulating a payment field associated with the presentation with the payment account data" is an obvious consequence of receiving structured payment data via an API, a capability well within the scope of browser functions like autofill, further enhanced by the direct and programmatic data exchange.

Therefore, a PHOSITA would have been motivated to combine the core functionality of the '074 A1 guest checkout system with the known utility of APIs and browser capabilities to create a generalized and streamlined web payment system involving a browser payment request API, rendering claims 1, 10, and 18 of the '408 patent obvious.