UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD UNIFIED PATENTS INC. Petitioner v. FINNAVATIONS LLC Patent Owner USS. Patent No. 8,132,720 Filing Date: May 15, 2008 Issue Date: March 13, 2012 Title: Financial Management System PETITION FOR INTER PARTES REVIEW UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 42.100 ET SEQ.TABLE OF CONTENTS L INTRODUCTION ...... Il. |. MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(B)... REAL PARTIES IN INTEREST . RELATED MATTERS... DESIGNATION OF LEAD COUNSEL... A. B. ©. PAYMENT OF FEES........ D. E. SERVICE INFORMATION ......... F. POWER OF ATTORNEY ..... TI. REQUIREMENTS FOR INTER PARTES REVIEW... A. GROUND FOR STANDING... B. IDENTIFICATION OF THE PRIOR ART REFERENCES... 1. U.S. Pat. No. 5,815,657 to Williams (““Williams” 2. U.S. Pat. No. 5,920,848 to Schutzer (“Schutzer”).. 3. U.S. Pat. No. 5,842,185 to Chancey (“Chancey”) 4. L Pat. No. 5,903,88: to Schrader (“Schrader”). 5. U.S. Pat. No. 6,394,34! to Makipaa (“Makipaa”). 6. U.S. Pat. No. 5,521,363 to Tannenbaum (“Tannenbaum”)... C. STATEMENT OF THE PRECISE RELIEF REQUESTED, IV. OVERVIEW OF THE ‘720 PATENT... A. — PRIORITY DATE OF THE ‘720 PATENT...B. SUMMARY OF THE ‘720 PATENT... C. SUMMARY OF RELEVANT PROSECUTION FILE HISTORY .. D. PERSON OF ORDINARY SKILL IN THE ART .-.sccsssssssssssssssensee 9 = E. | PROPOSED CLAIM CONSTRUCTION... 1. “online transaction”... 2. “at the conclusion of an online transaction” 3. “a reminder for a financial ransaction consummated online” 4. “suggested name”. V. PROPOSED REJECTIONS SHOWING THAT PETITIONER HAS A REASONABLE LIKELIHOOD OF PREVAILING A. GROUND 1: CLAIMS 1-7 & 11-20 ARE OBVIOUS OVER WILLIAMS IN VIEW OF CHANCEY..... B. | GROUND 2: CLAIMS 8-10 ARE OBVIOUS IN VIEW OF WILLIAMS, CHANCEY AND SCHRADE! C. GROUND 3: CLAIMS 1-7, 11-12 AND 14-18 ARE OBVIOUS, OVER SCHUTZER IN VIEW OF CHANCEY .. D. GROUND 4: CLAIMS 8-10 ARE OBVIOUS OVER SCHUTZER IN VIEW OF CHANCEY AND SCHRADER.........- 51 - E. GROUND 5: CLAIM 13 AND 19-20 ARE OBVIOUS OVER SCHUTZER IN VIEW OF CHANCEY, MAKIPAA AND TANNENBAUM... IV. CONCLUSIONEXHIBIT LIST Exhibit No. | Description 1001 U.S. Patent No. 8,132,720 to Dyor 1002 Declaration of Michael Shamos (‘Shams Declaration”) 1003 Resume of Michael Shamos 1004 USS. Patent No. 5,815,657 to Williams, Prior Art under 35, U.S.C. § 102(b) 1005 U.S. Patent No. 5,842,185 to Chancey (Intuit), Prior Art under 35 USC. § 102(b) 1006 U.S. Patent No. 5,903,881 to Schrader (Intuit), Prior Art under 35 U.S.C. § 102(b) 1007 U.S. Patent No, 5,920,848 to Schutzer, Prior Art under 35 U.S.C. § 102(b) 1008 U.S. Patent No. 6,394,341 to Makipaa, Prior Art under 35 U.S.C. § 102(e) 1009 LS. Patent No $,571,3463 to Tannenhanm, Prior Art under 35 USC. § 102(b) 1010 U.S. Patent No. 6,446,048 to Wells, Prior Art under 35 U.S.C. § 102(e) 1011 Unified Patents LLC Voluntary InterrogatoriesL INTRODUCTION Petitioner UNIFIED PATENTS INC. (“Unified” or “Petitioner”) respectfully petitions for initiation of inter partes review of Claims 1-20 of U.S. Patent No. 8,132,720 (the “ ‘720 Patent”) in accordance with 35 U.S.C. §§ 311~ 319 and 37 CFR. § 42.100 et seq. (“Petition”). Il. MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(B) A. REAL PARTIES IN INTEREST Pursuant to 37 C.F.R. § 42.8(b)(1, Petitioner certifies that Unified is the real party-in-interest, and further certifies that no other party exercised control or could exercise control over Unified’s participation in this proceeding, the filing of this petition, or the conduct of any ensuing trial. See Ex. 1010, Unified Patents LLC Voluntary Interrogatories. B. RELATED MATTERS Li jon Finnavations, LLC v. Alliance Bank, 2-15-cv-00479, TXED, April 13, 2015 Finnavations, LLC v. Bank of America Corporation, 2-15-cv-00480, April 13, 2015 Finnavations, LLC v. BBVA Compass Financial Corporation, 2-15-cv-00481, TXED, April 13, 2015Finnavations, LLC v. Capital One, National Association, 2-15-cv-00482, TXED, April 13, 2015 Finnavations, LLC v. Capital One, National Association, 2-15-cv-00483, TXED, April 13, 2015 Finnavations, LLC v. Charles Schwab & Co., Inc., 2-15-cv-00484, TXED, April 13, 2015 Finnavations, LLC v. Citizens Bank, National Association, 2-15-cv-00485, TXED, April 13, 2015 Finnavations, LLC v. First-Citizens Bank & Trust Company, 2-15-cv-00486, ‘TXED, April 13, 2015 Finnavations, LLC v. First Republic Bank, 2-15-cv-00487, TXED, April 13, 2015 Finnavations, LLC v. Frost Bank, 2-15-cv-00488, TXED, April 13, 2015 Finnavations, LLC v. HSBC Bank USA, National Association, 2-15-cv-00489, TXED, April 13, 2015 Finnavations, LLC v. JPMorgan Chase Bank, National Association, 2-15-cv-00490, TXED, April 13, 2015 Finnavations, LLC v. Keycorp Finance, Inc., 2-15-cv-00491, TXED, April 13, 2015Finnavations, LLC v. The PNC Financial Services Group, Inc., 2-15-cv-00492, TXED, April 13, 2015 Finnavations, LLC v. Prosperity Baneshares, Inc., 2-15-cv-00496, TXED, April 13, 2015 Finnavations, LLC v. Silicon Valley Bank, 2-15-cv-00497, TXED, April 13, 2015 Finnavations, LLC v. US Bank, National Association, 2-15-ev-00498, TXED, April 13, 2015 Related patent U.S. Pat. 7,389,915. C. PAYMENT OF FEES This Petition is accompanied by a payment of $25,000 and requests review of Claims 1-20 of the ‘720 Patent, 37 C.FR. § 42.15. Thus, this Petition meets the fee requirements under 35 U.S.C. § 312(aX(1). D. DESIGNATION OF LEAD COUNSEL Lead Counsel for Petitioner is Paul C. Haughey (Reg. No. 31,836), of Kilpatrick Townsend & Stockton LLP. Beck-up Counsel is Scott E. Kolassa (Reg. No. 55,337), of Kilpatrick Townsend & Stockton LLP.E, SERVICE INFORMATION As identified in the attached Certificate of Service, a copy of this Petition, in its entirety, is being served to the address of the attorney or agent of record in the Patent Office for the 720 Patent. Petitioner may be served at the offices of their counsel, Kilpatrick Townsend & Stockton LLP. F, POWER OF ATTORNEY Powers of attorney are being filed with the designation of counsel in accordance with 37 C.F.R. § 42.10(b). Ill. REQUIREMENTS FOR INTER PARTES REVIEW A. GROUND FOR STANDING: ‘The ‘720 Patent is currently asserted in a co-pending litigation, and this Petition is being filed within one year of Petitioner being served with a complaint for patent infringement (Petitioner has not been sued or served). Petitioner is not the owner of the ‘720 Patent and Petitioner is not barred or estopped from requesting IPR. Thus, the ‘720 Patent is eligible for inter partes review. B. IDENTIFICATION OF THE PRIOR ART REFERENC 1. U.S. Pat. No. 5,815,657 to Williams (“Williams”). Williams is a Verifone patent directed to an electronic wallet for use on the Internet with multiple electronic credit cards, and the ability to capture transactionswith a GUI and download them to Quicken, Williams was not cited, and predates the ‘720 Patent priority date by over 3 years. 2. U.S. Pat. No. 5,920,848 to Schutzer (“Schutzer”). Schutzer is a Citibank patent describing intelligent agents for online banking, bill payment and stock purchases. A GUI captures transaction information, which can be exported to Quicken. Schutzer was not cited, and predates the ‘720 Patent priority date by more than a year. 3. U.S. Pat. No. 5,842,185 to Chancey (“Chancey”) Chancey is an Intuit patent describing improvements to Intuit’s Quicken product, and shows explicitly prompting the user to enter a category code, or automatically assigning a category based on the type of merchant, with transactions downloaded using a madem Chancey was not cited, and predates the ‘720 Patent priority date by over 5 years. AUS) Pat. No. 5,903,881 to Schrader (“Schrader”). Schrader is another Intuit patent describing improvements to Intuit’s Quicken product, and explicitly discloses list of previous payees (merchants), a feature in some ‘720 Patent dependent claims. Schrader was not cited, and predates the ‘720 Patent priority date by over 2 years.US. Pat. No. 6,394,341 to Mikipai (“Miakipaa”), is a Nokia patent directed to electronic receipts, and shows capturing an itemized list of transactions for downloading to Quicken, a feature of “720 Patent dependent claims. Makipa was cited in an IDS in the ‘720 Patent file history, but was not mentioned by the Exaniner, and predates the ‘720 Patent priority by one month. 6. U.S. Pat. No. 5,521,363 to Tannenbaum (“Tannenbaum”). Tannenbaum describes a memory card for capturing itemized transaction details, similar to Makip’a, and downloading them to Quicken. Tannenbaum was not cited, and predates the ‘720 Patent priority date by over 5 years. C. STATEMENT OF THE PRI ISE RELIEF REQUESTED Pursuant to 35 LIS.C. § 311, this Petition requests cancellation of Claims 1- 20 of the *720 Patent in accordance with ore or more of the following grounds, as indicated in the discussion below. Two main references are used, Williams and Schutzer, both in combination with Chancey, with additional references for certain dependent claims. Ground 1: Claims 1-7 & 11-20 are obvious over Williams in view of Chancey Ground 2: Claims 8-10 are obvious over Williams, Chancey & Schrader aeGround 3: Claims 1-7, 11-12 & 14-18 are obvious over Schutzer in view of Chaneey. Ground 4: Claims 8-10 are obvious over Schutzer in view of Chancey & Schrader. Ground 5: Claim 13 & 19-20 are obvious over Schutzer in view of Chancey, Mikipii & Tannenbaum. IV. OVERVIEW OF THE ‘720 PATENT A. PRIORITY DATE OF THE ‘720 PATENT The *720 Patent is a continuation of application Ser. No. 09/664,587 filed Sep. 18, 2000, now Pat. 7,389,915 (the “ ‘915 Patent”), which claims priority to provisional application No. 60/155,102 filed Sept. 22, 1999. B. SUMMARY OF THE ‘720 PATE The ‘720 Patent is summarized in the Abstract: “A financial management sysiem includes a client terminal having a financial management application and a graphical user interface. The graphical user interface is configured to display transaction data, enable user modification of the transaction data, and transmit modified transaction data to the financial management application. “ The ‘720 Patent references Quicken from Intuit as the “financial management application.” The ‘720 Patent claims are directed to providing a GUIwith online transaction information, providing the user the ability to enter an expense category for the transaction, and efter the user clicks “accept,” downloading the transaction data to Quicken or another financial management program. Fig. 3 copied below illustrates the GUI. | Pa | Purchase Date Purchase Amount| Online Payee Credit Card # FIG. 3 C. SUMMARY OF RELEVANT PROSECUTION FILE HISTORY ‘The parent ‘915 Patent was rejected multiple times before finally being allowed. The ‘915 Patent issued with system claims, setting forth both a commercial server and a consumer terminal. ‘Ihe ‘720 Patent only received §112 rejections , which were overcome by cancelling the claims and submitting new -8-claims which were allowed. None of the cited references was as close as the prior art cited herein. Makipiii Pat. 6,394,341 relates to electronic receipts and was cited in an IDS, but was not mentioned by the Examiner. The examiner cited other references at the time of allowing the ‘720 Patent, but without discussion. The only patents discussed by the Examiner were in the parent ‘915 Patent file history. Treyz Pat. 6,587,835, cited by the examiner in a rejection, describes a handheld computing device that wirelessly interacts with a supermarket computer for transactions. Green Pat. 5,664,110, cited by the examiner in a rejection, describes a remote ordering system. Sullivan Pat. 6,999,990, cited by the examiner in a rejection, describes an Internet help session, with history tracked. Friedman Pat. 6,965,912, cited by the examiner in a rejection, shows an electronic greeting card system. D. PERSON OF ORDINARY SKILL IN THE ART One of ordinary skill in the art at time of the earliest claimed effective filing date of the ‘720 Patent (Sept. 22, 1999) would have an undergraduate degree in computer science, or equivalent work experience, including familiarity with graphical user interfaces (GUIs), financial recordkeeping, the XML markup language and World Wide Web communication. See Shamos Declaration §9-11.PROPOSED CLAIM CONSTRUCTION Pursuant to 37 C.F.R. § 42.100(b), the claim terms of an unexpired patent subject to inter partes review shall receive the “broadest reasonable construction in light of the specification of the patent in which [they] appearf].” See also In re Swanson, No. 07-1534 (Fed. Cir. 2008); In re Trans Texas Holding Corp., 498 F.3d 1290, 1298 (Fed. Cir. 2007) (citing In re Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984).) In compliance with 37 C.F.R. § 42.104(b)(4), Petitioner states that, in general, the “claim terms are presumed to take on their ordinary and customary meaning.” See Changes to Implement Inter Partes Review Proceedings, Post-Grant Review Proceedings, and Transitional Program for Covered Business Method Patents, 77 Fed, Reg. 48699 (2012), Response to Comment 35. However, where a definitioa is provided by a patent applicant for a specific claim term, that definition will control interpretation of the term as it is used in the claim. See, e.g., Toro Co. v. White Consolidated Indus., Inc., 199 F.3d 1295, 1301 (Fed. Cir. 1999), All claim terms not specifically addressed below have been accorded their broadest reasonable interpretation in light of the patent specification, including their plain and ordinary meaning, to the extent such a meaning could be determined by a skilled artisan. aieThere have been no claim construct:on briefs or orders yet in the related District Court litigation. Petitioner proposes to adopt the following constructions based on the reasons below and as set forth in Shamos Declaration f] 32-50. Claim Terms 1 “online transaction” This is not defined in the ‘720 Patent, and alternate uses are “online commercial transaction” (‘720 Patent 1:67) and “online financial transaction” (‘720 Patent Abstract). Since “online transaction” isn’t modified, it is presumed to be broader. Since “online” is not defined, its ordinary use of using a computer network is assumed. Accordingly, Petitioner submits the broadest reasonable interpretation of a “online transaction” is any transaction that is conducted in whole or in part using a computer network. See Shamos Declaration § 34. 2. “at the conclusion of an online transaction” The only mention of “conclusion” outside the claims is “...the Financial Assistant could be invoked upon the occurrence of a predetermined event, such as the commencement or conclusion of an online transaction.” eePetitioner submits the broadest reasonable interpretation of a “at the conclusion of an online transaction” is after the online transaction has concluded. Sce Shamos Declaration ff] 35-36. 3. “a reminder for a financial transaction consummated online” Outside of claims 12 and 19, the only place the term “reminder” appears in the ‘720 Patent is in the Background: “However, the present financial management systems provide neither a mechanism for creating reminders for financial transactions consummated online, nor for directly entering information associated with online transactions.” (‘720 Patent 1:51-55). This claim language was introduced in the 9-21-2011 amendment as new claims, with the only comment being “New claims 15-34 recite substantially the same claim language, albeit different claim scope, of the issued parent case, US Patent No 7,389,915.” Thus, the “reminder” is simply the presentation of the GUI for a transaction, which “reminds” the user to enter a category and download it to the financial management program (e.g., Quicken) Accordingly, Petitioner submits the broadest reasonable interpretation of a “a reminder for a financial transaction consummated online” is a prompt for selection of a category for a financial transaction consummated online. See Shamos Declaration ff 46-50.4. “suggested name” Dependent claim 9 recites “wherein the web browser provides a suggested name based on the name of the merchant.” The term “suggest” only appears in the claims, and there is no description of providing a suggested name in the ‘720 patent, only that the category could be based on previous categories. The language of claim 9 first appeared in the file history in the 11-29-2006 amendment in the parent ‘915 patent as new claim 25. Origiral claim 10 of the parent ‘915 patent was nearly identical, hut recited “provides a suggested category based on the name of the merchant.” Accordingly, Petitioner submits the broadest reasonable interpretation of a “suggested name” is suggested category name. See Shamos Declaration {| 42. V. PROPOSED REJECTIONS SHOWING THAT PETITIONER HAS A REASONABLE LIKELIHOOD OF PREVAILING Summary of the grounds of rejection. ‘The ‘720 Patent independent claims are directed to providing a GUI with online transaction information, providing the user the ability to enter an expense category for the transaction, and after the user clicks “accept,” downloading the transaction data to Quicken or another financial management program. The Background of the ‘720 Patent acknowledges that in the prior art, using Quicken, a user can “download credit card charges from a number of member banks.” ‘720Patent 1:47-48. The prior art supposedly cid not provide a mechanism “for directly entering information associated with online transactions.” Id., 1:54-55. The prior art also supposedly “store[s] data only about the total transaction amount, but fail[s] to store information about the particular items purchased and the costs of the particular items.” Id. 1:56-58. Note that this feature (storing data regarding the particular items purchased) only appears in claims 13 and 19-20. The closest prior art before the Examiner of the ‘720 Patent was Makipaai, cited in an IDS but not discussed by the Examiner, showing an electronic receipt. As described above, the prior art cited by the Examiner was not close, showing a handheld computing device that wirelessly interacts with a supermarket computer for transactions, a remote ordering system, an Internet help session, with history tracked, and an electronic greeting card system. The prior art discussed below was not found by the Examiner, and shows the supposed invention. Williams (Verifone) discloses all the elements of the independent claims except an explicit category reference: an electronic wallet for selecting from a variety of payment cards for an online transaction. It provides a GUI showing individual items purchased, allows the use to modify information and enter data (e.g.,a category) in a memo field, and download to a financial management program, or alternately export to Quicken. -14-Schutzer (Citibank) similarly shows the independent claim elements. It provides a GUI using “intelligent agents” to capture online transaction information (bill payment, stock purchases, ctc.). It shows a category field in the GUI, and downloading the data to Quicken. It does not show the items in a transaction. Chancey (Intuit) describes improvements to Intuit’s Quicken product, and explicitly shows prompting the user to enter a category code, and would be obvious to combine with this inherent feature in Williams (memo field) or Schutzer (category field) because both download to Quicken. Schrader (Intuit) describes improvements to Intuit’s Quicken product, and explicitly discloses the list of previous payees (merchants) in ‘720 Patent dependent claims 8-10. Makipaai (Nokia) and Tannenbaum show electronic receipts with itemized products, and downloading to Quicken. They thus show the itemization missing from Schutzer, and set forth in ‘702 Patent claims 13 & 19-20, and are obvious to combine with Schutzer, which describes a download to Quicken. A. GROUND 1: CLAIMS 1-7 & 11-20 ARE OBVIOUS OVER WILLIAMS IN VIEW OF CHANCEY It is obvious to combine Williams (1:11-3) and Chancey (1:12-14) as both deal with tracking data in credit card transactions. Williams (13:48-50) discloses exporting transaction data from a GUI to Quicken and Chancey (2:64-3:2) is an improvement Quicken®. One of skill in the art would be motivated to have the -15-Williams data exported to the improved version of Quicken described in Chancey. Another reason both are related is that transactions over a network are described in both Williams (Internet, 19:22-26 ) and Chancey (modem, 2:4-10). Also, Williams shows a memo field for an online transaction, and Chancey shows explicitly prompting the user to enter a category code. One of skill in the art would understand that a “memo” ficld would commonly be used to record a transaction type, or category, and thus would be motivated to incorporate the category and prompt of Chancey into Williams as a matter of design choice to categorize the transaction before exporting it to Quicken, rather than afterward. In fact, exactly this was shown in Wells, which was filed prior to the priority date of the °720 Patent and assigned to the owner of Quicken. Wells discloses a website with a GUI that captures online transaction information, in which the user selects a category 416, stores the transaction data in a database 127, then downloads the data to a personal finance application, specifically Quicken. “Thus, for example, transaction information associated with an Internet purchase can be automatically uploaded from the vendor's web-site to database 127. If this occurs, then the transaction information will have been, at least substantially instantaneously, uploaded to database 127 without any additional effort or expense on the purchaser's part.” Wells 8:49-55 (emphasis added). -16-“the financial profile information stored within database 127 can be utilized. The fact that client computer, 106 delivers financial profile information each time it establishes connection with server 121 ensures that the financial profile of the database always corresponds with that of the user's personal finance application ....” Wells 15:22- 28 (emphasis added). “The preferred personal finance application for use in the present invention is Quicken® ....” Wells 8:1-3 (emphasis added). “With initial reference to FIG. 4(b), it will be appreciated that text entry window 402' is identical to text entry window 402 of FIG. (a) except that the Account and Category fields are slightly modified. In this case, window 402' displays a category list 417 which is part of the financial profile information provided to server 121. Thus, category list 417 preferably corresponds with the category list of user, 's 124 personal finance application, 118". Upon selection of Category field 416', a drop-down window displaying category list 417 appears and user, 124 can select one of categories listed.” Wells 13:57-67 (emphasis added)Enter now transactions into Quicken auickenaccounr “3 TPE [Checking vy} [Payment T¥] “406 08 -a1c ~ DATE PAYEE awount ~~ *"? cance] 414 a6 es catecory 418 Bo MEMO Bonus (neame) Div income (income) or Git Receive (income) a inteestinc income) | | -——~ az Ente Trans} invest inc (income) ter ne Gece) Salay (income) Aut expense) AuttFuel (expense) Auicinsurance (expense) [] FIG. 4b Thus, Wells demonstrates that it would have been obvious to combine. The obviousness to combine is further supported by the Shamos Declaration, {{] 63-68 and 106-113. Claim 1. The first element of claim 1, after the preamble, sets forth the “personal financial management application .”. One example in the ‘720 Patent is Quicken (“The personal financial management program could be Quicken ...” ‘720 Patent, Col. 3, Il. 7-8; see also claim 3 below). Williams shows such a management application in Fig. 20, and also mentions Quicken as an alternative. ekeDyor 8,132,720 1. A financial management system configured to transmit a set of transaction data, the finan management system comprising: Prior Art (emphasis added) “An electronic monetary system provides for transactions utilizing an electronic-monetary system that emulates a wallet or a purse that is customarily used for keeping money, credit cards and other forms of payment organized.” Williams, Abstract. “Pressing the accept button 1140 signals the user's acceptance of the transaction, and it records the transaction data into the wallet's register [financial management program] ....” Williams 31:14-17. “In an alternative embodiment of the Register and Report functions described above, a separate financial application program, such as Quicken, could he utilized =...” Williams 36:16-18. [al a personal financial management application configured to store personal financial management application transaction data including purchase amount data, purchase date data, payee data, and card identification data, and This element is provided either by the built in register function, or separately by the referenced Quicken program. Since Quicken is referenced as an example, Patent Owner has admitted it has the referenced data. “FIG. 20 is a register display in accordance with a preferred embodiment of the invention. The register display lists all transactions in chronological order and allows a user to navigate through and examiner [sic] transactions associated with a wallet.” Williams 33:5-9; see id. Fig. 20. “The register detail display allows a user to view or examine all of the specific details of a transaction.” Williams 33:53-55. “In an alternative embodiment for the Register and Report functions described above, a separate financial application program, such as Quicken, could be utilized as a helper application with the intemet program.” Williams 36:16-19. “Data export is also provided to the following financial programs: Quicken, Microsoft Money and Managing your money.” Williams 18:40-42. -19-Williams discloses a “total [purchase] amount” [Fig. 11], | [purchase] “date 2080” [33:46], “merchant [payee] 1120” [Fig. 11], “card type data entry field 1760 ... associated card number entry ficld 1780” [card identification data)” | Williams 32:19- The next element of claim | sets forth the financial assistant with a GUI with fields for the transaction data. This is shown by the Williams clectronic wallet, and the GUI of Fig. 11, below, for example. The GUI of Fig. 11 of Williams is generated during the online transaction, before user acceptance. The GUI of Fig. 12 is the paid receipt, generated when the accept button is pressed. The accept button also downloads the transaction data to the register. As can be seen, the data is the same as Fig. 11, and clearly is “at the conclusion of an online transaction” since the purchaser has already pressed the “accept” button. See also Shamos Declaration at ¥j 35-36 and 54-56. -20-pote 10 1180 [A] PayWindow-Authorization-Bob's Wallet [ jel Payment Method f Order“ Mechant Ship to Address: Wells. Fargo HAWAII'S BEST ESPRESSO COMPANY Expres 1 Hawaiian Blend Decaf $7.50 1 Hawaiian Blend $6.00 2 Kona Wailapa Regular $18.99 Wels Fargo Express Mal ONO Farms Reyulas 925.99 ‘Change Payinent Met 1100. | Agree To Pay The Total Amount Stown Below cording To The Card Issuer Agreement. Arrount: $ 69.25 | Hereby Digitally Sign This Transaction 140s (Camety— 115 FIG.-11 OX Payment Method ~ Ship to Address ‘Wells Fargo. HAWAII'S BEST ESPRESSO COMPANY Czpreu, 1 Hawaiian Blend Decaf $7.50 i Hawaiian Blend 36.00 a Kona Watlapa Regular $18.99 i Maui ONO Farms Regular $25.99 $8.00 Tax $2.77 1200 ‘The transaction has been completed pad “Thea you for shopping at HAWAIIS BEST EXPRESSO COMPANYThe category field is shown by the “memo” field in Fig. 21 of Williams, copied below. This is a register GUI, showing the transaction after it has been added to the register, and thus clearly after the conclusion of the online transaction. Williams later describes exporting to Quicken (Williams Fig. 24, also 18:40-42). Williams also shows a “merchant” tab in Figs. 11 and 12, without describing the details. It would be obvious to have a category on the merchant tab, such as a category corresponding to the merchant ID code as described in Chancey. See also Shamos Declaration §66. Register Detall-Bob’s Wallet 2100 2120 Date: 316/1996 Order Werchant Ship to Address Time: 10:30AM — ~ HAWAII'S BEST ESPRESSO COMPANY 1 Hawaiian Blend Decaf $7.50 Paid by: Family Visa 1 Hawaiian Blend $6.00 4219-0909-0989-1234 exo 1/98 | 1 Kona Wailapa Regular $18.99 1 Maui ONO Farms Regular $25.99 Recieved: Cy— 2160 Paid: (72170 2150. == —ervessiss 7 jo Merchant Sis 2130 FIG.-21[b] a financial a: comprising: a set of graphical user | interface generation executable code configured to generate a graphical user interface at the conclusion of the online transaction, the graphical user interface comprising: See Fig. 11 above “FIG. 11 is an authorization display screen in accordance with a preferred embodiment. ....The payment button on a web page launches this screen when a wallet is already open.” Williams 31:1-9. “Processing commences at function block 600 where an internet [online] browser implemented as a Java applet detects the selection of a payment button and a test is performed at decision block 610 to determine if a wallet is open.” Williams 19:22-26 [cl] a purchase amount field, {c2] a purchase date field, [c3] a payee field, Fig. 11 shows the purchase amount in the box on the right. Fig. 21 shows the same data loaded into the register with the purchase date on the upper left. Thus, the purchase date must have been recorded at the time of the transaction . 11 shows the payee as the “merchant” at the top of the box on the right. [cd] a category field | configured to accept user input, and an accept button, merchant category cod: Fig. 21 shows a “memo” field at the lower left, which inherently can be used for a category. | Fig. 11 shows an “accept” button at the bottom left. “If no recognized category exists, the method may prompt a.user for selection of a category for association with the ” Chancey 2:32-34. The next element of claim 1 refers to the population of the fields of the GUI with the transaction data. This is shown by Williams in the display of Fig. 11, forexample, and it is inherent that executable code would be required to produce such a screen with the shown populated transaction data, See Shamos Declaration 55. [d]a set of graphical _ | The displaying of the transaction details necessarily user interface inherently includes executable code to populate the fields population executable | for the display. code that populates the | “The authorizaticn screen displays the transaction details purchase amount field, | and facilitates a user's examination of all the details of a the purchase date particular transaction. It also allows a user to accept or field, the payee field, | cancel a transaction, or change the payment method for a and the card particular transaction.” Williams 31:2-7. identification field based on the received transaction data, and The last element of claim 1 is directed to transmitting the transaction data to the personal financial management program (¢.g., Quicken) when the user presses an “accept” button. Williams shows such an accept button in Fig. 12, and recording (transmitting) to the register. Au altemative to the wallet register is exporting Ww Quicken. It is inherent that executable code is used to do this described function in Williams. See Shamos Declaration 456. [e] a set of personal | “Pressing the accept button 1140 signals the user's financial management | acceptance of the transaction, and it records the application transaction data into the wallet's register and displays a transmission PAID receipt as shown at 1200 at FIG. 12.” Williams executable code that 31:14-18 transmits the personal financial management | “Data export is also provided to the following financial application transaction | programs: Quicken, Microsoft Money and Managing your data from the field: | money.” Williams 18:40-42. -24-the graphical user interface to the | personal financial | management application when the accept button is activated. Claims 2-7. The elements of these claims are shown in the claim chart below. Claim 2 further sets forth that the GUI shows a payment card ID (e, credit card number). This is clearly shown in the Williams wallet. Claim 3 sets forth that the financial management program is Quicken, also shown in Williams. Claims 4-6 set forth various aspects of using a web browser: the “context” is a browser (claim 4), the financial assistant is “part of” a browser (claim 5), and the browser renders the GUI. All these uses of a browser are shown by Williams, and the ‘720 Patent does not show how a browser is used in other than its ordinary manner. Claim 7 says the GUI prompts the user to select “one of a number of predetermined categories.” The display of the Williams memo field is itself a in view of Chancey ta select one of prompt, and it would be obvious to modify i the predetermined categories. Chancey shows such a prompting and selection, and it would be obvious to do so before loading into Quicken. As described in Chancey, Quicken is designed to receive merchant category codes and assign themto a category, so reception of the category itself is clearly equivalent. See Shamos Declaration at §66. Dyor 8,132,720 | Prior Art (emphasis added) 2. The financial management system of claim 1, wherein the graphical user interface additionally comprises a card identification field for identifying a credit card associated with the transaction data 3. The financial management system of claim 1, wherein the personal financial management application is Quicken. 4. The financial management system of claim 1, wherein the financial assistant operates within the context of a web browser. 5. The financial management system of claim 1, wherein the financial assistant is part of a web browser. See Fig. 11 “Payment Method” and Fig. 10, cards “BofA. Visa 1040” and “Well’s Fargo Visa 1030.” “The supported payment instruments include: credit cards, electronic checks, electronic money, micropayment (electronic coin), debit card and smart cards.” Williams 17:54-57. “card type data entry field 1760 ... associated card | number entry field 1780” Williams 32:19-23. “credit card account 24” Chancey Fig. 1. “In an altemative embodiment for the Register and Report functions described above, a separate financial application program, such as Quicken, could be utilized as a helper application with the internet program.” Williams 36:16-19. “On receiving the MIME message from the merchant system, the browser launches the Pay Window application which is defined as a helper application in the browser.” Williams 11:5-7. “On receiving the MIME message from the merchant system, the browser launches the Pay Window application which is defined as a helper application in the browser.” Williams 11:5-7.6. The financial “On receiving the MIME message from the merchant management system of | system, the browser launches the PayWindow application claim 1, wherein a which is defined as a helper application in the browser.” web browser residing | Williams 11:5-7. on the client terminal renders the graphical user interface. 7. The financial “memo” Williams Fig. 12. management system of claim 1, wherein a “The memo field 2380 allows a user to enter a full or web browser residing | substring of the memo field asa filter parameter.” on the client terminal | Williams, Col. 34, II. 44-46. renders a graphical user interface which f no recognized category exists, the method may prompt prompts the user to a.user for selection of a category for association with the select one of anumber | merchant category code.” Chancey 2:32-34. of predetermined categories associated with the personal | financial management application Claim 11 says the transaction data comes from a merchant server which has executable code to process the transaction. Williams describes a merchant interface for providing order information. It is inherent that the merchant web server has executable code to process the transaction. See Shamos Declaration at 55. Dyor 8,132,720 __| Prior Art (emphasis added) _ 11. The financial “The mechant [sic] web site 180 contains the shopping management system of | Common Gateway Interface (CGI) 190 which is provided claim 1, wherein the | by the merchant or other web server communication transaction data is__| system. The CGI is an interface which allows applications | 2O7e| of commercial web received from a to access, process and respond to incoming messages. commercial web Industry slang is to refer to CGI scripts as a way of saying server provided by a _| that a programmer is writing web server applications in merchant, said scripting languages. A CGI script is a type of software commercial web application program. ....The payment instruction 192 is a server having a set of | file representing the Multipurpose Internet Mail transaction processing | Extension (MIME) message that is created by the executable source merchant system when the consumer clects to pay. This code configured to | MIME message contains the order information and the process an online payment instructions which are specific to the merchant. transaction when a set | The order information contains the Goods and Services Order (GSO), shipping address, merchant Uniform Resource Locator (URL), merchant certificate, merchant name and address, and transaction ID associated with the order. The payment instructions contains the payment instruments that the merchant accepts and the payment protocol preferences.” Williams 10:45-11:4. server transaction data is received. Claim 12. Claim 12 is an independent claim similar to claim 1, except it recites a “reminder” and eliminates most of the details of the GUI fields, except for the category field. As noted above under claim construction, the claims when presented were characterized as “substantially the same” as the parent patent claims. Thus, the “reminder” is simply the presentation of the GUI for a transaction, which “reminds” the user to enter a category and download it to the financial management program (e.g, Quicken). Accordingly, claim 12 is shown by Williams and Chancey for the same reason as discussed above and show in the chart below. Claim 13 sets forth that the items in the transaction are captured (as a receipt would). This is shown by the itemization in Fig. 11 of Williams. Claims 14-17recite the use of Quicken and uses of a browser, similar to claims 3-6, and are invalid for the same reasons discussed above. Claim 18 is similar to claim 7, prompting selection of a category, and is cbvious for the same reasons set forth above with respect to claim 7. Claim 19 is an independent claim similar to claim 12, using the “reminder” language, and sctting forth in the last clement that the items in the transaction are shown, similar to claim 13. Accordingly, claim 19 is invalid for the same reasons as claim 13. Dependent claim 20 simply adds back in the other fields of the GUI, as set forth in claim 1, that were left out of claims 12 and 19. Thus, claim 20 is invalid for the same reasons as claim 1 as set forth above. Dyor 8,132,720 12. A financial “Processing commences at function block 600 where an management system _| internet [online] browser implemented as a Java applet for creating a reminder | detects the selection of a payment button and a test is for a financial performed at decision block 610 to determine if a wallet transaction is open. ....Ifa user selects payment authorization at consummated online, | function block 634, Williams 19: 22-30. the financial management system | “Paywindow helper application 188 is utilized by the comprising: consumer to authorize the payment to the merchant, to administer their wallets, to review their previously completed payment transactions [financial transacton consummated] and to perform housekeeping activities on the wallets. This application is defined as a “helper” application on the consumer's desktop. The browser launches this application when the merchant system sends a MIME message requesting payment.” Williams 11:53- l 63.| [a] a personal financial | This element is provided either by the built in register management | function, or separately by the referenved Quicken application configured | program. to store personal “PIG. 20 is a register display in accordance with a financial management | preferred embodiment of the invention. The register application trans- display lists all transactions in chronological order and | action data including | allows a user to navigate through and examiner [sic] purchase amount transactions associated with a wallet.” Williams 33.5-9, data, purchase date _| see id. Fig, 20. data, payee data, and card identification “The register detail display allows a user to view or data, anda financial | examine all of the specific details of a transaction.” assistant compri Williams 33:53-55. “In an alternative embodiment for the Register and Report functions described above, a separate financial application program, such as Quicken, could be utilized as a helper application with the internet program.” Williams 36:16-19. “Data export is also provided to the following financial | programs: Quicken, Microsoft Money and Managing your money.” Williams 18:40-42. [b] a set of graphical _ | See Fig. 11 above. user interface “FIG. 11 isan authorization display screen in accordance generation executable | with a preferred embodiment. ....The payment button on code configured to _/ a web page launches this screen when a wallet is already | generate a graphical | open.” Williams 31:1-9. user interface at the conclusion of the online transaction, the graphical user interface comprising: [c] a category field Fig. 21 shows a “memo” field at the lower left, which configured to accept _| inherently can be used for a category. user input, and an Fig. 11 shows an “accept” button at the bottom left. accept button, “If no recognized category exists, the method may prompt | -30-| auser for selection of a category for association with the merchant category code.” Chanecy 2:32-34. {d] a set of graphical user interface population executable code that populates the category field based on the received | transaction data, and [el a set of personal financial management application transmission executable code that transmits the personal financial management application transaction data from the category field of the graphical user interface to the personal financial management application when the accept button is activated. 13. The financial management system of “If the process fails to locate a previous transaction with the same payee, then the process determines from the ‘atement a merchant category code associated with the present transaction (step 44). This category code, such as the Standard Industry Code, is a number that corresponds | to a description of the payce's primary business or | description of the type of transaction, such as service charge, credit, and the like, and is present in financial statements such as credit card statements. For example, a restaurant's mercant category code may he 5812, and a credit may have the category code 2100. The process | constructs a look-up table in the memory of the computer | for associating, or translating, merchant category codes with categories recognized by the process. In the example above, the process might associate the 5812 code with a recognized category such as "Dining." Assuming an association exists, the process assigns the present transaction to the recognized category (steps 46, 48).” Chaney 4:64-5:23, Pressing the accept button 1140 signals the user's acceptance of the transaction, and it records the ‘ansaction data into the wallet's register and displays a PAID receipt as shown at 1200 at FIG. 12.” Williams 31:14-18. ‘ig. 11 above shows the items in the transaction in the upper right: “Hawaiian Blend Decaf,” Hawaiian Blend,” | eeclaim 12, wherein the | Kona Wailapa Regular,” and “Maui ONO Farms personal financial Regular.” Williams, Fig. 11. management application transaction data comprises information about a plurality of particular items that comprise the financial transaction consummated online. 14. The financial The limitations of claim 14 are identical to claim 3, and management system of | are identically shown in Williams. claim 12, wherein the personal financial management application is Quicken. 15. The financial The limitations of claim 15 are identical to claim 4, and management system of | are identically shown in Williams. claim 12, wherein the financial assistant operates within the context of a web browser. 16. The financial | The limitations of claim 16 are identical to claim 5, and management system of | are identically shown in Williams. claim 12, wherein the financial assistant is part of a web browser. 17. The financial “The limitations of claim 17 are identical to claim 6, and management system of | are identically shown in Williams. claim 12, wherein a web browser residing on a client terminal renders the | graphical user19. A financial interface. 18. The financial ¢ limitations of claim 18 are identical to claim 7, and management system of | are identically shown in Williams. claim 12, wherein a web browser residing on a client terminal renders a graphical user interface which prompts the user to select one of a number of predetermined categories associated with the personal financial management application. management system | and is identically shown by Williams. for creating a reminder for a financial transaction consummated online, the financial management system comprising: _ _ [a] a personal financial | This element is icentical to element [a] of claim 1 and is management identically shown by Williams. application configured to store personal financial management application transaction data including purchase amount data, purchase date data, payee data, and card identification data, and a financial assistant | comprising: | -32-[b] a set of graphical | This element is identical to element [b] of claim 1 and is | user interface identically showr. by Williams. | generation executable code configured to generate a graphical user interface at the conclusion of the vuline Wausaction, the graphical user interface comprising: | __ : [c] a category field This element is identical to element [c] of. configured to accept _| identically showr: by Williams and Chancey. user input, and an accept button, [d] a set of graphical _ | This element is identical to element [d] of claim 12 and is user interface identically showr. by Williams and Chancey. population executable code that populates the category field based on the received transaction data, and _ [e] a set ofpersonal | “Pressing the accept button 1140 signals the user's financial management | acceptance of the transaction, and it records the applic: data into the wallet's register and displays a ion } transaction transmission PAID receipt as shown at 1200 at FIG. 12.” Williams executable code that 31:14-18. transmits the personal financial management | Fig. 11 above shows the items in the transaction in the application transaction | upper right: “Hawaiian Blend Decaf,” Hawaiian Blend,” data from the category | Kona Wailapa Regular,” and “Maui ONO Farms field of the graphical | Regular.” Willians, Fig. 11 user interface to the personal financial management | application when the | accept button is | activated, the personal | financial management application transaction data comprising _ -34-information about a plurality of particular items that comprise the financial transaction consummated online. 20. The financial management system of claim 19, wherein the graphical user interface additionally comprises: a purchase amount field, See claim 19 preamble. Fig. 11 shows the purchase amount in the box on the right. a purchase date field, Fig. 21 shows the same data loaded into the register with the purchase date on the upper left. Thus, the purchase date must have been recorded at the time of the transaction. a payee field, Fig. 11 shows the payee as the “merchant” at the top of the box on the right. Williams Fig. 11. a category field configured to accept user input, a card identification field, and an accept button Fig. 21 shows a “memo” field at the lower left, which | inherently can be used for a category. Williams Fig. 21. “If no recognized category exists, the method may prompt a.user for selection of a category for association with the merchant category code.” Chancey 2:32-34. See Fig. I1 “Payment Method” and Fig. 10, cards 1040 and 1030. Williams Fig. 11. “The supported payment instruments include: credit cards, electronic checks, electronic money, micropayment (electronic coin), debit card and smart cards.” Williams | 17:54-57 _ | Fig. 11 shows an “accept” button at the bottom left. | -35-B. GROUND 2: CLAIMS 8-10 ARE OBVIOUS IN VIEW OF WILLIAMS, CHANCEY AND SCHRADER Dependent claims 8 and 10 set forth a list of merchants and categories based on previous selections (claim 8) and a suggested category for the merchant if there has been a prior association of the merchant with a category (claim 10). While Williams shows a list of merchant names, Chancey shows assigning the transaction/merchant to a previously associated category. Schrader explicitly shows a merchant list. Since Willams downloads to Quicken, and both Chancey and Schrader are Intuit patents describing improvements to Quicken, it would be obvious to combine the three. In addition, both Williams and Schrader recite a list of merchants, and Schrader recites categories for merchants, so it would be obvious to provide a list of both merchants and categories. See also Shamos Declaration ut $]72-75. al im 9. Claim 9 recites prompting the user to select a category. As described above with respect to claim 1, tke provision of the “memo” field prompts a user to enter something, most likely an expense category or other characterization of the transaction. To the extent this isn’t explicit, Chancey shows prompting to enter a category, and it would be obvious to combine Chancey with Williams as discussed above.8. The management system of claim 7, wherein the web browser creates an associated list of merchants and wateguries based. previous selections. anciall 9. The financial management system of claim 8, wherein the web browser provides a suggested name | based on the name of the merchant. [Dyor 8,132,720 Prior Art (emphasis added) “The merchant combo 2240 display lists all of the merchant names in the wallet. The item 2250 control causes a list of all the merchant names to be displayed for selection of the particular merchant name required.” Williams 34:16-20. “The user enters a payee in payce field 223, cither by direct text entry or by selecting a payee [merchant] from a list of known payees using the dropdown button 224.” Schrader 15:61-63. “In another aspect, the invention comprises a computerized method and system for assigning financial transactions such as credit card transactions to categories. This assignment occurs in the process of entering the transactions into a financial account stored in a computer. One form of the method includes determining from the electronic statement if a payee for a transaction is of record in the computer and, if so, assigning the transaction to a category already associated with the payee. “One form of the method includes determining from the electronic statement if a payee for a transaction is of record in the computer and, if so, assigning the | transaction to a category already associated with the payee, Chancey 2:23-27, 10. The financial management system of claim 9, wherein the web browser creates an associated list of merchants and categories based on previous selections, and provides a suggested category based upon the The user enters a payee in payee field 223, either by direct text entry cr by selecting a payee [merchant] from a list of known payees using the dropdown button 224.” Schrader 15:61-63 “One form of the method includes determining from the electronic statement if a payee for a transaction is of record in the computer and, if so, assigning the transaction to a category already associated with the payee. Chancey 2:23-27. ” Chancey 2:19-27.associated list if the merchant has previously been associated with a category. C. GROUND 3: CLAIMS 1-7, 11-12 AND 14-18 ARE OBVIOUS OVER SCHUTZER IN VIEW OF CHANCEY Schutzer is a Citibank patent describing “the use of computerized intelligent agents to facilitate the integration of networked performance of financial transactions with computerized methods 0° financial accounting.” Schutzer, Abstract. Schutzer is directed to online bill payment and stock purchases (4:27- 29), which are online transactions. Schutzer, like Williams, expressly discloses transmitting data to Quicken (15:49-52). Thus, it is obvious to combine Schutzer with Chancey for the same reasons as discussed above for combining with Williams. Schutzer shows a GUI with transaction information, and shows a category field, the display of which is a prompt to the user, and it would be obvious to add the explicit category prompt of Chancey. Also, both Schutzer and Chancey describe transactions over a network and additional information to a transaction GUI (e.g., Schutzer 14:14-16 and 15:49-52; Chancey 2:4-10). See also Shamos Declaration at 4982-86. Claim 1. The first element of claim 1, after the preamble, sets forth the “personal financial management application .” One example in the ‘720 Patent is -38-Quicken (“The personal financial management program could be Quicken ...” “720 Patent, Col. 3, II. 7-8; see also claim 3 below). Schutzer describes a financial planner, such as Quicken. The next element of claim | sets forth the financial assistant with a GUI with fields for the transaction data. This is shown by the Schutzer GUI of Figs. 8 and 24 as described in the claim chart below, for example, including a category field. Fig. 8 shows payment reminder window automatically populated with transaction data, while Fig. 24 shows a payment window with blank fields for the user to complete. Schutzer describes exporting the data to Quicken, which necessarily happens after conclusion of the online transaction. See Shamos Declaration at 78. Dyor 8,132,720 _ Priar Art (emphasis added) _ | 1. A financial ‘he present invention relates to the use of computerized | management system | intelligent agents to facilitate the integration of networked | configured to transmit | performance of financial transactions with computerized a set of transaction methods of financial accounting.” Schutzer, Abstract. data, the financial management system comprising: {a] a personal financial | “In FIG. 9, if the user selects the button for Financial management Planning 135, the system automatically executes a application configured | financial planner, such as Quicken. The user can then to store personal import information from the system into the planner.” financial management | Schutzer 15:49-52. application transaction data including “The information provided for processing includes Date purchase amount data, | 191, Amount 192, Status 193, Category 194, Check purchase date data, | Number 195, Payee/Description 196, Address 197, d -39-payee data, and card | identification data, and [b] a set of graphical user interface generation executable code configured to generate a graphical user interface at the conclusion of the online transaction, the graphical user interface comprising: amount field, [c2} a purchase date field, _ [c3] a payee field, Memo 198.” Schutzer 14:14-16. “As shown in FIG. 8, a window 120 appears containing information about From Account 121, Payee Name 122, Amount 123, and Date due 124. The user can select OK 125 to automatically make the payment or Cancel 126 to not make the payment.” Schutzer 13:42-46." “In FIG. 24, if the user selects the Payment button 313, a pop-up window 340 appears, as shown in FIG. 27. This window 340 allows the- user to input information about From Account 341, Payee Name 34?, Amount 343, Date 344, and Category 345 in order to make a one-time payment. The user may OK 367 the recurring payment or Cancel 368.” Schutzer 16:6-13. ‘Amount 343” see above. | “Date 344” see above. “Payee Name 34: [cd] a category field configured to accept user input, and an accept button, ‘Category 345” si ‘OK 367” [accept button] see above. “The merchant category code is associated with a category recognized hy the compnter, and the trans: is assigned to the recognized category. If no recognized category exists, the process prompts the user for a category to which the transaction can be assigned.” Chancey Abstract. “If no recognized category exists, the method may prompt a.user for selection of a category for association with the | merchant category code.” ‘The next element of claim | refers to the population of the fields of the GUI with the transaction data. This is shown by Schutzer with the reference to default information being provided. The provision of default information necessarily -40-requires the population of the GUI so the use can see the default information. It is inherent that executable code would be required do this. See Shamos Declaration 179. [Ta] a set of graphical | The displaying of the transaction details necessarily | | user interface inherently includes executable code to populate the fields population executable | for the display. | | code that populates the | “A warning for a pending payment appears as a result of a purchase amount field, | system check for the current date and the due date for the purchase date particular payments. ....Default information, such as the field, the payee field, | payee address, payee electronic transfer account number and the card [card identification], date, and amount to be paid are identification field automatically prompted by the system.” Schutzer 8:21-29. based on the received transaction data, and The last element of claim 1 is directed to transmitting the transaction data to the personal financial management program (¢.g., Quicken) when the user presses an “accept” button. Schutzer shows the “downloading” and “transferring” to the “financial software application.” Fig. 8 shows an “OK” button, which one of skill in the art would recognize as initiating the download. The downloaded data can be imported to a “financial planner, such as Quicken.” It would be an obvious matter of design choice to instead have these two steps combined, so that the OK button downloads and imports the information to the financial planner. It is inherent that executable code is used to perform this described function in Williams. (See Shamos Declaration 478. aie[elaset of personal __| “the server automatically performing the financial financial management | transaction, and automatically downloading information application related to the performance of financial transactions from transmission the server to the local client application. In addition, the executable code that _| invention includes the steps of transferring downloaded transmits the personal | information related to performed financial transactions financial management | from a local client application to a financial software application transaction | application ....” Schutzer 4: 46-53. data from the fields of the graphical user interface to the personal financial management application when the accept button is activated “In FIG. 9, if the user selects the button for Financial Planning 135, the system automatically executes a financial planner, such as Quicken. The user can then import information from the system into the planner.” Schutzer 15:49-52. “As shown in FIG. 8, a window 120 appears containing information about From Account 121, Payee Name 122, | Amount 123, and Date due 124. The user can select OK [accept button] 125 to automatically make the payment or Cancel 126 to not make the payment.” Schutzer 13:42-46 Dependent claims 2-11. The elements of these claims are shown in the claim chart Claim: . below. Claim 2 further sets forth that the GUI shows a payment card ID (e.g., credit card number). Schutzer refers to an account, without specifying a credit card account. However, Chancey specifies that the accounts can include a credit card account. Since Schutzer refers to Quicken as a financial planner to which the data can be downloaded, and Chancey describes Quicken, it would be obvious to include a credit card account in the types of accounts supported by Schutzer. See Shamos Declaration at ]82-86.Claim 3 sets forth that the financial management program is Quicken, also shown in Schutzer. Claims 4-6 sct forth various aspects of using a web browser: the “context” is a browser (claim 4), the financial assistant is “part of” a browser (claim 5), and the browser “renders” the GUI. All these uses are standard uses ofa browser, and a browser is described as used by Schutzer. The ‘720 Patent does not show how a browser is used in other than its ordinary manner. See Shamos Declaration at {18-20 and 40. Claim 7 says the GUI prompts the user to select “one of a number of predetermined categories.” Schutzer describes providing a category field to be completed by a user, and separately shows a list of categories, which are the “predetermined categories.” The display of the categories is itself'a prompt. It is inherent that the list would be associated with the category field, and alternately it would be an obvious design choice to do so. Also, it would be obvious to combine it in view of Chancey to select one of the predetermined categories. Chancey shows such a prompting and selection, and it would be obvious to do so before loading into Quicken. As described in Chancey, Quicken is designed to receive merchant category codes and assign them to a category, so reception of the category itself is clearly equivalent. See Shamos Declaration at $957-62 and 82-86.Claim 11. Claim 11 says the transaction data comes from a merchant server which has code to process the transaction. Schutzer describes Financial institution servers providing the data, which are “merchants” for stock transactions, which arc also described in Schutzer. It is inherent that the financial institution (merchant) web server has executable code to process the transaction. See Shamos Declaration at {76-81 Dyor 8,132,720 Prior Art (emphasis added) | 2. The financial “Account 341” See above, Schutzer 16: management system of | claim 1, wherein “...the entry of financial transactions into the appropriate the graphical user financial account--whether it is a credit card account, a interface additionally | checking account, or another account.” Chancey 1:58-60. comprises a card | identification field for identifying a credit card associated with the transaction data 3. The financial “In FIG. 9, if the user selects the button for Financial management system of | Planning 135, the system automatically executes a claim 1, wherein the _ | financial planner, such as Quicken. The user can then personal financial import informaticn from the system into the planner.” management Schutzer 15:49 application is Quicken. 4. The financial user (not shown) utilizes an internet browser 20 to management system of | perform 21 an on-line transaction at the primary bank claim 1, wherein the | server 4. Additionally the user utilizes the internet financial assistant browser 20 to connect 21 to the primary bank server 4 operates within the and view account information.” Schutzer 10:63-67. context of a web | browser. -44-5. The financial management system of claim 1, wherein the financial assistant is part of a web browser. “A user (not shown) utilizes an internet browser 20 to perform 21 an on-line transaction at the primary bank server 4, Additionally the user utilizes the internet browser 20 to connect 21 to the primary bank server 4 and view account information.” Schutzer 10:63-67. 6. The financial management system of claim 1, wherein a web browser residing on the client terminal renders the graphical user interface. 7. The financial management system of claim 1, wherein a web browser residing, on the client terminal renders a graphical user interface which prompts the user to select one of a number of predetermined categories associated with the personal financial management application “A user (not shown) utilizes an internet browser 20 to perform 21 an on-line transaction at the primary bank server 4, Additionally the user utilizes the internet browser 20 to connect 21 to the primary bank server 4 and view account information.” Schutzer 10:63-67. user (not shown) utilizes an internet browser 20 to perform 21 an on-line transaction at the primary bank server 4. Additionally the user utilizes the internet browser 20 to connect 21 ta the primary hank server 4 and view account information.” Schutzer 10:63-67. “In FIG. 24, if the user selects the Payment button 313, a pop-up window 340 appears, as shown in FIG. 27. This window 340 allows the user to input information about From Account 341, Payee Name 342, Amount 343. Date 344, and Category 345 in order to make a one-time payment. The user may OK 367 the recurring payment or Cancel 368.” Schutzer 16:6-13. “In FIG. 17, if the user selects Payee List 238 ....The window 270 includes a list of Payees 271, a list of Categories 272, a section for the user to input the name of a New Payee 273, and buttons to Add 274 the new payee, Delete 275 a selected payee, or Change 276 a category of a payee.” Schutzer 15:8-16. “If no recognized category exists, the method may prompt auser for selection of a category for association with the merchant category code.” Chancey 2:32-34.management system of | number of financial institutions though data file claim 1, wherein the _ | downloading/uploading across the internet so that transaction data is transaction data is loaded into the system ....” Schutzer received froma 7:2-5. | commercial web server provided by a _| Financial institutions are “merchants” for stocks. | merchant, said “Via this internct connection, the user performs onc of a commercial web number of banking or financial institution transactions. server having a set of | For these transactions, the user utilizes a password or transaction processing | scrics of passwords to access the account. The 11. The financial “The system interfaces with the on-line servers of a large | | executable source transactions performed can include withdrawals, | code configured to transfers, deposits, investments in stocks, bonds, mutual | process an online funds, futures or options, bill payments, and transaction when a set | establishment of certificates of deposit or money market | of commercial web _| accounts.” Schutzer 9:55-63. | server transaction data | is received. Claims 12, 14-20. Claim 12 is an independent claim similar to claim 1, except it recites a “reminder” and eliminates most of the details of the GUI fields, except for the category field. As noted above under claim construction, the claims when presented were characterized as “substantially the same” as the parent patent claims. Thus, the “reminder” is simply the presentation of the GUI for a tran: ion, which “reminds” the user to enter a category and download it to the financial management program (¢.g., Quicken). Accordingly, claim 12 is shown by Schutzer and Chancey for the same reason as discussed above. In addition, Schutzer separately shows the use of reminders, such as in Fig. 7 - 46 -Claims 14-17 recite the use of Quicken and uses of a browser, similar to claims 3-6, and are invalid for the same reasons discussed above. Claim 18 is similar to claim 7, prompting selection of a category, and is obvious for the same reasons set forth above with respect to claim 7. Claim 19 is an independent claim similar to claim 12, using the “reminder” language, and setting forth in the last element the items in the transaction are shown, similar to claim 13. Accordingly, claim 19 is invalid for the same reasons as claim 13, Dependent claim 20 simply adds back in the other fields of the GUI, as set forth in claim 1, that were left out of claims 12 and 19. Thus, claim 20 is invalid for the same reasons as claim | as set forth above. Dyor 8,132,720 Prior Art (emphasis added) “The local intelligent agent searches for paying habit rules in the local rule file, searches the updated transaction history and searches the reminder file. Following these searches, the intelligent agent prompts the user with several possible alarms and reminders. An action button is shown on the screen for each warning and reminder. The warnings and reminders include: 1) Cleared checks; 2) Warning for pending payment; 3) Low balance alarm; 4) Uncleared due date payment; and 5) General Reminder.” Schutzer 8:2-1], 12. A financial management system for creating a reminder for a financial transaction consummated online, the financial management system comprising: to element [a] of claim 1, and is identically shown by Schutzer. [al a personal financial | This element is icentic management application configured to store personal financial management application trans- |action data including purchase amount data, purchase date data, payee data, and card identification data, and [b] a financial assistant comprising. a set of graphical user interface generation executable code configured to generate a graphical user interface at the conclusion of the online transaction, the graphical user interface comprising: [c] a category field configured to accept user input, and an accept button, This element is identical to element [b] of claim 1, and is identically shown by Schutzer. The category selection is shown: “In FIG. 12, the user can process an item on the list 181 by double clicking on a selected item. Double clicking produces another pop-up window 190, as shown in FIG. 13A. The information provided for processing includes Date 191, Amount 192, Status 193, Category 194, Check Number 195, Payee/Description 196, Address 197, and Memo 198. The user can select OK. 199 if the information is correct, Delete 200 to delete the detail, or Cancel 201.” Schutzer 14:11-19. “This option allows the user to specify new expense categories for the user's accounts. The window 260 includes Expense Categories 261 with a scroll bar 261a. The user may lista New Category 262 and use buttons to ‘Add 263 the New Category 262 inputted, or Delete 264 selected Expense Categories 261. The user selects OK 1. 265 when finished or Cancel 266 to can .... The window 270 includes a list of Payees 271, a list of | | Categories 272, a section for the user to input the name of - 48 -{d] @ set of graphical user interface population executable code that populates the category field based on the received transaction data, and [e] a set of personal financial management application transmission executable code that transmits the personal financial management application transaction data from the category field of the graphical user interface to the personal financial management application when the accept button is activated. 14. The financial management system of claim 12, wherein the personal financial management application is Quicken. The limitations of claim 14 are identical to claim 3. a New Payee 273, and buttons to Add 274 the new payee, | Delete 275 a selected payee, or Change 276 a category of a payee.” Schutzer 15:1-16. “If no recognized category exists, the method may prompt auser for selection of a category for association with the merchant category code.” Chancey 2:32-34. | “TP the process [ails to locate a previous transaction with the same payee, then the process determines from the statement a merchant category code associated with the present transaction (step 44). ....Assuming an association exists, the process assigns the present transaction to the recognized category (steps 46, 48).” Chancey 4:64- 5:13. The “accept button” is the “OK” button shown as 347 in| Fig, 27 of Schutzer. “the server automatically performing the financial transaction, and cutomatically downloading information related to the performance of financial transactions from the server to the local client application. In addition, the invention includes the steps of transferring downloaded information related to performed financial transai | from a local client application to a financial | application.” Schntzer 4:46-53 | | and are identically shown in Schutzer.15. The financial The limitations of claim 15 are identical to claim 4, and management system of | are identically shown in Schutzer. claim 12, wherein the financial assistant operates within the context of a web browser. 16. The financial | The limitations of claim 16 are identical to claim 5, and management system of | are identically shown in Schutzer. claim 12, wherein the financial assistant is part of a web browser. 17. The financial “The limitations of claim 17 are identical to claim 6, and management system of | are identically shown in Schutzer. claim 12, wherein a web browser residing on a client terminal renders the graphical user interface. 18. The financial The limitations of claim 18 are identical ta claim 7, and management system of | are identically shown in Schutzer and Chancey. claim 12, wherein a web browser residing on a client terminal renders a graphical user interface which prompts the user to select one of a number of predetermined categories associated with the personal financial management application. -50-D. GROUND 4: CLAIMS 8-10 ARE OBVIOUS OVER SCHUTZER IN VIEW OF CHANCEY AND SCHRADER Dependent claims 8 and 10 set forth a list of merchants and categories based on previous selections (claim 8) and a suggested category for the merchant if there has been a prior association of the merchant with a category (claim 10). Schutzer shows a list of payees and a list of categories, and describes allowing the user to change the category associated with a payee. ‘Thus, the category must have been previously associated with a previous selection. Chancey more clearly shows assigning the transaction/merchant to a previously associated category. As described above, since Schutzer references Quicken, and Chancey is an Intuit patent describing improvements to Quicken, it would be obvious to combine. See also Shamos Declaration at 487. Claim 9. Claim 9 recites that the web browser “provides a suggested name [category, see Ground | discussion] based on the name of the merchant.” It would be obvious to combine Schutzer with Chancey, for the reasons described above, to provide suggested categories based on a merchant category code. Also, it would be obvious to do so before loading into Quicken. Chancey describes “assigning the transaction to a category already associated with the payee,” which is suggesting a category. Since the user can change the category, as described above, this is clearly a suggestion. -51-yor 8,132,720 Prior Art (emphasis added) 8. The financial “The user enters a payee in payee field 223, either by management system of | direct text entry or by selecting a payee [merchant] from a claim 7, wherein the _ | list of known payzes using the dropdown button 224.” web browser creates Schrader 15:61-63. an associated list of merchants and “A user (not shown) utilizes an internet browser 20 to categories based on | perform 21 an on-line Wansaction at the prinruy bank previous selections. _| server 4. Additionally the user utilizes the internet browser 20 to connect 21 to the primary bank server 4 and view account information.” Schutzer 10:63-67. “In FIG. 17, if the user selects Payee List 238 ....The window 270 includes a list of Payees 271, a list of Categories 272, a section for the user to input the name of a New Payee 273, and buttons to Add 274 the new payee, Delete 275 a selected payee, or Change 276 a category of a payee.” Schutzer 15:8-16 “In another aspect, the invention comprises a computerized method and system for assigning financial transactions such as credit card transactions to categories. This assignment occurs in the process of entering the transactions into a financial acconnt stored in a computer. One form of the method includes determining from the electronic statement if a payee for a transaction is of record in the computer and, if so, assigning the transaction to a category already associated with the | payee.” Chancey 2:19-27. 9. The financial “In FIG. 17, if the user selects Payee List 238....The management system of | window 270 includes a list of Payees 271, a list of claim 8, wherein the | Categories 272, a section for the user to input the name of web browser provides | a New Payee 273, and buttons to Add 274 the new payee, asuggested name _| Delete 275 a selected payee, or Change 276 a category of based on the name of | a payee.” Schutzer 15:8-16. the merchant. “One form of the method includes determining from the electronic statement if a payee for a transaction is ofrecord in the computer and, if so, assigning the transaction to a category already associated with the oe payee. Chancey 2:23-27. _ 10. The financial ‘The user enters a payee in payee field 223, either by management system of | direct text entry or by selecting a payee [merchant] from a claim 9, wherein the __| list of known payees using the dropdown button 224.” web browser creates Schrader 15:61-63. au assuciated list of merchants and “One form of the method includes determining from the categories based on electronic statement if a payee for a transaction is of previous selections, __| record in the computer and, if so, assigning the and provides a transaction to a category already associated with the suggested category payee. Chancey 2:23-27. based upon the associated list if the merchant has | previously been associated with a category. E. GROUND 5: CLAIM 13 AND 19-20 ARE OBVIOUS OVER SCHUTZER IN VIEW OF CHANCEY, MAKIPAA AND TANNENBAUM Claims 13 and 19 set forth that the izems in the transaction are captured (as a receipt would). This is shown by the electronic receipt of Makipaa, cited by Patent Owner in an IDS. The citation by Patent Owner recognizes that Makip& would be an obvious place to look for more details on such a transaction system. Since Schutzer captures electronic transaction information for a user’s records, with Makipaa providing more detail, it would hz obvious to combine the two. In particular, Makipaa explicitly describes the electronic receipt information beingprovided to Quicken, just as in the ‘720 Patent. Also, Mikipii, like Schutzer, describes transactions over the internet. Additionally, Tannenbaum also shows an itemization for a transaction with the use of a network (modem), and providing it to Quicken, thus it would be obvious to combine Tannenbaum with either Schutzer or Makipii. See also Shamos Declaration at 988-105. Claims 19 and 20 set forth additional elements similar to elements of claims 1 and 12, already discussed above, and as referenced in the claim chart helow. Prior Art (emphasis added) 13. The financial “As a result of storage of at least the verified electronic management system of | receipt, the user information system becomes either a claim 12, wherein the | personal or business database which stores detailed personal financial _| information about the contents of the transaction and the management | individual items included in the transaction such as that | application transaction | which is typically recorded on a paper receipt.” Makipidi data comprises 27-11. information about a plurality of particular | items that comprise rhe intermediate service provider 20 may provide the | the financial users with a service detailing their consumption habits | transaction and history. This kind of service can be provided over the consummated online. | web or by using standard data formats for personal | financial management software (i.e. Quicken).” Makipaa 11:61-63. “Today many computer programs exist, such as, for example, QUICKEN by Intuit, ... However, there remains one hitch in the process. And that is the fact that acredit card user must enter data from each transaction manually ....” Tannenbaum 1:25-41 54“Section 36 yields the account balance and section 37, the actual itemized transaction data. The user, under direction of the application program, can remove that data at this time for storage in the main accounting application, | if desired.” Tannenbaum 6:20-24. | “said card usage data being itemized transaction data. | pertaining to a cradit transaction, said itemized data including an identification of the individual transactions and the amounts thereof” ‘Tannenbaum claim 1. | 19. A financial nianagement system for creating a reminder for a financial transaction consummated online, the financial management system comprising: [a] a personal financial management application configured to store personal financial management application transaction data including purchase amount data, purchase date data, payee data, and card identification data, and [b] a financial assistant comprising: a set of graphical user interface generation executable code configured to generate a graphical user interface at the conclusion of the The preamble of claim 19 is identical to that of claim 12. See Schuzter and Chancey, above. This limitation is identical to that of 1[a], and is identically shown by Schuzter and Chancey. This limitation is identical to that of 1[b], and is identically shown by Schuzter and Chancey. -55-online transaction, the graphical user | interface comprising: [cla category field ‘This limitation is identical to that of 12[c], and is configured to accept | identically shown by Schuzter and Chancey. user input, and an accept button, a {d] a set of graphical | Tis jimitation is identical to that of 12[d], and is user interface identically showr. by Schuzter and Chancey. population executable code that populates the category field based on the received transaction data, and_ | 7 [e] a set of personal The “accept button” is the “OK” button shown as 347 in financial management | Fig, 27 of Schutzer. application transmission “the server automatically performing the financial executable code that transaction, and automatically downloading information transmits the personal | related to the performance of financial transactions from financial management | the server to the local client application. In addition, the application transaction | invention includes the steps of transferring downloaded data from the category | information related to performed financial transactions field of the graphical _ | from a local client application toa financial software user interface to the application ....” Schutzer 4:46-53 personal financial management Re information about a plurality of particular items that application when the _| comprise the financial transaction, see claim 13, above. accept button is activated, the personal financial management application transaction | data comprising information about a plurality of particular items that comprise | the financial transaction consummated online.| 20. The financial management system of claim 19, wherein the graphical user interface additionally comprises: In FIG. 24, if the user selects the Payment button 313, a pop-up window [GUI] 340 appears, ....Schutzer 16:6-7. a purchase amount field, | a purchase date field, a payee field, _| payment.” Schutzer 16:6-10. In FIG, 24, if the user selects the Payment button 313, a pop-up window 340 appears, a3 shown in FIG. 27. This window 340 allows the- user to input information about From Account 341, Payee Name 342, Amount 343, Date 344, and Category 345 in order to make a one-time “Date 344” See above. | “Payee Name 342” See above. | a category field configured to accept user input, field, and | a card identification “Category 345” See above “The merchant cetegory code is associated with a category recognized by the computer, and the transaction is assigned to the recognized category. If no recognized category exists, the process prompts the user for a category to which the transaction can be assigned.” Chancey Abstract. | “If no recognized category exists, the method may prompt a.user for selection of a category for association with the | merchant category code.” Chancey 2:32-34. “Account 341” See above. ,..the entry of financial transactions into the appropriate financial account--whether it credit card account, a checking account, or another account.” Chancey 1:58-60. an accept button. “The user may OK [Accept] 347 the payment or Cancel 348.” Schutzer 16:12-13. saeIV. CONCLUSION The Office is requested to find there is a reasonable likelihood that Petitioners will prevail and initiate an Inter Partes Review of Claims 1-20. The USPTO is authorized to charge any fees or credit any overpayments to Deposit Account No. 20-1430. Respectfully submitted, walt Dh Paul C. Haughey Registration No. 31,836 Lead Counsel for Petitioners Lead Counsel Back-Up Counsel Paul C, Haughey Scott E. Kolassa Registration No. 31,836 Reg. No. 55,337 phaughey@kilpatricktownsend.com Postal and Hand-Delivery Address: Kilpatrick Townsend & Stockton LLP Two Embarcadero Center, Eighth Floor San Francisco, CA 94111 Telephone: (415) 576-0200 Fax: (415) 576-0300 SKolassa@kilpatricktownsend.com Postal and Hand-Delivery Address: Kilpatrick Townsend & Stockton LLP 1080 Marsh Road Menlo Park, CA 94025 Telephone: (650) 324-6349 Fax: (650) 618-1544 -58-CERTIFICATE OF SERVICE The undersigned hereby certifies that a copy of this Petition for Inter Partes Review of U.S. Patent No. 8,132,720, including its supporting Exhibits (1001- 1011) and Power of Attorney has been served via Express Mail on May 18. 2015, upon the following: Finnavations LLC 3415 Custer Road, Suite 120-B Plano, TX 75023 Matthew G. Dyor 1646 184" Avenue NE Bellevue WA 98008 Respectfully Dated: May 18, 2015 Cue Y, By:_| & _K oF Paul C, Haughey Registration No. 31,836 Counsel for Petitioner 67301722V.1 -59-