Obviousness

The analysis of obviousness under 35 U.S.C. § 103 for US patent 7,177,838 requires identifying combinations of prior art that would have made the claimed invention obvious to a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date January 26, 2000).

The independent claims of US7177838 cover:

• Claim 1 (Vendor's method): A vendor's server establishing a user account, the user purchasing electronic tokens from the vendor, the server storing tokens, the user selecting items, the server calculating token cost, and debiting the account if sufficient tokens are available.
• Claim 12 (User's method): A user's perspective of establishing an account, purchasing tokens from the vendor, selecting items, being informed of costs, and confirming a purchase leading to account debit.
• Claim 21 (Vendor's apparatus): A vendor's server configured to perform the method steps of Claim 1, including selling electronic tokens directly to users.
• Claim 31 (Token transfer between users): A vendor's server establishing accounts for multiple users, the vendor selling tokens to a first user, the first user authorizing transfer to a second user, and the server facilitating the debit/credit for transfers (e.g., for an auction site).

The patent explicitly identifies the problems in the prior art that it seeks to overcome: the necessity for users and merchants to deal with a "central organization, such as a bank" for electronic currency (e.g., eCash, InternetCash, Beenz), which imposes overhead and limits vendor control over token value and terms [cite: Description, Section: BACKGROUND OF THE INVENTION]. The patent aims to provide a system where the vendor itself issues and controls the electronic tokens, accepts various payment options (online and offline) for these tokens, and thereby reduces overhead and increases vendor control and privacy.

Combination of Prior Art for Obviousness

A PHOSITA in electronic commerce in 2000, aware of existing systems and their limitations, would have been motivated to combine certain known elements to achieve the objectives addressed by US7177838.

Key Prior Art References and their Relevant Disclosures:

1. eCash (ecash Technologies Incorporated): This system permits "micropayments" and allows users to purchase products and services on the Web without using a credit card. It relies on "eCash" banks to issue currency, which users spend on vendor sites, and vendors exchange for traditional money through an "eCash" bank. It involves user accounts for storing currency [cite: Description, Section: BACKGROUND OF THE INVENTION].
2. RocketCash (RocketCash Corporation): This system sets up accounts for users (e.g., teens) and allows their parents to add money to these accounts using various payment methods, including "checks, money orders, or credit cards." Users can then shop on the Web, and purchases are billed to their RocketCash account. While it eliminates the need for credit cards for transactions, it operates through a "single central entity (i.e. RocketCash Corporation)" for account management and funding [cite: Description, Section: BACKGROUND OF THE INVENTION].
3. General E-commerce Practices (Pre-2000): It was well-established for vendors to operate Web sites, display products and services, maintain user accounts, and process purchase orders. Application service providers (ASPs) were already offering software for sale or rental, managing authorization codes, and looking for ways to minimize client-server interaction and sensitive data transmission [cite: Description, Section: BACKGROUND OF THE INVENTION].

Obviousness Argument:

The primary distinguishing feature of US7177838 is that the vendor directly issues and sells the electronic tokens, and maintains user accounts for these tokens, thereby cutting out the traditional third-party bank or central organization. This includes accepting both online (e.g., credit card) and offline (e.g., check, money order) payments for the tokens.

A PHOSITA would have been motivated to combine the features of eCash, RocketCash, and general e-commerce practices for the following reasons:

• Addressing Overhead and Control: The '838 patent itself highlights the problem that existing systems (like eCash, InternetCash, Beenz) "necessarily impose overhead" because "both the vendors who accept these various forms of electronic currency, and the users who buy items in exchange for electronic currency must deal with a central organization, such as a bank." It also notes that vendors have "no control over the value of the electronic currency, its sale price, the terms on which it may be bought" [cite: Description, Section: BACKGROUND OF THE INVENTION]. A PHOSITA would clearly understand the commercial desirability of overcoming these limitations.

• Combining Electronic Currency with Flexible Funding:

  • eCash taught the use of electronic currency/tokens for efficient online transactions, including micropayments, and the management of user balances.
  • RocketCash demonstrated a "central entity" (RocketCash Corporation, not a bank) that managed user accounts and, crucially, allowed these accounts to be funded by various means, including checks, money orders, or credit cards. This explicitly teaches the technical concept of a non-bank entity accepting both online and offline payments to load value into user accounts.

Motivation to Combine:
A PHOSITA, seeking to eliminate the "overhead" and gain "complete control over the sale and distribution of electronic currency or tokens" (as articulated in the '838 patent's summary [cite: Description, Section: SUMMARY OF THE INVENTION]), would naturally be motivated to integrate the electronic token concept of eCash with the flexible account funding and management approach of RocketCash, by having the vendor of goods and services directly assume the role of the "central entity" (like RocketCash Corporation).

• If RocketCash Corporation could manage accounts and accept diverse payment methods (online and offline) to fund those accounts, it would be an obvious step for a PHOSITA to realize that a vendor could perform these same functions. The vendor would then issue its own "eCash-like" tokens, storing them in user accounts funded directly by the user using online or offline payments, mirroring RocketCash's funding methods. This directly addresses the stated problems of third-party reliance and lack of vendor control, as the vendor now directly controls the issuance, value, and funding methods of its proprietary tokens.

Application to Specific Claims:

• Claims 1, 12, and 21 (Vendor/User Transaction and Apparatus): The combination renders these claims obvious. The vendor operating a server to establish accounts, accept payments (online/offline, as taught by RocketCash) for its own electronic tokens (as generally taught by eCash, but now vendor-issued), store these tokens, present products for token purchase, and process transactions is a straightforward application of existing technologies with an obvious motivation to improve efficiency and control. The concept of using these tokens for software purchase or rental (including various rental terms like time, uses, or processings) is an application of the token system to a known business model (ASP software rental, as detailed in the '838 background), not a distinct invention in the token system itself.

• Claim 31 (Token Transfer Between Users): Once a vendor-issued token system (as made obvious by combining eCash and RocketCash) is established, extending it to permit transfers between user accounts within that vendor's system (e.g., for an auction site) is an obvious implementation choice for a PHOSITA. Auction sites already existed and facilitated transactions between users. The '838 patent itself describes this as a way for "users to exchange electronic tokens issued by a vendor" and "paying each other for products and services, without having to obtain and send a money order" [cite: Description, Section: DETAILED DESCRIPTION OF THE INVENTION, referring to FIG. 13]. The motivation for an auction site vendor (acting as the token issuer) to enable such transfers to streamline internal payments would be clear.