DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 9, 11, 13, 17 and 16 have been amended and are hereby entered.
Claims 5 and 6 were cancelled, while claims 21 was added.
Claims 1 - 4 and 7 - 21 are pending and have been examined.
This action is made FINAL.
Response to Arguments
Applicant's arguments filed July 23, 2025 have been fully considered but they are not persuasive.
Regarding the applicant's arguments against the 101 rejection of pending claims on pages 1-3: Applicant’s arguments directed to Step 2A prong 2 were considered. However, these arguments are not persuasive and the examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 2 starting in p. 2: The Applicant alleges that the claims integrate, the judicial exception identified, into a practical application because “the claims improve the functionality of a computer” by reducing “the computing resources required to assemble a time series of transactions related to a particular subject, such as a particular user, particular account, or particular property” and by having an “arrangement of tokens” that provides the technological solution to the technological problem. However, the Examiner finds these arguments unpersuasive and respectfully disagrees. Because the abstract ideas identified in the claims are not being integrated into a practical application or does not amount to significantly more than the judicial exception (e.g. abstract idea(s)) itself when considering the additional elements individually and in combination. Rather, the claim limitations invoked the use of a computer as a tool to perform an abstract idea (see MPEP 2106.04(d)(I) and MPEP 2106.05(f)). Thus, not providing an inventive concept at Step 2B. Therefore, these claims, contrary to Applicant assertions for using “pre-arrangement tokens (with inter-token pointers)” to “substantially pre-assembled in a lightweight form", the related transactions, does not reflect an improvement to the way the computer is working to specifically and distinctively detail how the computer achieve such computing resources reduction that can be significantly more than what other general computers can achieve. Rather, the claims broadly recites the generation of the tokens and their respective pointers for them to later be decoded which are performed by a computer that is recited in a high level of generality that fails to further specify and/or further limit how these limitations are different from generally “apply it” to a general purpose computer (see MPEP 2106.05(a)(I) and 2106.05(f)). Specifically, the limitations disclose common steps of “receiving” indications of user transactions (e.g. “electronic transactions”) to “generate” tokens per indication wherein each token is encoded and includes their respective “pointers” that refer to a storage location of each transaction. But also, after the common steps recited, claim 1 further recites “receiving” a time series “request” of the user transactions to further “decode” tokens and “retrieve” data pointers. Finally, claim 13, after reciting the common steps, further recites “initiating” a payment transaction according to the respective tokens. However, at least the steps for “generating” the tokens, are not further describing how the tokens are encoded by actively and positively reciting how the “encoding” function is achieved. Also, the Applicant’s disclosure does not provide more detail about this token generation and its encoding which is merely discloses the use of this function as instructions being applied. Thus, the claim steps further describe the end result for monitoring transaction tokens, generating a time series and initiate payment transactions without providing details on how this alleged “improvement” to the computer functioning and/or to the existing technology of “transaction data storage systems” is achieved.
Therefore, for all the reasons stated above, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 103 for the pending claims on pages 3 – 7: Applicant’s arguments regarding these amended limitation steps, specifically for the tokens that “comprise pointers to storage locations, as claimed” in the pending claims are not persuasive. Because at least the combination of Chalikwar and Liberman still teaches this storage locations comprising a memory address that the token’s pointers point to. Chalikwar teaches the tokens and the pointers as the “token identifiers (IDs)” or “Token IDs” that can be used to “locate and retrieve the corresponding the trusted offline payment token stored in the token database” (see ¶0041 – 42 and 48; Chalikwar), but does not explicitly teach the storage location specifically comprising a memory address that the pointers point per token. However, Liberman satisfies all the claims argued by the Applicant that recites such feature elements (see pp. 5 – 7 from Remarks) as the “messages may be stored at an identifiable memory address” wherein each of these messages have their own token generated (see ¶0238; Liberman). Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
Claim Rejections - 35 USC § 101
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 - 4 and 7 - 21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention recited in the claims begins in view of independent claims 1, 9 and 13, as follows:
At Step 1: Claims 1, 9 and 13 fall under statutory category of a process.
At Step 2A Prong 1: Claims 1, 9 and 13 recites an abstract idea, which are defined by the following underlined elements (e.g. functional steps) while omitting any hardware components (e.g. represented as “…”):
receiving…a plurality of indications of data representing a plurality of electronic transactions associated with a user;
generating…a plurality of tokens by generating, for each of the indications, wherein each token is encoded and:
a first token of the plurality of tokens comprises a pointer to a storage location of the data representing a first electronic transaction of the plurality of electronic transactions; and
each other token of the plurality of tokens comprises a respective pointer to a respective storage location of a respective electronic transaction of the plurality of electronic transactions and a respective pointer to a storage location of another one of the plurality of tokens;
receiving…a request for a time series of electronic transactions associated with the user;
in response to the request, generating…a time series of the plurality of electronic transactions by:
decoding the plurality of tokens; and
retrieving the plurality of data stored at the storage locations to which the pointers point.
For claim 9:
receiving…a first indication of first data respective of a first electronic transaction associated with a user;
generating…a first token, an encoded first token comprising a first pointer to a storage location of the first data;
receiving…a second indication of second data respective of a second electronic transaction associated with the user; and
generating an encoded second token, the second token comprising:
a second pointer to a storage location of the second data, and
a third pointer to a storage location of first token.
For claim 13:
receiving…indications of respective data of each of a plurality of electronic transactions associated with a user;
generating…a respective encoded token for each of the plurality of electronic transactions, the token comprising a respective pointer to a storage location of the data associated with the electronic transaction;
wherein at least one of the respective tokens additionally encodes a pointer to a storage location of one of the other tokens in the plurality of tokens; and
initiating a payment transaction according to the at least one of the respective tokens.
Generally, the claims’ limitations describe a method for receiving user transactions and their corresponding indications that are generated as tokens with encoded pointers to reference a time series of the user transactions and verify their corresponding past transactions. As disclosed in the specification in ¶0009 – 10, this invention allows the ability of “rapidly understand which related past transactions exist is a technical challenge” and includes “a solution for the storage of transaction data to enable quick later compilation of related transactions, including but not limited to a time series of related transactions.” However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) are recited in claims 1, 9 and 13 in the form of “commercial or legal interactions”. The limitations in each claim recite the common steps of “receiving” indications of user transactions (e.g. “electronic transactions”) to “generate” tokens per indication wherein each token is encoded and includes their respective “pointers” that refer to a storage location of each transaction. But also, after the common steps recited, claim 1 further recites “receiving” a time series “request” of the user transactions to further “decode” tokens and “retrieve” data pointers. Finally, claim 13, after reciting the common steps, further recites “initiating” a payment transaction according to the respective tokens. Thus, because all of these steps are reciting “electronic transactions” being tokenized to either create a “time series” by request or initiate “payment transactions” encompass commercial interactions in the form of marketing or sales activities or behaviors.
Step 2A Prong 2: For independent claims 1, 9 and 13, The judicial exception(s) or abstract idea previously identified is not integrated into a practical application (see MPEP 2106.04 (d)). The claims recite the additional element(s) of a computing system. These additional elements, individually and in combination, and while considering the claims as a whole, are merely used as a tool to perform the abstract idea (See MPEP 2106.05(f)). These element features of the computer and the tokenization and encoding functions are recited at a high level of generality and are performed generally to apply the abstract idea without placing any limits on how these steps are performed distinctively from generic computer components and general token generation and encoding data functions. Thus, each function is recited to generally “apply it” to a computer and to generally apply encoding and tokenization techniques. See MPEP 2106.05(f).
Moreover, the steps of “generating” respective “encoded token(s)” and claim 1’s step of “decoding” the tokens, even when actively and positively reciting the encoding function for the tokens, are also “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the encoding/decoding or tokenization techniques for the computer that encodes the tokens are broadly recited and lacks details on how this encoding/decoding is specifically performed in the tokens and simply is limited to encoding tokens that attempts to limit the use of the abstract idea to computer environments (see MPEP 2106.05(h) for example (x)). Therefore, this is indicative of the fact that the claim set has not integrated the abstract idea into a practical application and therefore, the claims are found to be directed to the abstract idea identified by the Examiner.
As for the “receiving”, “retrieving” and “initiating a payment transaction…” steps in the respective claims are really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)).
Step 2B: For independent claims 1, 9 and 13, these claims do not provide an inventive concept. The recited additional elements of the claim(s) are the following: a computing system. This additional element is not sufficient to amount significantly more than the judicial exception. Meaning, that there are no additional element(s) claimed in the dependent claims that could be significantly more than the judicial exception, but rather, further recites the abstract idea. As indicated in Step 2A Prong 2, the additional element(s) in the claims are merely, using a generic computer device or computing technologies and/or other machinery merely as a tool to perform an abstract idea that does not constitute a practical application and only amounts to a mere instruction to practice the invention. Thus, these elements do not render the claims as being eligible (refer to MPEP 2106.05(f) and 2106.05(h)). This is because the claimed invention must improve “upon conventional functioning of a computer, or upon conventional technology or technological processes a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art” (see MPEP 2106.05(a)). The rationale set forth for the 2nd prong of the eligibility test above is also applicable and re-evaluated in step 2B. Therefore, this rationale is sufficient for its rejection basis as it is not patent eligible and no comments are necessary as it is also consistent with the MPEP 2106.
For dependent claims 2 – 8, 10 – 12 and 13 – 20, these claims cover or fall under the same abstract idea of a method of organizing human activity. They describe additional limitations steps of:
Claims 2 – 4, 7 - 8, 10 – 12 and 13 – 20: further describes the abstract idea of the method for storing data respective of a time series of electronic transactions respective of a user and what type of transactions and records are being processed, the different tokens per transaction encoded with pointers to data located in a storage and decoded with their corresponding keys, the determination of requests based on the transaction and its status analysis to finally initiate a payment based on the request. Thus, being directed to the abstract idea group of “commercial or legal interactions” as it covers marketing or sales activities or behaviors.
Step 2A Prong 2 and Step 2B: For dependent claims 3 and 7, these claims recite the additional elements of: an electronic transaction system (from claim 3) and an automated customer service system (from claim 7). These additional elements recited are invoking computers merely used as a tool to perform or “apply” the abstract idea(s) to the existing process of generating encoded tokens from electronic transactions to initiate payment transactions or generate time series of these transactions. which are also recited to be merely used as a tool to perform the abstract idea to process electronic transactions and offer user assistance. Thus, it amounts no more than mere instructions to apply the exception using a generic computer component (MPEP 2106.05(f)). Therefore, these claim limitations amount to no more than mere instructions to apply the exception using generic computer components and or computing technologies (e.g. that are merely deployed to be used as a tool; see MPEP 2106.05 (f)).
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
Claim Rejections - 35 USC § 103
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.
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.
Claims 9, 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Chalikwar (U.S. Pub No. 20210365932 A1) in view of Liberman (U.S. Pub No. 20190355059 A1).
Regarding claim 9:
Chalikwar teaches:
receiving, by a computing system, a first indication of first data respective of a first electronic transaction associated with a user; (In ¶0041; Fig. 2A (218 – 220); Fig. 4A (405): teaches “At label 220, Trusted Token Repository 210 may receive from Requestor Institution 206 the token request along with pertinent parameters” (see ¶0040 and ¶0047 for details of parameters that involve different types of transaction data) which is directed to a first indication of data in accordance to ¶0049 – 50 from applicant specs.)
generating, by the computing system, an encoded first token, the first token comprising a first pointer to a storage location of the first data; (In ¶0041; Fig. 2A (220 – 222); Fig. 2B (246); Figs. 3A – 3B; Fig. 4A (415): teaches that “based on the token request and accompanying parameters, Trusted Token Repository 210 may generate a trusted offline payment token, including a token identifier (ID) corresponding to the particular token” which is in the form of a “barcode, QR code or Random code” (see Fig. 3A – 3B, ¶0049 – 52 and ¶0068) and is stored in a “secure token database maintained by (or on behalf of) Trusted Token Repository 210” which is directed to the encoded first token with a first pointer to a storage location of the first data, in accordance to ¶0022 – 23 from applicant specs. Refer to ¶0047 – 48 for more details about token verification and to ¶0067 and ¶0075 for token encoding details.)
receiving, by the computing system, a second indication of second data respective of a second electronic transaction associated with the user; and generating an encoded second token, the second token comprising: a second pointer to a storage location of the second data, and... (In ¶0041; Fig. 2A (218 – 222); Fig. 2B (246); Figs. 3A – 3B; Fig. 4A (405 – 415): teaches under the broadest reasonable interpretation (BRI), that the system can receive a first and a second indication to create their corresponding token IDs for each type of transaction for a same user such as a “withdrawal or a transfer of cash” (directed to a first and second transaction for the generation of a first and second token) to either a person or an institution (see ¶0006, ¶0022 and ¶0035). Thus, these limitations are satisfied and taught as “Trusted Token Repository 210” receiving from “Requestor Institution 206 the token request along with pertinent parameters” and “based on the token request and accompanying parameters, Trusted Token Repository 210 may generate a trusted offline payment token, including a token identifier (ID) corresponding to the particular token” which is encoded in the form of a “barcode, QR code or Random code” and is directed to the encoded first and second pointers (see ¶0067 and ¶0075 for token encoding details).)
Chalikwar does not explicitly teach the ability of specifically having a second token that includes a third pointer to a storage location of the first token. However, Liberman teaches:
…the second token comprising: …a third pointer to a storage location of the first token. (In ¶0242; Fig. 6A – 6C (604, 606 and 640): teaches, under BRI, that “Broker 630 uses the token management system to generate extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999” wherein the system further “augments orders 640, 641, 642, 643, . . . 1639 with extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999, respectively” (directed to each token per transaction). But more specifically, “PB/0/0/0 label” includes encrypted information and “electronic data transaction result message FM1” (see ¶0267) directed to the third pointer of the second token for “order 640” wherein “entities 602 and 612 would accordingly search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” directed to the third indication of data pointing to the first token of order 604 (see ¶0268). Refer, to ¶0241 – 243 and Fig. 6A, wherein “order 640” is considered a subset of “order 606” and “order 606, which is a subset of, or an order based on, order 604” that may be “an order to purchase 1 million shares of the financial instrument AAPL” directed to an electronic transaction, in accordance to ¶0048 and ¶0052 from applicant specs.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the ability of specifically having a second token that includes a third pointer to a storage location of the first token, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Regarding claim 13:
Chalikwar teaches:
receiving, by a computing system, indications of respective data of each of a plurality of electronic transactions associated with a user; (In ¶0041; Fig. 2A (218 – 220); Fig. 4A (405): teaches “At label 220, Trusted Token Repository 210 may receive from Requestor Institution 206 the token request along with pertinent parameters” (see ¶0040 and ¶0047 for details of parameters that involve different types of transaction data) which is directed to indications of data in accordance to ¶0049 – 50 from applicant specs.)
generating, by the computing system, a respective encoded token for each of the plurality of electronic transactions, the token comprising a respective pointer to a storage location of the data associated with the electronic transaction; (In ¶0041; Fig. 2A (220 – 222); Fig. 2B (246); Figs. 3A – 3B; Fig. 4A (415): teaches that “based on the token request and accompanying parameters, Trusted Token Repository 210 may generate a trusted offline payment token, including a token identifier (ID) corresponding to the particular token” which is in the form of a “barcode, QR code or Random code” (see Fig. 3A – 3B, ¶0049 – 52 and ¶0068) and is stored in a “secure token database maintained by (or on behalf of) Trusted Token Repository 210” which is directed to encoding the respective token with a pointer to a storage location of the electronic transaction data, in accordance to ¶0022 – 23 from applicant specs. Refer to ¶0047 – 48 for more details about token verification, to ¶0067 and ¶0075 for token encoding details.)
initiating a payment transaction according to the at least one of the respective tokens. (In ¶0052 – 53; Fig. 2B (256): teaches that “Trusted Token Repository 210 may also initiate a payment settlement process to transfer funds equal to the token amount for the consumed token from Requestor Institution 206 to Recipient Institution 208” and at “label 256, as a payment settlement process Requestor Institution 206 may initiate payment to Recipient Institution 208 of funds equal to the token amount for the consumed trusted offline payment token”.)
Chalikwar does not explicitly teach the ability of specifically having tokens that additionally encodes a pointer to a storage location of one of the other tokens. However, Liberman teaches:
wherein at least one of the respective tokens additionally encodes a pointer to a storage location of one of the other tokens in the plurality of tokens; and (In ¶0242; Fig. 6A – 6C (604, 606 and 640): teaches, under BRI, that “Broker 630 uses the token management system to generate extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999” wherein the system further “augments orders 640, 641, 642, 643, . . . 1639 with extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999, respectively” (directed to each token per transaction). But more specifically, “PB/0/0/0 label” includes encrypted information and “electronic data transaction result message FM1” (see ¶0267) directed to the third pointer of the second token for “order 640” wherein “entities 602 and 612 would accordingly search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” which is directed to an additional encoded pointer included in another token such as to a first token of order 604 (see ¶0268), in accordance to ¶0026 – 27 and ¶0035. Refer, to ¶0241 – 243 and Fig. 6A, wherein “order 640” is considered a subset of “order 606” and “order 606, which is a subset of, or an order based on, order 604” that may be “an order to purchase 1 million shares of the financial instrument AAPL” to an electronic transaction, in accordance to ¶0048 and ¶0052 from applicant specs.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the ability of specifically having tokens that additionally encodes a pointer to one of the other tokens, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Regarding claim 18:
The combination of Chalikwar and Liberman, as shown in the rejection above, discloses the limitations of claim 13.
Chalikwar further teaches:
wherein the payment transaction is not one of the plurality of electronic transactions. (In ¶0035 – 36: teaches, under BRI, that “a withdrawal or transfer of cash” may be initiated by a user by personally visiting “a facility operated by Requestor Institution 206” which is directed to a payment that is a non-electronic transaction and is none of the electronic transactions disclosed in ¶0048 and ¶0052 from applicant specs.)
Claims 1 - 4, 7 - 8 and 10 - 12, 14 - 17 and 19 - 21 are rejected under 35 U.S.C. 103 as being unpatentable over Chalikwar (U.S. Pub No. 20210365932 A1) in view of Liberman (U.S. Pub No. 20190355059 A1) in further view of McHugh (U.S. Pub No. 20210042742 A1).
Regarding claim 1:
Chalikwar teaches:
receiving, by a computing system, a plurality of indications of data representing a plurality of electronic transactions associated with a user; (In ¶0041; Fig. 2A (218 – 220); Fig. 4A (405): teaches “At label 220, Trusted Token Repository 210 may receive from Requestor Institution 206 the token request along with pertinent parameters” (see ¶0040 and ¶0047 for details of parameters that involve different types of transaction data) which is directed to indications of data in accordance to ¶0049 – 50 from applicant specs.)
generating, by the computing system, a plurality of tokens by generating, for each of the indications, a respective token, wherein each token is encoded and: a first token of the plurality of tokens comprises a pointer to a storage location of the data representing a first electronic transaction of the plurality of electronic transactions; and each other token of the plurality of tokens comprises a respective pointer to a respective storage location of a respective electronic transaction of the plurality of electronic transactions… (In ¶0041; Fig. 2A (220 – 222); Fig. 2B (246); Figs. 3A – 3B; Fig. 4A (415): teaches that “based on the token request and accompanying parameters, Trusted Token Repository 210 may generate a trusted offline payment token, including a token identifier (ID) corresponding to the particular token” which is in the form of a “barcode, QR code or Random code” (see Fig. 3A – 3B, ¶0049 – 52 and ¶0068) and is stored in a “secure token database maintained by (or on behalf of) Trusted Token Repository 210” which is directed to generating encoded tokens with their respective pointers to a storage location, in accordance to ¶0022 – 23 from Applicant specs. Refer to ¶0047 – 48 for more details about token verification and to ¶0067 and ¶0075 for token encoding details.)
Chalikwar does not explicitly teach the ability of specifically having a respective pointer to a storage location of another token from the plurality of tokens. However, Liberman teaches:
…and a respective pointer to a storage location of another one of the plurality of tokens; (In ¶0242; Fig. 6A – 6C (604, 606 and 640): teaches, under BRI, that “Broker 630 uses the token management system to generate extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999” wherein the system further “augments orders 640, 641, 642, 643, . . . 1639 with extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999, respectively” (directed to each token per transaction). But more specifically, “PB/0/0/0 label” includes encrypted information and “electronic data transaction result message FM1” (see ¶0267) directed to the third pointer of the second token for “order 640” wherein “entities 602 and 612 would accordingly search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” which is directed to an additional encoded pointer included in another token such as to a first token of order 604 (see ¶0268), in accordance to ¶0026 – 27 and ¶0035. Refer, to ¶0241 – 243 and Fig. 6A, wherein “order 640” is considered a subset of “order 606” and “order 606, which is a subset of, or an order based on, order 604” that may be “an order to purchase 1 million shares of the financial instrument AAPL” to an electronic transaction, in accordance to ¶0048 and ¶0052 from applicant specs.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the ability of specifically having a respective pointer to a storage location of another token from the plurality of tokens, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Neither Chalikwar or Liberman does not explicitly teach the abilities of receiving a request for a time series of electronic transactions for a user to generate it by decoding the tokens and retrieving their respective data pointers. However, McHugh teaches:
receiving, by the computing system, a request for a time series of electronic transactions associated with the user; (In ¶0060; Fig. 4 (402): teaches that in order “to retrieve a token history for tokens used by one or more external systems, local vault 106 may receive a query request for retrieving token history for tokens used by one or more external systems” that in response data is provided such as “all of the events pertaining to the token of each external system including information such as event reason, event requestor, event type, message reason code, message type, token type, and other relevant information” which can be modified and processed to generate a time-series token data as an analytical model via a “message from a financial network” for an “account holder” (see Fig.4 (402) and ¶0062 – 63 for more details).)
in response to the request, generating, by the computing system, a time series of the plurality of electronic transactions by: decoding the plurality of tokens; and retrieving the plurality of data stored at the storage locations to which the pointers point. (In ¶0066 – 67; Fig.4 (404 – 412): teaches that in “operation 404, an analyze engine may extract the token and the metadata from each of the messages” by reading the “messages and parse the message to detect and extract token and metadata from the messages” (directed to decoding the tokens since the metadata extracted includes “secure element identifier, account hash” and “reason code”; see ¶0062 – 63). Later, in operations 410 – 412 from this processing method, “a time-series capture engine may capture the time-series token data for the token based on the metadata” and a “modeling engine may generate an analytical model using the time-series data” to “detect events such as fraud or suspicious activity detection” or to be used in “predictive algorithms for forecast events”.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the abilities of receiving a request for a time series of electronic transactions for a user to generate it by decoding the tokens and retrieving their respective data pointers, as taught by McHugh in order to “detect events such as fraud or suspicious activity detection” or to be used in “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claim 2:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
Chalikwar further teaches:
wherein the plurality of electronic transactions comprise electronic events associated with the user. (In ¶0034 – 35; Fig. 2A – 2C: teaches that “Process flow 200 includes interactions between and among various entities, including Requestor User 202, Requestor Institution 206, and Trusted Token Repository 210” wherein “Requestor User 202 may be User_1 101 or User_2 102 and may interact with other entities via network 120” and “Requestor Institution 206 may be Institution_A 104 or Institution_B 106 and may interact with other entities via network 120” wherein such interaction is related to “obtain a trusted offline payment token for a withdrawal or transfer of cash” via “using a client device via network 120” to access “an online account with Requestor Institution 206” directed to electronic events, in accordance to ¶0012 from applicant specs.)
Regarding claim 3:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 2.
Chalikwar further teaches:
wherein the electronic events comprise one or more of: an interaction between a user and an electronic transaction system; (In ¶0036; Fig. 2A – 2C: teaches “if accessing an online account with Requestor Institution 206, Requestor User 202 may be required to provide an online user ID and password at login, such that the identity of Requestor User 202 may be verified by Requestor Institution 206 for any activity carried out during the online session”.)
an interaction between the electronic transaction system and a third-party system; or a processing operation by the electronic transaction system. (In ¶0043; Fig. 2A – 2C: teaches “At label 224, Requestor Institution 206 may have received from Trusted Token Repository 210 the token ID corresponding to the trusted offline payment token generated in response to the token request sent by Requestor Institution 206” in response to “Requestor Institution 206” sending a “token request for a trusted offline payment token, along with parameters pertinent to the token” to a “Trusted Token Repository 210” (see ¶0040), directed to “a third party file system”, in accordance to ¶0012 from applicant specs. Refer to ¶0049 – 53 for more interactions between “Recipient Institution 208” and “Trusted Token Repository 210” to approve a “payment of the token amount to Requestor User 202” in which further “a payment settlement process Requestor Institution 206 may initiate payment to Recipient Institution 208 of funds equal to the token amount for the consumed trusted offline payment token” directed to another third-party system.)
Regarding claim 4:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
Chalikwar further teaches:
wherein the plurality of data comprise electronic records of data of the transaction. (In ¶0068; Fig. 3B: teaches that each transaction and its generated token (see ¶0041) includes electronic data records directed to “data elements such as Token ID 322, Requestor User ID 324, Requestor Institution ID 326, Recipient Institution ID 328, Recipient Institution Branch 330, Institution Key 332, Token $$ Amount 334, Recipient Name 336, and Valid Period/Expiration 338. Token ID 322 may include the unique numeric or alphanumeric code to assigned to token and/or may include the encoded form, as described above with reference to FIG. 3A”.)
Regarding claim 7:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
Neither Chalikwar or Liberman does not explicitly teach the abilities of generating a time series in response to a customer service request submitted by the user and offer assistance to the user according to the generated time-series. However, McHugh further teaches:
wherein: the time series is generated in response to a customer service request submitted by the user to an automated customer service system associated with the computing system; and (In ¶0058; Fig. 3 (301): teaches that in operations 302 to 308 for the “system for capturing time-series token data” (see ¶0051), a “user (i.e., account holder) 300 may create/delete/update a token for a payment device” wherein such message is detected (see ¶0052 – 53) and received “by the messaging system 114” to “call the token customer service to update or add the token for the account holder's payment device” wherein the “Token customer service may be a hub for managing network tokens provided by financial networks” which is directed to an automated customer service system.)
the computer-implemented method further comprises offering assistance to the user, by the automated customer service system, according to the generated time series. (In ¶0073; Fig. 2; Fig. 3 (308); Fig. 4 (412); Fig. 5 (510): teaches under the broadest reasonable interpretation (BRI) for offering user assistance, that in “operation 510, a local vault interface may generate GUIs for managing an account holder's token information” wherein “account holder may also use the local vault interface to add a token, retrieve all tokens, retrieve a token for a specified external system, or retrieve token history for one or more external systems”. Also, in ¶0060 the “local vault 106 may receive a query request for retrieving token history for tokens used by one or more external systems” wherein the “response from local vault 106 may include all of the events pertaining to the token of each external system” which is directed to offering user assistance based on the request. Refer to Fig. 2 and ¶0048 – 50 wherein the user can select the option of “Pay help” directed to offering user assistance)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the abilities of generating a time series in response to a customer service request submitted by the user and offer assistance to the user according to the generated time-series, as taught by McHugh in order to allow “for maintaining all of an account holder's token information in a central location” which “may eliminate having to repeatedly make a call to an API of a financial network to retrieve token data for a payment device for various external systems” that is further “cumbersome and computationally expensive process” and “the system for capturing time-series token data may solve the technical problem of reducing the calls to an API of a financial network for retrieving token data for a payment device, and in-turn may reduce the amount of computational resources necessary to manage and store token data.” (¶0014; McHugh).
Regarding claim 8:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 7.
Neither Chalikwar or Liberman does not explicitly teach the ability of specifically analyzing the generated time series to identify pending transaction and provide a status of the pending transaction based on offering user assistance and in accordance to the corresponding time series generated for the user. However, McHugh further teaches:
wherein offering the user assistance according to the generated time series comprises one or more of: determining an intent of the customer service request; analyzing the generated time series to identify an incomplete transaction and, in response, offering assistance to the user with the incomplete transaction; or analyzing the time series to identify a pending transaction and, in response, provide a status of the pending transaction. (In ¶0060; Fig. 2; Fig. 3 (308); Fig. 4 (412); Fig. 5 (510): teaches, under the broadest reasonable interpretation (BRI), this conditional limitation as being directed to “retrieve a token history for tokens used by one or more external systems, local vault 106 may receive a query request for retrieving token history for tokens used by one or more external systems” wherein the “response from local vault 106 may include all of the events pertaining to the token of each external system including information such as event reason, event requestor, event type, message reason code, message type, token type, and other relevant information. The events may be creation, modification, suspension, deactivation, deletion or other actions affecting the token used by an external system” directed to providing a status in response to analyzing the time series to identify pending transactions. See ¶0063 – 67 for more details regarding token analysis and prediction based on time-series data and respective status received.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of specifically analyzing the generated time series to identify pending transaction and provide a status of the pending transaction based on offering user assistance and in accordance to the corresponding time series generated for the user, as taught by McHugh in order to allow “for maintaining all of an account holder's token information in a central location” which “may eliminate having to repeatedly make a call to an API of a financial network to retrieve token data for a payment device for various external systems” that is further “cumbersome and computationally expensive process” and “the system for capturing time-series token data may solve the technical problem of reducing the calls to an API of a financial network for retrieving token data for a payment device, and in-turn may reduce the amount of computational resources necessary to manage and store token data.” (¶0014; McHugh).
Regarding claims 10 and 12:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claims 10 and 11, respectively.
This claim set is represented by claim 12
Chalikwar teaches the encryption and decryption of tokens (see ¶0069; Chalikwar). But neither Chalikwar or Liberman explicitly teach the ability of generating a time series that have different transactions with the first token, the second token and third token decoded. However, McHugh further teaches:
further comprising: generating, by the computing system, a time series comprising the first electronic transaction, the second electronic transaction, and the third electronic transaction by decoding the first token, the second token, and the third token. (In ¶0040: teaches that the “Time-series engine 108 may capture time-series data and generate a time-series model detailing all of the account holder's tokens and events executed with the respective tokens” which is directed to the first token, the second token, and the third token decoded. Also, “a time-series model may illustrate events such as creation of an token at an external system 110, use of the token by the external system 110 to execute a transaction, deletion of the token, suspension of the token, modification of the token, and use of the token, over a snapshot in time.”)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of generating a time series that have different transactions with the first token, the second token and third token decoded, as taught by McHugh as it would be obvious to try to have tokens decoded in order to “detect events such as fraud or suspicious activity detection” or to use the system and its time-series modelling for “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claims 11 and 17:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claims 10 and 16, respectively.
Chalikwar teaches the receiving two different indications for a “withdrawal or a transfer of cash” to generate their tokens and their corresponding token IDs which is directed to a first and second transaction for the generation of a first and second tokens (see ¶0041, ¶0022 and ¶0035; Chalikwar). However, Chalikwar does not explicitly teach the abilities of specifically receiving a third indication for a third electronic transaction to generate a third token with a fourth pointer encoded and a fifth pointer referring to a second token. However, Liberman further teaches:
further comprising: receiving, by the computing system, a third indication of third data respective of a third electronic transaction associated with the user; and generating a third token, the third token comprising: a fourth pointer to a storage location of the third data, and… (In ¶0238: teaches under the broadest reasonable interpretation (BRI) that the system “generate tokens for financial messages based on extended private-public key pairs, which are transmitted downstream, and associate, based on the tokens, financial messages to each other that are otherwise unrelated” wherein “decryption may be based on the tokens used to identify/associated financial messages to each other” directed to a third electronic transaction such as trading transactions. Moreover, “token management system augments a financial message with a token that stays with, i.e., is a part of, the financial message through the life of the financial message, e.g., as the financial message is broken up into a plurality of additional financial messages, and as those plurality of financial messages are ultimately traded on one or more exchange computing systems, and as those exchange computing systems generate additional messages, e.g., reporting messages, whether private/direct or public, responsive to the financial messages” which is directed to a fourth pointer that is searched via extended public keys (see ¶0245 – 246 and ¶0250).)
the third token encoding…a fifth pointer to a storage location of the second token. (In ¶0268; Fig. 6A – 6D: teaches under BRI, that “the token management system on the fund managers 602's computer transmits orders 606, 608 and 610, augmented with extended public keys PB/O, PB/1, and PB/2, respectively” (specifically order 608 with PB/1 key directed to the second token) that further “generates, and searches market data feeds for reporting messages including, tokens derived from PB/1, e.g., PB/I/O, PB/1/1, PB/1/2, PB/1/3, PB/1/4” and “any order reporting messages that include any of the extended public keys based on PB can be collected and grouped by fund manager 602 as being an order for financial instrument AAPL that was originated with the fund manager 602” so the “the process of execution of the order 604, no matter how that order is divided/anonymized by fund manager 602 or any of the parties downstream of fund manager 602” can be observed and searched, thus, being directed to the fifth pointer that points to the storage location of the second token.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the abilities of specifically receiving a third indication for a third electronic transaction to generate a third token with a fourth pointer encoded and a fifth pointer referring to a second token, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Regarding claim 14:
The combination of Chalikwar and Liberman, as shown in the rejection above, discloses the limitations of claim 13.
Chalikwar teaches the encryption and decryption of tokens (see ¶0069; Chalikwar). But neither Chalikwar or Liberman explicitly teach the ability of generating a time series that have different transactions with respective tokens decoded. However, McHugh further teaches:
further comprising: generating, by the computing system, a time series of the plurality of electronic transactions by decoding the tokens. ((In ¶0040: teaches that the “Time-series engine 108 may capture time-series data and generate a time-series model detailing all of the account holder's tokens and events executed with the respective tokens” which is directed to the first token, the second token, and the third token decoded. Also, “a time-series model may illustrate events such as creation of an token at an external system 110, use of the token by the external system 110 to execute a transaction, deletion of the token, suspension of the token, modification of the token, and use of the token, over a snapshot in time.”)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of generating a time series that have different transactions with respective tokens decoded, as taught by McHugh as it would be obvious to try to have tokens decoded in order to “detect events such as fraud or suspicious activity detection” or to use the system and its time-series modelling for “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claim 15:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 14.
Neither Chalikwar or Liberman explicitly teach the ability of initiating a payment transaction based on a time series request. However, McHugh further teaches:
wherein the payment transaction is initiated based on a request for the time series. (In ¶0040: teaches under the broadest reasonable interpretation (BRI), “a time-series model may illustrate events such as creation of an token at an external system 110, use of the token by the external system 110 to execute a transaction, deletion of the token, suspension of the token, modification of the token, and use of the token, over a snapshot in time.” Also, to “retrieve a token history for tokens used by one or more external systems, local vault 106 may receive a query request for retrieving token history for tokens used by one or more external systems.” (see ¶0060))
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of initiating a payment transaction based on a time series request as taught by McHugh as it would be obvious to try to have tokens decoded in order to “detect events such as fraud or suspicious activity detection” or to use the system and its time-series modelling for “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claim 16:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 14.
Chalikwar further teaches:
wherein: the plurality of electronic transactions comprise a first electronic transaction and a second electronic transaction, and (In ¶0034 – 35; Fig. 2A – 2C: teaches that “Process flow 200 includes interactions between and among various entities, including Requestor User 202, Requestor Institution 206, and Trusted Token Repository 210” wherein such interactions is related to “obtain a trusted offline payment token for a withdrawal or transfer of cash” directed to a first and second transaction.)
the respective tokens comprise: a first token, the first token comprising a first pointer to a storage location of first data associated with the first electronic transaction; and a second token, the second token comprising: a second pointer to a storage location of second data associated with the second electronic transaction, and… (In ¶0041; Fig. 2A (218 – 222); Fig. 2B (246); Figs. 3A – 3B; Fig. 4A (405 – 415): teaches under the broadest reasonable interpretation (BRI), that the system can receive a first and a second indication to create their corresponding token IDs for each type of transaction for a same user such as a “withdrawal or a transfer of cash” (directed to a first and second transaction for the generation of a first and second token) to either a person or an institution (see ¶0006, ¶0022 and ¶0035). Thus, these limitations are satisfied and taught as “Trusted Token Repository 210” receiving from “Requestor Institution 206 the token request along with pertinent parameters” and “based on the token request and accompanying parameters, Trusted Token Repository 210 may generate a trusted offline payment token, including a token identifier (ID) corresponding to the particular token” which is encoded in the form of a “barcode, QR code or Random code” and is directed to the first and second pointers (see ¶0067 and ¶0075 for token encoding details).)
Chalikwar does not explicitly teach the ability of specifically having a second token encoding a third pointer to the first token. However, Liberman further teaches:
second token encoding: …a third pointer to a storage location of the first token. (In ¶0242; Fig. 6A – 6C (604, 606 and 640): teaches, under BRI, that “Broker 630 uses the token management system to generate extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999” wherein the system further “augments orders 640, 641, 642, 643, . . . 1639 with extended public keys PB/0/0/0, PB/0/0/1, PB/0/0/2, PB/0/0/3, . . . PB/0/0/999, respectively” (directed to each token per transaction). But more specifically, “PB/0/0/0 label” includes encrypted information and “electronic data transaction result message FM1” (see ¶0267) directed to the third pointer of the second token for “order 640” wherein “entities 602 and 612 would accordingly search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” directed to the third indication of data pointing to the first token of order 604 (see ¶0268). Refer, to ¶0241 – 243 and Fig. 6A, wherein “order 640” is considered a subset of “order 606” and “order 606, which is a subset of, or an order based on, order 604” that may be “an order to purchase 1 million shares of the financial instrument AAPL” directed to an electronic transaction, in accordance to ¶0048 and ¶0052 from applicant specs.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the ability of specifically having a second token encoding a third pointer to the first token, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Regarding claim 19:
The combination of Chalikwar and Liberman, as shown in the rejection above, discloses the limitations of claim 13.
Chalikwar teaches payment transactions to “Recipient Institution 208 of funds equal to the token amount for the consumed trusted offline payment token” (see ¶0063 – 64; Chalikwar). Specifically, for withdrawing or transferring cash (see ¶0068). However, neither Chalikwar or Liberman explicitly teach the ability of having a payment transaction specifically, a payment from a user to a merchant. Thus, McHugh further teaches:
wherein the payment transaction comprises a payment from the user to a merchant. (In ¶0081: teaches under the broadest reasonable interpretation (BRI), that “a financial institution hosting messaging system 114 and data capture system 100 may issue a payment device to an account holder” wherein “account holder may use the payment device at various external systems 110” that “may be a retailer or service provider which stores and process payment devices (e.g., credit cards, debit cards, pre-paid debit cards, gift cards, or the like) in response to the account holder providing the payment device information and executing an event (e.g., sale, return, addition of payment device, deletion of payment device, deletion of an account, modification of the account or payment device, or the like) with the payment device using interface 118 of external system 110” .)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of having a payment transaction specifically, a payment from a user to a merchant, as taught by McHugh as it would be obvious to try to have payment transactions between users and merchants in order to “detect events such as fraud or suspicious activity detection” or to use the system and its time-series modelling for “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claim 20:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 19.
Chalikwar teaches payment transactions to “Recipient Institution 208 of funds equal to the token amount for the consumed trusted offline payment token” (see ¶0063 – 64; Chalikwar). Specifically, for withdrawing or transferring cash (see ¶0068). However, neither Chalikwar or Liberman explicitly teach the ability of having a payment transaction specifically, initiated in response to a merchant request. Thus, McHugh further teaches:
wherein the payment transaction is initiated in response to a request from a merchant. (In ¶0043 – 44: teaches under the broadest reasonable interpretation (BRI), that “external system 110 may be a retailers and an account holder may use interface 118 of external system 110 to purchase retail items using the account holder's payment device. The attempt to purchase retail items using the payment device may be an event” wherein, “to process the sale, external system 11 may generate and transmit a message to financial network 150” which “may transmit a message to message system 114 hosted by the financial institution configured to process the payment of the sale” which is directed to a payment transaction initiated in response to a request from a merchant.)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar with Liberman to provide the ability of having a payment transaction specifically, initiated in response to a merchant request, as taught by McHugh as it would be obvious to try to have payment transactions initiated in response to a merchant request in order to “detect events such as fraud or suspicious activity detection” or to use the system and its time-series modelling for “predictive algorithms for forecast events” (¶0067; McHugh).
Regarding claim 21:
The combination of Chalikwar, Liberman and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
Chalikwar teaches the storage of “generated trusted offline payment token in a secure token database” that include “Token IDs” which are “sufficient to uniquely identify the token and to carry out any transfer and consumption of the token”, but also can be used to “locate and retrieve the corresponding the trusted offline payment token stored in the token database” by matching requested “parameters” with the data (see ¶0041 – 42 and 48; Chalikwar). However, Chalikwar does not explicitly teach the storage location specifically comprising a memory address that the pointers point per token. However, Liberman further teaches:
wherein each storage location comprises a respective memory address. (In ¶0184: teaches that “Incoming messages may be stored at an identifiable memory address” wherein each of these messages have their own token generated (see ¶0238) and these messages are related to money transactions or “order” (see ¶0031 for invention overview).)
It would have been obvious to one of ordinary skill in the art before the earliest effective filing date of the claimed invention to modify Chalikwar to provide the storage location, specifically comprising a memory address that the pointers point per token, as taught by Liberman in order to generally enable “each party routing orders or executing trades may add fees to the cost of execution. This fee information, likewise, needs to be reported upstream so that parties can be paid, and so that the fund can account for the parties as an expense. Or, a party routing orders or executing trades may generate some other confidential information, e.g., only intended to be read/viewed by a few parties, and not everyone who has access to the financial message database” and for “a fund manager [that] may not receive information about all of their orders/sub-orders in a timely manner, leaving the fund manager without critical financial information.” (¶0237; Liberman). But more specifically, to enable “entities 602 and 612” to “search the data source 650 for financial messages having the PB/0/0/0 label, and be able to associate such financial messages with their orders 606 and 620, respectively” (¶0268; Liberman).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen (U.S. Pub No. 20220138719 A1) is pertinent because it “relates generally to methods, systems, and products for providing installment payment options and, in some particular embodiments, to a method, system, and computer program product for providing installment payment options for a payment transaction using a consumer device.”
Peterson (U.S. Patent No. 10402808 B1) is pertinent because it “relates generally to the field of secure network transactions and, more particularly, to systems and methods for utilizing low-value tokens to generate high-value tokens.”
Shah (U.S. Pub No. 20050137969 A1) is pertinent because it “relates to financial transactions. More specifically, the invention relates to a method for improving the security and integrity of financial transactions, such as transactions executed by mutual fund companies.”
Ling (WO Pub No. 2019192785 A1) is pertinent because it is “a transaction terminal system that includes storage circuitry to store information that is indicative of a terminal system currency of the transaction terminal system”
Kizhakayil (U.S. Pub No. 20230206335 A1) is pertinent because it “generally relate to methods and systems for controlled propagation and distribution of secure electronic tokens that include data representative of values of financial instruments.”
Wall (U.S. Pub No. 20210027297 A1) is pertinent because it is “a method and apparatus for processing a transaction between a merchant system and a customer system, the customer system associated with a customer of the merchant”
Badenhorst (U.S. Pub No. 20150363781 A1) is pertinent because it “intend[s] to simplify loyalty reward mechanisms by providing a single-use token which contains payment credentials and a static consumer loyalty identifier.”
Ortiz (U.S. Pub No. 20160019536 A1) is pertinent because it “relates generally to systems, methods, and machine-interpretable programming and/or other instruction products for the secure processing of data. In particular, the disclosure relates to the secure creation, administration, manipulation, processing, and storage of electronic data useful in processing of payment transactions and other data processes, using secure identifiers, payment elements such as virtual wallets and payment tokens, and other devices and processes.”
Badal-Badalian (CA Pub No. 3122951 A1) is pertinent because it is “a system for processing electronic transactions. The system comprises at least one processor and a memory storing instructions which when executed by the processor configure the processor to obtain device information, generate a credential token based on the device information, and process an electronic transaction using the credential token.”
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ivonnemary Rivera Gonzalez whose telephone number is (571)272-6158. The examiner can normally be reached Mon - Fri 9:00AM - 5:30PM.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/IVONNEMARY RIVERA GONZALEZ/Examiner, Art Unit 3626
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights