Ex Parte Ivanoff et alDownload PDFPatent Trial and Appeal BoardOct 26, 201814954763 (P.T.A.B. Oct. 26, 2018) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE FIRST NAMED INVENTOR 14/954,763 11/30/2015 21186 7590 10/30/2018 SCHWEGMAN LUNDBERG & WOESSNER, P.A. P.O. BOX 2938 MINNEAPOLIS, MN 55402 Kent F. Ivanoff UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www .uspto.gov ATTORNEY DOCKET NO. CONFIRMATION NO. 4497.002US2 1050 EXAMINER GREGG, MARY M ART UNIT PAPER NUMBER 3697 NOTIFICATION DATE DELIVERY MODE 10/30/2018 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): uspto@slwip.com SLW@blackhillsip.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte KENT F. IVANOFF, VINCENT MARTINO, and NIKOLAUS TROTTA Appeal 2017-006131 1 Application 14/954,763 Technology Center 3600 Before MURRIEL E. CRAWFORD, MICHAEL W. KIM, and PHILIP J. HOFFMANN, Administrative Patent Judges. KIM, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE This is an appeal from the final rejection of claims 1-28. We have jurisdiction to review the case under 35 U.S.C. §§ 134 and 6. The invention relates generally "to techniques to acquire or otherwise access data pertaining to healthcare transactions and to provide business intelligence functionality and/or information." Spec.~ 2. 1 The Appellants identify iVinci Partners, LLC as the real party in interest. Appeal Br. 2. Appeal2017-006131 Application 14/954,763 Claim 1 is illustrative: 1. A method for transformation and processing of healthcare transaction data provided through a user-interactive graphical user interface, the method comprising electronic operations implemented with processor circuitry of a computing system, the electronic operations comprising: receiving a first set of healthcare transaction data created from a first healthcare transaction, the first set of healthcare transaction data provided from a first electronic healthcare billing system; receiving a second set of healthcare transaction data created from a second healthcare transaction, the second set of healthcare transaction data provided from a second electronic healthcare billing system, wherein the second electronic healthcare billing system maintains data for a different set of healthcare transactions than the first electronic healthcare billing system; creating an aggregate set of healthcare transaction data records from a combination of the first set of healthcare transaction data and the second set of healthcare transaction data, wherein the aggregate set of healthcare transaction data is associated with a user; creating a payment due data record from the aggregate set of healthcare transaction data records, wherein the payment due data record is established at a time of generation of the graphical user interface, and wherein payment due data record indicates an aggregated balance due for open charges of the first healthcare transaction and the second healthcare transaction that are tracked by the first electronic healthcare billing system and the second electronic healthcare billing system; creating a repayment decisioning data record for the user, wherein the repayment decisioning data record is established at the time of generation of the graphical 2 Appeal2017-006131 Application 14/954,763 user interface, and wherein the repayment decisioning data record is established from: evaluating a set of repayment data records associated with the aggregate set of healthcare transaction data records to generate an aggregate rule set for repayment of the aggregated balance due, wherein the aggregate rule set includes a repayment rule of a third electronic healthcare billing system; evaluating a set of user characteristic data records to determine current repayment characteristics of the user, wherein the current repayment characteristics are uniquely evaluated for the user for repayment of the aggregated balance due;and generating a minimum amount due and repayment characteristics for a repayment of the aggregated balance due, wherein the minimum amount due and the repayment characteristics are constrained to the repayment rule of the third electronic healthcare billing system indicated in the repayment data records and the current repayment characteristics of the user indicated in the user characte 1 istic data records; generating the graphical user interface, wherein the graphical user interface: outputs the aggregated balance due and aggregated healthcare transaction information including data from the aggregate set of healthcare transaction data records; and outputs multiple available payment options for at least a portion of the aggregated balance due, wherein the multiple available payment options indicate reduced payments that are customized to the minimum amount due, the repayment characteristics for the repayment 3 Appeal2017-006131 Application 14/954,763 of the aggregated balance due, and the current repayment characteristics of the user; rece1vmg an indication of a user-configured payment option from the multiple available payment options, in response to input by the user in the graphical user interface; verifying that the user-configured payment option complies with the repayment rule associated with the third electronic healthcare billing system for the repayment of the aggregated balance due; and m response to successful verification of the user- configured payment option: transmitting an electronic transaction request to effectuate an electronic transaction that transfers financial obligations of the first healthcare transaction from the first electronic healthcare billing system to the third electronic healthcare billing system, based on the indication of the user-configured payment option; and transmitting an electronic payment transaction request to effectuate multiple electronic transactions that perform repayment of at least a portion of the aggregated balance due for the second healthcare transaction to the second electronic healthcare billing system and for the first healthcare transaction to the third2 electronic healthcare billing system, based on the indication of the user- configured payment option. The Examiner rejected claims 1-28 under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. 2 We suspect, based on paragraphs 70, 71, 179, and 232 of the Specification, cited at Appeal Br. 7, that the payment goes to the first electronic billing system, not the third, because the third system is making the payments. 4 Appeal2017-006131 Application 14/954,763 The Examiner rejected claims 1-28 under 35 U.S.C. § 112(b) as indefinite. The Examiner rejected claims 1-28 under 35 U.S.C. § 101 as directed to ineligible subject matter in the form of abstract ideas. The Examiner rejected claims 1, 5, 7, 8, 11, 13-17, 20-24, 27, and 28 under 35 U.S.C. § 103 as unpatentable over Stamper et al., (US 2014/0039905 Al, pub. Feb. 6, 2014) ("Stamper"), Blain et al., (US 2012/0179605 Al, pub. July 12, 2012) ("Blain"), and Connell (US 8,583,492 B2, iss. Nov. 12, 2013). The Examiner rejected claims 2--4 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Franklin et al., (US 2007/0100747 Al, pub. May 3, 2007) ("Franklin"). The Examiner rejected claims 6, 18, 23, and 26 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Feilbogen et al., (US 2002/0023045 Al, pub. Feb. 21, 2002) ("Feilbogen"). The Examiner rejected claims 9 and 25 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Lidow (US 2005/0177435 Al, pub. Aug. 11, 2005). The Examiner rejected claim 10 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Rosenberg (US 2013/0103572 Al, pub. Apr. 25, 2013). The Examiner rejected claims 11 and 12 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Teague et al., (US 2005/0021462 Al, pub. Jan. 27, 2005) ("Teague"). 5 Appeal2017-006131 Application 14/954,763 The Examiner rejected claim 19 under 35 U.S.C. § 103 as unpatentable over Stamper, Blain, Connell, and Otterbach et al., (US 2006/0116906 Al, pub. June, 1, 2006) ("Otterbach"). We REVERSE. ANALYSIS Reiection under 35 U.S.C. § l 12(a) The Examiner finds that for independent claim 1, "neither the written description nor the original presentation of claims have support or possession of the function 'generation of the graphical user interface,"' and the Appellants "did not have possession of any algorithm to perform the claimed 'generation of the graphical user interface user interface."' Final Act. 32. The same reasoning is applied to reject independent claims 14 and 22, and all dependent claims. Id. 33-35. We are persuaded by the Appellants' argument that "[ o ]ne of ordinary skill in the art would understand that these webpage graphical user interfaces are generated when accessed by the client web browser." Appeal Br. 17. While there is no in haec verba requirement, newly added claim limitations must be supported in the specification through express, implicit, or inherent disclosure. The fundamental factual inquiry is whether the specification conveys with reasonable clarity to those skilled in the art that, as of the filing date sought, applicant was in possession of the invention as now claimed. See, e.g., Vas Cath Inc. v. Mahurkar, 935 F.2d 1555, 1563---64 (Fed. Cir. 1991). When an explicit limitation in a claim is not present in the written description, it must be shown that a person of ordinary skill would 6 Appeal2017-006131 Application 14/954,763 have understood that the description requires that limitation. Hyatt v. Boone, 146 F.3d 1348, 1353, (Fed. Cir. 1998). The Specification describes that "the private payment portal subsystem may generate and provide to a guarantor an electronic statement for a given period," and, referring to the user interface disclosed in Appellants' Figure 9, that the "user interface 900 may provide an interactive overview of an electronic statement that may include an account overview area 902, an autopay overview area 904, a payment options area 906, and an account summary area 908." Spec. ,r 162. We are persuaded that the ordinary artisan would have understood that generating a user interface, such as in Appellants' Figure 9, would have been done through well-known techniques at the time of invention, such as those techniques commonly used for generating a graphical user interface, as now claimed. The Examiner also finds no written description support for amended claim language related to a "data record is established at the time of the generation of the graphical user interface," because of a lack of description of the generation at "any specific time." Final Act. 33-34. We are persuaded by the Appellants' argument that the web page user interfaces are generated when accessed by a user, and thus are described in the original Specification as "established at a time of generation of the graphical user interface." Appeal Br. 22. For example, the Specification describes that: The interactive overview may be an interactive "statement" of charges that dynamically changes with user interaction. When a guarantor first logs in after receiving an electronic notice that a statement is ready, the interactive overview data may match or closely match the electronic statement and reflect, for example, 7 Appeal2017-006131 Application 14/954,763 a presumption that the preset or standard payment configuration for new charges will likely be utilized by the guarantor. Spec. ,r 205. This establishes that the user interface is created "dynamically," which provides support for the amended claim language. For these reasons, we do not sustain the rejection of claims 1-28 as failing the written description requirement of 35 U.S.C. § 112(a). Reiection under 35 U.S. C. § l l 2(b) The Examiner finds for all claims that "[because] there is no clarification as to the metes and bounds of the term 'generating the graphical user interface' the examiner is unable to determine if the term means to create an interface or for an existing interface in a system to function for communication." Final Act. 36-38. We agree with the Appellants that "[ o ]ne of ordinary skill in the art would read the terms 'generate', 'generation', and 'generating' in the independent claims as referring to 'creating' or 'producing' the graphical user interface, which is consistent with the commonly accepted dictionary definition for each of these terms." Appeal Br. 19 (emphasis omitted). The Specification, for example, describes that "[ u ]pon login, the user interface 900 may display to provide a viewing guarantor with an overview of the guarantor's account and/or any accounts managed by the guarantor." Spec. ,r 162. The generating of a graphical user interface therefore is merely displaying information on a device for a user to see, not creating a communication system. The Examiner also asserts the "creating step must happen before the generating step because the generating step outputs the result of the creating step. However, the claimed limitations are unclear with respect the claimed 8 Appeal2017-006131 Application 14/954,763 statement 'at the time of generation' and the other steps that seem to be happening ( concurrently or sequentially)." Answer 5-6. We agree with the Appellants that the two data records in the independent claims created at the time the GUI is generated clearly indicates that the records are generated at approximately the same time the GUI is prepared for display, rather than, for example, in an earlier batch process, for essentially the same rationale we set forth above as to the creation of the user interface. For these reasons, we do not sustain the rejection of claims as indefinite under 35 U.S.C. § 112(b). Re;ections under 35 U.S.C. § 103 We are persuaded by the Appellants' argument that Stamper does not disclose "transfers [ of] financial obligations of the first healthcare billing transaction from the first electronic healthcare billing system to the third information electronic healthcare bill system," as recited in independent claim 1. Appeal Br. 25. Independent claims 14 and 22 recite similar subject matter. In rejecting the corresponding claim language, the Examiner relies on Stamper, Figure 3, and paragraphs 30, 39, and 42--46. Final Act. 61-62. Figure 3 is a four-step flow chart that details receiving billing information, generating a statement, selecting payment options, and sending the statement and options to the user, but does not transfer any financial obligations to a third party. Stamper Fig. 3. Paragraph 30 describes aspects of the reconciliation statement. Paragraph 39 describes Figure 3. Paragraphs 42 and 43 provide additional information about the last two steps of Figure 3. Paragraphs 44--46 describe the computer system of Figure 4 that may be 9 Appeal2017-006131 Application 14/954,763 used to implement the Stamper system. None of the cited paragraphs transfer a financial obligation, as claimed. The Examiner responds by denoting the billing consolidation and payment consolidation aspects of Stamper, and asserts that "[b ]illing information is a financial obligation," and that Stamper meets the claim language because it discloses "healthcare providers transmitting billing information." Answer 2 7. The Specification, though, describes "automatically effectuat[ing] electronic transactions to transfer title of an accounts receivable asset that constitutes some or all rights to collect payment for the open charges balance." Spec. ,r 61. Merely transmitting billing information does not transfer title of the obligation to a different party. Instead, the invention requires a different entity to acquire the right to collect on the owed amounts as the transfer of obligations. Stamper does not address this act, and neither Blain nor Connell are relied on for this teaching. Therefore, we are persuaded that the Examiner has not shown sufficiently that the aforementioned limitation, recited, in some form, in each of independent claims 1, 14, and 22, is met by the prior art. For this reason, we do not sustain the rejections of claims 1-28 under 35 U.S.C. § 103. Reiection under 35 U.S. C. § 1 OJ The Examiner finds the independent claims "are directed to the abstract idea of combining billing data received, offering to a client repayment options according to rules, effecting an obligation transfer of the bill based on client repayment options selected and rules and requesting 10 Appeal2017-006131 Application 14/954,763 repayment on bills." Final Act. 39; Ans. 6. 3 The Examiner then parses out the portions of the claim concerning each of those respective concepts, and analogizes them to a particular case. The Examiner next determines that claim elements "beyond the identified abstract concept include a computer system comprising a memory circuitry, a processor circuitry, a storage medium including instructions that for execution by the processor circuitry and memory circuitry recited at a high level of generality to perform well- understood conventional computer functions." Final Act. 42. The Examiner also views the claims as a whole, but finds "the claim limitations do not add limitations other than what is well understood, routine and conventional in the field, nor [do] the claimed limitations add unconventional steps that confine the claimed limitation to a particular useful application." Id. at 43. The Examiner's approach is problematic, because while we are cognizant that a claim can be directed to multiple abstract ideas, we are the persuaded that it is improper to eliminate claim language on a concept by concept basis, as we are persuaded that goes against our reviewing court's instruction to consider the claim as a whole. Put practically, for two given abstract ideas claimed in combination, one of those abstract ideas may represent something "significantly more" relative to the other abstract idea. Having said that, we are in agreement with the Examiner's implicit assessment that the some of the proffered concepts, even when evaluated 3 In doing so, the Examiner adopts a formulation of claim 1 similar, but not identical, to that set forth by the Board in a prior decision. Ex parte i Vinci Partners, LLC, Appeal 2017-004177, slip op. at 10 (PTAB July 13, 2018) ("Therefore, for claim 1, we would reformulate the Examiner's finding to be that claim 1 is directed to consolidating billing information, offering to the user periodic payment options for the amount due, and permitting the user to alter the periodic payment amount the payments are based on."). 11 Appeal2017-006131 Application 14/954,763 under the above rubric, are not patent-eligible. For example, we are unpersuaded that the concepts of "combining billing data received" and "offering to a client repayment options according to rules" are anything other than abstract ideas. See, e.g., In re Salwan, 681 F. App'x 938, 941 (Fed. Cir. 2017), cert. denied sub nom. Salwan v. Mata!, 138 S. Ct. 278, 199 L. Ed. 2d 178 (2017), reh'gdenied, 138 S. Ct. 496, 199 L. Ed. 2d 379 (2017); LendingTree, LLC v. Zillow, Inc., 656 F. App'x 991, 996 (Fed. Cir. 2016); Credit Acceptance Corp. v. Westlake Servs., 859 F.3d 1044, 1054 (Fed. Cir. 2017); CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1373 (Fed. Cir. 2011). Furthermore, it is plausible that the concept of "combining billing data received" does not add "significantly more" to the abstract idea of "offering to a client repayment options according to rules," because the former can perhaps be characterized as merely data gathering, which has held by the courts as not constituting "significantly more." Id. at 1370 ("We have held that mere '[data-gathering] step[s] cannot make an otherwise nonstatutory claim statutory."'). The more difficult concept, however, is "effecting an obligation transfer of the bill based on client repayment options selected and rules and requesting repayment on bills," where each independent claim recites language substantially similar to: in response to successful verification of the user-configured payment option: transmitting an electronic transaction request to effectuate an electronic transaction that transfers financial obligations of the first healthcare transaction from the first electronic healthcare billing system to the third electronic 12 Appeal2017-006131 Application 14/954,763 healthcare billing system, based on the indication of the user- configured payment option. For these limitations, the Examiner asserts that this is similar to "( ( creating a contract) (buySafe); comparing new and stored information and using rules to identify options (SmartGene))." Final Act. 42. We are unclear as to how the case law cited relates to "effecting an obligation transfer of the bill based on client repayment options selected[,] and rules and requesting repayment on bills." For buySafe, while the obligation transfer certainly involves creating a contract, that is but one aspect of the outlined concept. And for SmartGene, while certainly the repayment option chosen by the client is identified, that, again, is but one aspect of the outlined concept. Furthermore, even if the above limitations are evaluated under Step 2 of Alice, the Examiner has not identified any evidence in the record, or provided a sufficient analysis, to show that it would not constitute "significantly more" with respect to either of the other concepts identified above under Step 1 of Alice as abstract ideas, namely, "combining billing data received" or "offering to a client repayment options according to rules." For example, when selling receivables amounts to a third party, the Examiner has not identified any evidence in the record, or provided a sufficient analysis, to show that it is well-understood, routine, and conventional to base a transfer of the financial obligation of the receivables on the user's selection of a financing option, as claimed. At best, paragraph 232 of the Specification describes the practice of "factoring"; however, there, receivables balances are not sold based on user selection, as claimed. For these reasons, we do not sustain the rejection of claims 1-28 under 35 U.S.C. § 101. 13 Appeal2017-006131 Application 14/954,763 DECISION We REVERSE the rejection of claims 1-28 under 35 U.S.C. § 112(a) as failing the written description requirement. We REVERSE the rejection of claims 1-28 under 35 U.S.C. § 112(b) as indefinite. We REVERSE the rejections of claims 1-28 under 35 U.S.C. § 103. We REVERSE the rejection of claims 1-28 under 35 U.S.C. § 101. REVERSED 14 Copy with citationCopy as parenthetical citation