CTNF 19/092,249 CTNF 92928 DETAILED ACTION Acknowledgements This action is in response to Applicant’s filing on Mar. 27, 2025, and is made Non-Final . This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082. Interviews Examiner interviews are available by telephone or, preferably , by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. If Applicant desires an interview more quickly than permitted by the AIR scheduling tool, please include this information in the AIR remarks for consideration. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits. MPEP § 713. Each AIR should specifically explain how the interview will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner's analysis, proposed claim amendments, or another concrete basis for discussion. An agenda (e.g., using USPTO Form PTOL-413A) submitted in advance is strongly encouraged, as examiners use agendas when determining whether to grant an interview. If the AIR form’s character limits prevent inclusion of all pertinent details, which is anticipated, please send a contemporaneous email with the details (e.g., the Interview agenda) to the Examiner at James.Miller1@uspto.gov and reference the filed AIR. For After-Final Interview Requests , interviews are conducted at the Examiner’s discretion. Applicant does not have a right to an interview. After-Final Interviews will be granted only if the Examiner is convinced that disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST. For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial. If an interview request is denied and Applicant believes the denial is unwarranted, Applicant may contact the Examiner's supervisor, Ben Sigmond at (303) 297-4411. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statement (IDS) submitted on Mar. 27, 2025 , was filed before the mailing of a first office action on the merits and therefore, is in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDS has been considered. Claim Status The status of claims is as follows: Claims 1–20 are pending and examined with Claims 1, 11, and 16 in independent form. This is a first action on the merits. Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more. Analysis Step 1 : Claims 1–20 are directed to a statutory category. Claims 1–10 recite a “method” and are therefore, directed to the statutory category of a “process.” Claims 11–15 recite a “computer” and are therefore, directed to the statutory category of a “machine.” Claims 16–20 recite a “method” and are therefore, directed to the statutory category of a “process.” Representative Claim Claim 11 is representative [“Rep. Claim 11”] of the subject matter under examination and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations 1 and underline , as needed, in further describing the abstract idea exception: [A] 11. An orchestrator computer comprising: a processor ; and a computer readable medium , the computer readable medium comprising code , executable by the processor , for performing a method comprising: [B] receiving, from a storage application server , a data packet comprising access data ; [C] receiving, from a transport computer , a request for the data packet [access data], after the transport computer receives a message comprising a value and a resource provider identifier from a resource provider computer ; and [D] transmitting, to the transport computer , a response comprising the data packet [access data], [E] wherein the transport computer is programmed to [F] receive the data packet [access data], [G] generate an authorization request message comprising the access data, the resource provider identifier, and the value, and [H] transmit the authorization request message to an external computer for authorization processing. Claims are directed to an abstract idea exception. Step 2A, Prong One : Rep. Claim 11 recites “[B] receiving … a data packet comprising access data; [C] receiving … a request for the data packet [access data], after … receiv[ing] a message comprising a value and a resource provider identifier … ; and [D] transmitting … a response comprising the data packet [access data], … [F] receive the data packet [access data], [G] generate an authorization request message comprising the access data, the resource provider identifier, and the value, and [H] transmit the authorization request message … for authorization processing, which recites commercial or legal interactions under the organizing human activity exception because communicating “access data” between parties, “generat[ing] an authorization request message comprising the access data,” and “authorization processing,” recites “sales activities or behaviors, and business relations” between two or more parties. MPEP § 2106.04(a)(2)(II)(B). The timing condition (i.e., “after … receiv[ing] a message comprising a value and a resource provider identifier”) merely narrows when the abstract routing occurs without adding any technical details. “Data packet” is recited without any technical character (e.g., structure, protocol, format, or architecture) and under BRI is merely a label for a collection of data being passed between parties. Alternatively 2 , Limitations B–H , as drafted, recite the abstract idea exception of mental processes that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but fo r the recitation of the generic computer components indicated in bold . MPEP § 2106.04(a)(2)(III). Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include: • a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A. , 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016); . . . • a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC , 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011). MPEP § 2106.04(a)(2)(III)(A). For example, but for the generic computer components claim language, here, Limitations B–H , recite collecting information ( Limitations B, C, D, F, H ) and organizing and packaging information ( Limitations G), where all the steps are recited at a high level of generality such that they could practically be performed in the human mind. Spec. ¶¶ 72–82. For example, Limitation G is a mental process that is practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to organize and package information by “generat[ing] an authorization request message comprising the access data, the resource provider identifier, and the value,” which is equivalent of a human clerk assembling known data fields onto a paper authorization form. Spec. ¶ 29. Limitation G covers any solution to “generat[ing] an authorization request message” with the recited data with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which is so broad as to encompass mental processes. If a claim limitation under BRI, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract idea exception. MPEP § 2106.04(a)(2)(III). Accordingly, the pending claims recite the combination of these abstract idea exceptions. Step 2A, Prong Two : The additional elements identified in Rep. Claim 11, considered individually and as an ordered combination, do not integrate the abstract idea exception into a practical application. MPEP § 2106.04(d). The additional elements are limited to the computer components and indicated in bold , supra . The additional elements are: An orchestrator computer comprising: a processor; and a computer readable medium comprising code; a storage application server; a transport computer; a resource provider computer; and an external computer. The additional elements do not improve the functioning of a computer or other technology. MPEP § 2106.05(a) . A claim improves technology only when it recites a specific improvement to the way a computer itself operates, not merely the application of an existing process using a computer. MPEP § 2106.05(a) (citing Enfish, LLC v. Microsoft Corp. , 822 F.3d 1327, 1336 (Fed. Cir. 2016)). Here, the abstract idea exception of receiving data, receiving a request for the data, and transmitting a response comprising the data to generate and transmit an authorization request message for authorization processing was previously performed manually (e.g., a user presenting payment credentials to a merchant clerk, who assembles that transaction data and submits it to a bank for authorization). Spec. ¶¶ 2–5. Because the process can be performed manually, the computer is not being improved and is merely being used as a tool to perform the pre-existing manual process. Applying a pre-existing manual process using generic computer components is not an improvement to computer technology. The specification confirms this characterization by describing the advantages of the claimed system in terms of business outcomes (resource provider computer need not be PCI-DSS complaint and that storage applications not affiliated with resource provider computers can conduct transactions) rather than in terms of any specific technical improvement to the computer, server, network infrastructure, or computer architecture itself. Spec. ¶ 99. The specification does not describe any specific technical improvement to authorization algorithms, communication protocols, encryption methods, data structures, network protocols, or computer architecture. Spec. ¶¶ 44, 56, 64, 100–103. Thus, any improvements describe business outcomes, not technical improvements to the computers themselves. The additional elements do not apply the abstract idea with a particular machine. Although the claims recite specific hardware components (i.e., orchestrator computer comprising: a processor; and a computer readable medium comprising code; a storage application server; a transport computer; a resource provider computer; and an external computer), these components are recited at a high functional level and perform only their generic functions of receiving, transmitting, storing, and processing data. Spec. ¶¶ 35–37, 56, 64. A machine is “particular” only when it imposes a meaningful limit on the claims scope. MPEP § 2106.05(b). Here, any general purpose server or computer with the ability to receive, store, and transmit data would satisfy the claims’ hardware requirements, which confirms that the hardware components are generic rather than “particular.” MPEP § 2106.05(b). The specification describes each computer component using broad, open-ended language (e.g., the orchestrator computer “may comprise a processor 402” and its computer readable medium “can comprise various software modules and APIs”) without restricting the claimed hardware to any particular design, configuration, or architecture. Spec. ¶ 56. The additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f) . Regarding the additional elements, Applicant’s Specification does not otherwise describe them with specificity beyond exemplary language or describes them as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. The specification’s own broad, exemplary characterization confirms that these components are not described in a manner that would impose any specific technical limitation that would integrate the abstract idea into a practical application. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co. , 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers , 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g. , Spec. ¶ 35 (“a processor can include any suitable data computation device or devices.”); ¶ 36 (“A "memory" may be any suitable device or devices”); ¶ 37 (“A "server computer" may include a powerful computer or cluster of computers.”); ¶ 56 (orchestrator computer processor and medium described by name and function only); ¶ 100 (“any of the embodiments can be implemented in the form of control logic using hardware … and/or using computer software with a generally programmable processor in a modular or integrated manner.”); ¶ 101 (“Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language”). The generic processor, here, performs calculations (functions) and executes instructions that are programmed by software directed to the abstract idea. Spec. ¶¶ 35, 56, 57. This is a computer doing what it is designed to do—performing directions it is given to follow, and whose directions are directed to the abstract idea. Limitation A describes the processor executing “code” stored in at least one computer readable memory [“memory device”] to perform the steps of the claimed invention. This takes generic hardware and describes the functions of receiving, storing, and sending data (instructions) between the processor and memory device, which merely invokes computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2). Limitations B–H describe the processor, memory device, and instructions, performing the steps of the claimed invention, which represents the abstract idea exception itself on a general-purpose computer. Performing the steps of the abstract idea exception using a computer, merely adds a general-purpose computer after the fact to an abstract idea exception without imposing any meaningful technical limitations. MPEP § 2106.05(f)(2). Alternatively , the claim generically recites an effect of the abstract idea without specifying how the computer achieves that effect in any technically meaningful way. MPEP § 2106.05(f)(3); see also Spec. ¶¶ 56, 57. Therefore, the claim as a whole, considering the additional elements individually and as an ordered combination, amounts to no more than mere instructions to apply the abstract idea using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 11 is directed to an abstract idea. Independent Claims 1 and 16 are not substantially different than Rep. Claim 11, recite the same abstract idea as Rep. Claim 11, and contain no additional elements not otherwise analyzed for Rep. Claim 11. Therefore, Independent Claims 1 and 16 are also directed to the same abstract idea. The claims do not provide an inventive concept. Step 2B : Rep. Claim 11 fails Step 2B because the claim as a whole, even when considering the additional elements individually and in combination, does not amount to significantly more than the abstract idea. MPEP § 2106.05. The additional elements (i.e., An orchestrator computer comprising: a processor; and a computer readable medium comprising code; a storage application server; a transport computer; a resource provider computer; and an external computer) , are each well-understood, routine, and conventional (“WRC”) computer components and functions in the relevant field, as evidenced by Applicant’s own disclosure 3 . Further, Applicant’s Specification discloses that these components operate in no particular order and are implemented using generic, off-the-shelf computing technology. Spec. ¶ 103 (steps/functions may be performed in any order or concurrently); ¶¶ 35–37, 100, 101 (describing each component using exemplary language as generic or known computing equipment and networks). (1) An orchestrator computer comprising: a processor; and a computer readable medium comprising code are WRC in the financial technology field. Spec. ¶¶ 35, 36, 56, 100, 101. (2) a storage application server; a transport computer; a resource provider computer; and an external computer are WRC. Spec. ¶¶ 37, 39, 64, 100, 101. The Specification further confirms that the functions of receiving, storing, transmitting, and processing data are normal, well-understood operations of generic computer systems, and the steps may be performed in any order or concurrently. See, e.g. , Spec. ¶¶ 56, 64, 103. The combination is also WRC at the high level of generality recited : The combination of the additional elements is likewise WRC. A combination of individually well-understood, routine, and conventional elements does not provide an inventive concept unless the combination itself produces an unconventional result or is applied in an unconventional manner. MPEP § 2106.05(d)(2). Here, the combination performs each step in exactly the manner described as conventional throughout Applicant’s own Specification. Spec. ¶¶ 56, 64, 100–103. There is no indication that the combination of these elements operates in an unconventional manner or produces a result that is other than what would be expected from the generic application of these individual components. Unlike BASCOM , where the claims recited a specific non-conventional arrangement of installing a filtering tool at a specific network location (an ISP server) rather than on individual end-user devices, Rep. Claim 11 does not recite how the elements are combined in a non-conventional way. The claims recite each element at a high level of generality without specifying the particular arrangement or order that constitutes the alleged improvement. At the high level of generality recited (receiving, receiving, transmitting, receive, generate, transmit), the combination is WRC. Any BASCOM argument fails because any non-conventional arrangement allegedly described in the specification (specifically, the use of the orchestrator computer as a privacy-preserving intermediary that stores a user’s access data and routes it via a session identifier so that the resource provider never obtains the user’s credentials) is simply not recited in the claims. Spec. ¶¶ 75, 79, 99. Rep. Claim 11 recites only the abstract steps of receiving, receiving, transmitting, receive, generate, and transmit without incorporating any specific technical details for how these elements are performed. A non-conventional arrangement that is described but not claimed cannot supply the inventive concept at Step 2B. Because the claims here recite only generic components performing generic functions at a high level of generality, the abstract idea recited in claims cannot be improved by a computer. MPEP § 2106.05(f). No inventive concept is present under Step 2B. MPEP § 2106.05(d). Accordingly, the additional elements of Rep. Claim 11 have been recognized, based on Applicant’s own disclosure, as WRC activity in the field. MPEP § 2106.05(d). These elements do no more than “apply” the recited abstract idea(s) using known computer and computer-related components. See also Step 2A, Prong Two, supra . Independent Claims 1 and 16 are method claims reciting steps that perform the same abstract processing and generic computer operations recited in Rep. Claim 11. Independent Claims 1 and 16 add no additional elements beyond those of Rep. Claim 11 that would amount to significantly more than the abstract idea. Therefore, Independent Claims 1 and 16 also do not recite an inventive concept under Step 2B. Dependent Claims Not Significantly More The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination with the elements of the independent claims. Each dependent claim incorporates all the limitations of its parent Independent Claim and therefore recites the same abstract idea. The additional limitations recited in the dependent claims do not integrate the abstract idea exception into a practical application under Step 2A, Prong Two, and do not amount to significantly more than the abstract idea under Step 2B, for the following reasons: Dependent Claims 2, 3, 18, and 19 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional elements. These claims merely narrow the type of message generated or the type of data routed (the abstract idea) by specifying sub-categories of information within the abstract collection and routing process. They add no structural or technical element beyond the abstract idea itself. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). Dependent Claims 4, 5, and 6 narrow the resource computer to an energy supply terminal or energy supply operator terminal, narrow the energy supply terminal to an electrical charging terminal, narrow the storage application server managing a storage application on a user device or vehicle, and narrow the data packet timing to after a user initiates a charging session between the vehicle and the electrical charging terminal. These claims generally link the abstract idea of the Independent Claims to a particular technological environment, i.e., the EV charging environment. MPEP § 2106.05(h). Confining an abstract idea to a particular technological environment does not integrate the abstract idea into a practical application and does not amount to significantly more. MPEP § 2106.05(h); MPEP §§ 2106.05(I); 2106.04(d)(III). Dependent Claims 7, 8, 9, and 20 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims. All of the claimed computers and their functions are described in the specification only at a high level using generic, exemplary language, which confirms that are WRC components in the financial technology field. Spec. ¶¶ 33, 34. De-tokenization (i.e., looking up a token in a token vault to retrieve the corresponding credential) is itself a conventional operation described without any specific technical character. Spec. ¶¶ 26–28, 34. These additional elements, individually and in combination with the independent claims, are WRC based on Applicant’s own specification and therefore, do not integrate the abstract idea into a practical application or amount to significantly more. MPEP § 2106.05(d); MPEP §§ 2106.05(I); 2106.04(d)(III). Dependent Claims 10, 12, 13, 14, 15, 17 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims. Claims 10 and 15 recite one or more APIs for communicating between the orchestrator computer, storage application server, and transport computer. Spec. ¶¶ 56, 75. Claims 12, 13, 14, and 17 recite a data storage for storing data packets, a session identifier, and the retrieval of the data packet using the session identifier. Spec. ¶¶ 56, 65, 75, 79, 87. APIs are generic, WRC inter-computer communication interfaces described by name only without any specific technical description in the specification or claims. A session identifier is a conventional data label generated by a routine random number generator algorithm used to associate stored records with a transaction session. Spec. ¶ 56. Retrieving a stored record using an identifier is the functional equivalent of a librarian locating a book by a reference number using the Dewey decimal system and a conventional manual process. Spec. ¶¶ 79, 87. These additional elements, individually and in combination with the independent claims, are WRC based on Applicant’s own specification and therefore, do not integrate the abstract idea into a practical application or amount to significantly more. MPEP § 2106.05(d); MPEP §§ 2106.05(I); 2106.04(d)(III). Conclusion Claims 1–20 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 11 otherwise styled as a A1nother statutory category is subject to the same analysis. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 1–20 are rejected under 35 U.S.C. 103 as being unpatentable over Patterson et al. (U.S. Pat. Pub. No. 2022/0343314) [“Patterson”] in view of FOR: (Int. Pat. Pub. No. WO 2023/192206 A1) [“FOR-Sullivan”] . Regarding Claim 1, Patterson discloses : A method comprising: (See at least Abstract, “method is disclosed.” receiving, by an orchestrator computer [SRT System 70] from a storage application server [Application server 80] , a data packet comprising access data [user's payment information, Spec. ¶ 24] ; (See at least ¶ 71, a "checkout request" is sent from the “application server 80 associated with the digital application 10A-1” to the “SRT system 70 via an API.” ¶ 71. “The message can comprise resource provider account information, the transaction currency, the transaction amount, and the user's payment information (such as card data and account data) in the form of the access data reference identifier (e.g., a digital card reference identifier) associated with the access data corresponding to the selected user device in step S204.” ¶ 71.) receiving, by the orchestrator computer [SRT System 70] from a transport computer [transport computer 30] , a request for the data packet [get payload message] , (See at least ¶ 74, “In step S209, the transport computer 30 transmits a get payload message to the SRT system 70 via an API to retrieve the payload data that was prepared in step 208.”) […] transmitting, by the orchestrator computer to the transport computer, a response comprising the data packet, (See at least ¶ 75, “In step S210, the SRT system 70 sends a payload response message including the payload to the transport computer 30.” “The SRT system then sends a payload data response with the payload and optionally the correlation ID to the transport computer.” ¶ 44. wherein the transport computer is programmed to receive the data packet, generate an authorization request message comprising the access data, the resource provider identifier, and the value, and transmit the authorization request message to an external computer for authorization processing. (See at least ¶ 77, “In step S212, the transport computer 30 generates an authorization request message comprising the received payload data and sends it to the processing network computer 40. The authorization request message may comprise at least a token, a token cryptogram, an amount of the transaction, and a resource provider identifier.”) Patterson discloses receiving, by the orchestrator computer from a transport computer, a request for the data packet, after the transport computer receives a message. Patterson does not disclose the transport computer receives a message comprising a value and a resource provider identifier from a resource provider computer. Patterson merely discloses a “notification with the correlation ID .” Patterson, ¶ 42. Thus, Patterson does not disclose but FOR-Sullivan discloses : after the transport computer receives a message comprising a value [preauthorization amount] and a resource provider identifier from a resource provider computer [service provider computer 108] ; and (See at least ¶ 109, “the service provider computer 108 can transmit the authorization request message to an authorizing entity computer 114 … via a transport computer operated by an acquirer and a processing network computer 112.” The authorization request message contains a “pre-authorization amount (e.g., an amount of funds to be reserved for payment of charging the electric vehicle 103) … The preauthorization amount may be included with a token or credential in an authorization request message.” ¶ 106. Because the message is transmitted "via" the transport computer, the transport computer necessarily receives this message from the service provider computer 108 (resource provider computer). Regarding the claimed “resource provider identifier,” Patterson discloses that an authorization request message in a payment-network context "may comprise at least a token, a token cryptogram, an amount of the transaction, and a resource provider identifier," Patterson, ¶ 77, and that such messages also include transaction data such as "the transaction amount, merchant identifier, [and] merchant location." Patterson, ¶ 26. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention, to have combined after the transport computer receives a message comprising a value and a resource provider identifier from a resource provider computer, as taught by FOR-Sullivan, to the known invention of Patterson, in the same field of invention, with the motivation to improve payment security. FOR-Sullivan, ¶¶ 3, 4. Further, It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention, to implement FOR-Sullivan’s authorization request message in the same conventional payment-network environment, to include a resource provider identifier (as disclosed by Patterson for authorization request messages, Patterson, ¶¶ 26, 77) with the pre-authorization amount and credential/token already present in FOR-Sullivan’s authorization request message with the motivation to identify the resource provider so the correct merchant/service provider can be credited for the transaction and promptly routed and authorized in the payment network. Regarding Claim 2, Patterson and FOR-Sullivan discloses : The method of claim 1 and the authorization request message Patterson does not disclose but FOR-Sullivan discloses : wherein the authorization request message is a pre-authorization request message. (See at least ¶ 106), “The service provider computer 108 10 may determine the pre-authorization amount after receiving and determining the information regarding the percent battery charge amount requested or needed to fully charge the battery in the electric vehicle 103 … The preauthorization amount may be included with a token or credential in an authorization request message. … if $20 was held and the actual cost of the charge was $10, then the hold on the remaining $10 is released.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the authorization request message is a pre-authorization request message , as taught by FOR-Sullivan, to the known invention of Patterson, in the same field of invention, with the motivation to reserve funds when the final transaction amount is now known thereby reducing the risk on non-payment. Regarding Claim 3, Patterson and FOR-Sullivan discloses : The method of claim 1 and the authorization request message Patterson does not disclose but FOR-Sullivan discloses : wherein the authorization request message is a current authorization request message. (See at least ¶ 106, “After the charging of the electric vehicle 103 is completed, the 25 cost of the charge is later determined by the service provider computer 108 and a subsequent message (e.g., another authorization or clearing message) may be sent to the authorizing entity computer with the actual cost of the charge, and the previous hold may be released. For example, if $20 was held and the actual cost of the charge was $10, then the hold on the remaining $10 is released.” The “current authorization request message” is the “true-up” or final payment message after charging is complete.) The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 2 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 3. Regarding Claim 4, Patterson and FOR-Sullivan discloses : The method of claim 1 and the resource provider computer Patterson does not disclose but FOR-Sullivan discloses : wherein the resource provider computer is an energy supply terminal or an energy supply operator terminal. (See at least ¶ 44, “The system can also include an energy supply terminal 105” The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 4. Regarding Claim 5, Patterson and FOR-Sullivan discloses : The method of claim 4 and the energy supply terminal Patterson does not disclose but FOR-Sullivan discloses : wherein the energy supply terminal is an electrical charging terminal, and the storage application server manages a storage application on a user device or a vehicle. (See at least ¶ 44, “The system can also include an energy supply terminal 105 (e.g., an electric vehicle charging station).) The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 5. Regarding Claim 6, Patterson and FOR-Sullivan discloses : The method of claim 5 and the data packet Patterson discloses a user initiates a transaction and the orchestrator (SRT System 70) receives a data packet. Patterson, Fig. 3. Patterson does not disclose the initiation is a charging session between the vehicle and the electrical charging terminal. Thus, Patterson does not disclose but FOR-Sullivan discloses : wherein the data packet is received by the orchestrator computer after a user initiates a charging session between the vehicle and the electrical charging terminal. (A user initiates a charging session by establishing a communication session between an electric vehicle 103 and an energy supply terminal 105 (Fig. 1) via an electrical charging cable (¶ 46). After the session is established, the vehicle obtain a credential or token, generates an encrypted data packet including the credential or token and provides it to the energy supply terminal, which transmits the data packet to a service provider computer 108 (orchestrator computer). FOR-Sullivan, ¶ 8. The encrypted data packet is received by the service provider computer 108 (orchestrator computer) after a user initiates charging.) The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 6. Regarding Claim 7, Patterson and FOR-Sullivan discloses : The method of claim 1 and the external computer Patterson further discloses wherein the external computer is an authorizing entity computer, the authorizing entity computer being programmed to analyze the authorization request message, generate an authorization response message, and transmit the authorization response message to the transport computer. (See at least ¶ 29, “An "authorizing entity" may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorizing entity computer.” “The authorizing entity computer 60 may then decide if the transaction is authorized or not. The authorization may be based upon whether the user has sufficient value and/or if the user or communication device has been sufficiently authenticated.” ¶ 79. “In step S218, the authorizing entity computer 60 may transmit an authorization response message comprising the transaction approval or denial code, and the real credential, back to the processing network computer 40.”) Regarding Claim 8, Patterson and FOR-Sullivan discloses : The method of claim 7 and the external computer Patterson further discloses wherein the external computer is a network processing computer. (See at least ¶¶ 49, 50). Regarding Claim 9, Patterson and FOR-Sullivan discloses : The method of claim 8 and the access data, the network processing computer Patterson further discloses wherein the access data comprises a token, the token being a substitute for a credential, and (See at least ¶ 23, “A "token" may be a substitute value for a credential.” “In some embodiments, the access data in the payload may comprise a token that corresponds to the access data reference identifier, a token expiration date, and a cryptogram.” ¶ 43.) wherein the network processing computer is programmed to receive the authorization request message comprising the token, de-tokenize the token to obtain the credential, and transmit the authorization request message comprising the credential, the resource provider identifier to the authorizing entity computer for authorization. (See at least ¶ 45, “After the payload is received by the transport computer, the transport computer then incorporates the payload data into an authorization request message, and sends the authorization request message to a processing network computer.” “The token service system may support token processing of transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN and conducting a transaction using that PAN.” ¶ 25. “The processing network computer can communicate with a token provider computer to validate the cryptogram … The processing network computer may also communicate with a token provider computer to obtain a real credential associated with the token . After the real credential is obtained by the processing network computer, the processing network computer may transmit a modified authorization request message with the real credential to an authorizing entity computer for authorization.” ¶ 45.) Regarding Claim 10, Patterson and FOR-Sullivan discloses : The method of claim 1 and the orchestrator computer and the storage application server Patterson further discloses wherein the orchestrator computer and the storage application server communicate via one or more APIs. (See at least ¶ 41, “The digital application then sends a message to the SRT system via a dedicated APL” See also, ¶¶ 44, 74. Regarding Claim 11, Patterson discloses : An orchestrator computer comprising: a processor; and a computer readable medium, the computer readable medium comprising code, executable by the processor, for performing a method comprising: (See at least Fig. 6) The remaining limitations of Claim 11 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis , based on Patterson and FOR-Sullivan for the same rationale presented in Claim 1 supra . The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 11. Regarding Claim 12, Patterson and FOR-Sullivan discloses : The orchestrator computer of claim 11 and the orchestrator computer Patterson further discloses : wherein the orchestrator computer comprises a data storage for storing the data packet and other data packets. (See at least Fig. 6, system memory 62 and databases 66A, 66B. “The SRT system 70 stores registration data (e.g., a network address, a name, etc.) associated with the resource provider in a database in the SRT system 70 along with details (e.g., a network address, a name, etc.) regarding the entity operating the transport computer 30.” ¶ 53. “The SRT system then searches a database for the access data corresponding to the received access data reference identifier, and then retrieves the corresponding access data from the database.” ¶ 40.) Regarding Claim 13, Patterson and FOR-Sullivan discloses : The orchestrator computer of claim 12 and the data packet Patterson further discloses : wherein the data packet comprises a session identifier [SRT correlation identifier] . (See at least ¶ 42, “then the SRT system retrieves transport computer (e.g., acquirer computer) details (e.g., a URL of the acquire computer) from its registration database, and generates an SRT correlation identifier or SRT correlation ID. Once the SRT correlation ID is generated, the SRT system can send a notification with the correlation ID to the transport computer via dedicated payment URL. The SRT system can also prepare a payload including the access data associated with the access data reference identifier.”) Regarding Claim 14, Patterson and FOR-Sullivan discloses : The orchestrator computer of claim 13 and the request for the data packet Patterson further discloses : wherein the request for the data packet [message including the correlation ID to the SRT] comprises the session identifier, and the method further comprises: retrieving the data packet using the session identifier. (See at least ¶ 44, “After receiving the notification from the SRT system, the transport computer then sends message including the correlation ID to the SRT system via an API to retrieve the generated payload data. The SRT system then sends a payload data response with the payload and optionally the correlation ID to the transport computer.” Regarding Claim 15, Patterson and FOR-Sullivan discloses : The orchestrator computer of claim 11 and the orchestrator computer Patterson further discloses : wherein the orchestrator computer comprises one or more APIs for communicating with the storage application server and the transport computer. (See at least ¶ 41, “The digital application then sends a message to the SRT system via a dedicated APL” See also, ¶¶ 44, 74.) Regarding Claim 16, Patterson discloses : A method comprising: (See at least Abstract) The remaining limitations of Claim 16 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis , based on Patterson and FOR-Sullivan for the same rationale presented in Claim 1 supra . The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis , to support the rejection of Claim 16. Regarding Claim 17, Patterson and FOR-Sullivan disclose The method of claim 16, The remaining limitations of Claim 17 are not substantively different than those presented in the combination of Claims 13 and 14 and are therefore, rejected, mutatis mutandis , based on Patterson and FOR-Sullivan for the same rationale presented in Claims 13 and 14, supra . Regarding Claim 18, Patterson and FOR-Sullivan disclose The method of claim 16 The remaining limitations of Claim 18 are not substantively different than those presented in Claim 2 and is therefore, rejected, mutatis mutandis , based on Patterson and FOR-Sullivan for the same rationale presented in Claim 2, supra . Regarding Claim 19, Patterson and FOR-Sullivan disclose The method of claim 16 and the access data Patterson further discloses : wherein the access data comprises a credential. (See at least ¶ 17) Regarding Claim 20, Patterson and FOR-Sullivan disclose The method of claim 16 The remaining limitations of Claim 20 are not substantively different than those presented in Claim 8 and is therefore, rejected, mutatis mutandis , based on Patterson and FOR-Sullivan for the same rationale presented in Claim 8, supra . Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /JAMES H MILLER/Primary Examiner, Art Unit 3694 Application/Control Number: 19/092,249 Page 2 Art Unit: 3694 Application/Control Number: 19/092,249 Page 3 Art Unit: 3694 Application/Control Number: 19/092,249 Page 4 Art Unit: 3694 Application/Control Number: 19/092,249 Page 5 Art Unit: 3694 Application/Control Number: 19/092,249 Page 6 Art Unit: 3694 Application/Control Number: 19/092,249 Page 7 Art Unit: 3694 Application/Control Number: 19/092,249 Page 8 Art Unit: 3694 Application/Control Number: 19/092,249 Page 9 Art Unit: 3694 Application/Control Number: 19/092,249 Page 10 Art Unit: 3694 Application/Control Number: 19/092,249 Page 11 Art Unit: 3694 Application/Control Number: 19/092,249 Page 12 Art Unit: 3694 Application/Control Number: 19/092,249 Page 13 Art Unit: 3694 Application/Control Number: 19/092,249 Page 14 Art Unit: 3694 Application/Control Number: 19/092,249 Page 15 Art Unit: 3694 Application/Control Number: 19/092,249 Page 16 Art Unit: 3694 Application/Control Number: 19/092,249 Page 17 Art Unit: 3694 Application/Control Number: 19/092,249 Page 18 Art Unit: 3694 Application/Control Number: 19/092,249 Page 19 Art Unit: 3694 Application/Control Number: 19/092,249 Page 20 Art Unit: 3694 Application/Control Number: 19/092,249 Page 21 Art Unit: 3694 Application/Control Number: 19/092,249 Page 22 Art Unit: 3694 Application/Control Number: 19/092,249 Page 23 Art Unit: 3694 Application/Control Number: 19/092,249 Page 24 Art Unit: 3694 Application/Control Number: 19/092,249 Page 25 Art Unit: 3694 Application/Control Number: 19/092,249 Page 26 Art Unit: 3694 Application/Control Number: 19/092,249 Page 27 Art Unit: 3694 Application/Control Number: 19/092,249 Page 28 Art Unit: 3694 Application/Control Number: 19/092,249 Page 29 Art Unit: 3694 Application/Control Number: 19/092,249 Page 30 Art Unit: 3694 Application/Control Number: 19/092,249 Page 31 Art Unit: 3694 Application/Control Number: 19/092,249 Page 32 Art Unit: 3694 Application/Control Number: 19/092,249 Page 33 Art Unit: 3694 Application/Control Number: 19/092,249 Page 34 Art Unit: 3694 1 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C). 2 “It should be noted that these groupings are not mutually exclusive, i.e., some claims recite limitations that fall within more than one grouping or sub-grouping. … Accordingly, examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings and proceed with the analysis in Step 2A Prong Two.” MPEP § 2106.04(a). 3 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.) , 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
Prosecution Insights