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 .
In view of the appeal brief filed on April 13, 2026, PROSECUTION IS HEREBY REOPENED. new grounds of rejections are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/NATHAN C UBER/ Supervisory Patent Examiner, Art Unit 3626
Status of Claims
Claims 5 and 6 were cancelled, while claims 21 was added.
Claims 1 - 4 and 7 - 21 are pending and have been re-examined.
In light of the Appeal Conference decision for Appeal Brief filed on April 13, 2026, this case have been re-opened.
This action is made a NON-FINAL.
Response to Arguments
Appellant’s arguments filed April 13, 2026 have been fully considered but they are not persuasive.
Regarding the Appellant's arguments against the 101 rejection of pending claims on pages 8 – 13: 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 1 starting in p. 8: Appellant argues in p.9 that the claims 1, 9 and 13 are not reciting the abstract idea of a “method of organizing human activity” in the form of “commercial or legal interactions” as “marketing or sales activities or behaviors” because “data that is processed and stored in respective storage locations using the encoded token mechanism is merely representative of electronic transactions (e.g., series of transactions associated with a user)”. However, the Examiner respectfully disagrees and find these arguments unpersuasive because the claim limitations recited are directed in part to “generate” a “time series of the plurality of electronic transactions” (from claims 1 and 9) that are derived from “receiving” their respective “indications of data” to “generate” tokens per indication and transaction and “decode” the tokens to “retrieve” the data stored in the token that includes a “pointer to a respective storage location of a respective electronic transaction” (from claims 1, 9 and 13) and to further “initiate” a payment transaction according to the respective tokens (from claim 13). Thus, according to the MPEP 2106.04 (II)(A)(1), the Examiner analyzed and determined what the “applicant has invented by reviewing the entire application disclosure and construing the claims in accordance with their broadest reasonable interpretation (BRI)”. Further, the claim language was determined based on the condition that each claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim (see MPEP 2106.04, subsection II). Thus, the Examiner closely examined all claim limitations individually and as a whole, and found that the steps fall under a certain method of organizing human activity. This is because the end result that the claim limitations recite, is to “initiate” payment transactions based on the generation of the “time series of the plurality of electronic transactions” that are further derived from the generated “tokens” and their respective “storage location pointers” which involves commercial interactions related to “marketing or sales activities or behaviors”. Further, the claimed invention allows to “respond to a service request regarding that user, account, or property in a live support scenario” when using the generated “a time series of transactions for a particular user, particular account, or particular property” (see ¶0009 from Applicant disclosure).
For Step 2A-Prong 2 starting in p. 10: Appellant argues in p.11 that the claims are claims are directed to 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.” However, the Examiner respectfully disagrees and find these arguments unpersuasive. Because the claims’ limitations are reciting the use of a generic computer (i.e. a “computing system”) that further uses tokenization and encoding/decoding technologies which are broadly recited, for specifically at least “generating” respective “encoded token(s)” (see claims 1, 9 and 13) and “decoding” the tokens when “generating” the “time series of the plurality of electronic transactions” without further limiting or specifying how these tokens are being encoded/decoded. Instead, the claims are reciting the use of the technical field of “encoded token mechanism(s)” or “pre-arrangement tokens (with inter-token pointers)”, as asserted by the Appellant, which does not reflect such improvement to the computer functioning and/or technical field of tokenization or encoding/decoding technologies. The claims recite the end-result of providing "sets of related transactions [that] are substantially pre-assembled in a lightweight form" (see ¶0010 from Applicant disclosure), as cited by the Appellant, to construct their time-series of payment transactions. Thus, the claims are merely indicating a field of use or technological environment (i.e. computer environments and tokenization technology) in which to apply a judicial exception to achieve the intended result of generating a “time series of the plurality of electronic transactions” (from claims 1 and 9) and further “initiate” a payment transaction according to the respective tokens (from claim 13). In other words, the encoding/decoding [and/] or tokenization techniques for the computer that encodes/decodes 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/decoding tokens that attempts to limit the use of the abstract idea to computer environments (see MPEP 2106.05(h) for example (x)), as previously asserted in the final office action.
Additionally, the identified limitations in the claims did not integrate a judicial exception into a practical application since the steps were merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea (see MPEP 2106.05(f) and 2106.04(d)(I)). Thus, Appellant assertions that the claims “improve” the functioning of a computer or “improves” another technology or technical field by “enabling the rapid understanding of the related past transactions that are located in the respective storage locations and the rapid compilation of such related transactions using the encoded tokens” is unpersuasive. Because instead, the claim limitations are improving the abstract idea itself for “rapid understanding” of past transactions while using general tokenization and encoding/decoding techniques for “rapid compilation”. The computer and the performing limitations are merely including instructions to implement an abstract idea on a general-purpose computer and use the computer as a tool to achieve the intended result that also recites the abstract idea, as stated above. Thus, the claim steps further describe the end result without providing details on how this alleged “improvement” to the computer functioning and/or to the existing technology of tokenization and encoding/decoding is achieved. Finally, “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept” at step 2B (see MPEP 2106.05(f)(2); TLC communications). Therefore, for all of the reasons above, the Examiner maintains that the claims do not integrate the abstract idea into a practical application and do not overcome 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 14 – 19: Appellant’s arguments against the previous prior art references are considered moot. Because upon revision of this case and in light of the Appeal Conference decision for the Appeal Brief filed, this case is re-opened and new prior art have been found. The new combination of O'Sullivan, Matheson, Soon-Shiong and McHugh references have been incorporated to provide clarity over the 35 USC § 103 rejection for obviousness. Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 18 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Because claim 18 recites the limitation "…wherein the payment transaction is not one of the plurality of electronic transactions" which is reciting subject matter that is considered a negative limitation (emphasized in an underline). Because the boundaries of what other transactions are considered to not be “electronic transactions” are not clearly defined, neither in the claims or in light of the examples of electronic transactions given in ¶0046 – 48, ¶0052 and ¶0080 from Applicant specifications. Thus, the claim limitation is defining the invention in terms of what is not, rather than pointing out the invention (see MPEP 2173.05(i)). Also, it is unclear if Applicant is referring to non-electronic transactions (i.e. physical transactions), although the Examiner notes that the specifications as originally filed, do not support any non-electronic transactions (see ¶0012 from Applicant disclosure). Thus, the scope of what is claimed is not clear for these reasons and is considered to be indefinite. For purposes of examination, the Examiner is interpreting claim 18 to be referring to a different electronic transaction, that is not a “payment transaction” type.
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 limitations:
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 and the 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. 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)” with “pointer” to a “storage location” representing per “electronic transaction” 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 and their pointers are broadly recited and lacks details on how this encoding/decoding is specifically performed in the tokens and their respective pointers 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)).
Also, these limitations for “generating” encoded tokens with “pointers” amount to mere data transmission and storage done by the generic computer recited because, the limitations are recited at a high level of generality, and thus are insignificant extra-solution activity. These limitations are considered as “activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim”, for “generating” the “time-series of the payment transactions” of a user, in this case. “Extra-solution activity” includes “both pre-solution and post-solution activity”. Thus, in this case, these limitations are similar to the “example of pre-solution activity is a step of gathering data for use in a claimed process, e.g., a step of obtaining information about credit card transactions, which is recited as part of a claimed process of analyzing and manipulating the gathered information by a series of steps in order to detect whether the transactions were fraudulent” and the “example of post-solution activity is an element that is not integrated into the claim as a whole, e.g., a printer” (i.e. in this case the encoded “pointers” to point to different tokens to construct the time-series of the payment transactions of a user), “that is used to output a report of fraudulent transactions, which is recited in a claim to a computer programmed to analyze and manipulate information about credit card transactions in order to detect whether the transactions were fraudulent”. See MPEP 2106.05(g) and the Example iii (i.e. Selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display, Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354-55, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)) further described in this same MPEP section from the “Selecting a particular data source or type of data to be manipulated” examples of activities considered insignificant extra-solution activity.
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 – 4, 7 - 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.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over O'Sullivan (U.S. Pub No. 20200160298 A1) in view of Matheson (U.S. Pub No. 20230079195 A1) in further view of Soon-Shiong (U.S. Pub No. 20240086382 A1).
Regarding claim 9:
O'Sullivan teaches:
receiving, by a computing system, a first indication of first data respective of a first electronic transaction associated with a user; (In ¶0029; Fig. 3 (302); Fig. 4 (402); Fig. 5 (502): teaches that, during a “tokenization process”, the user can provide “account information such as the PAN itself, an associated expiration date and/or security code, and the like” that “may be stored in a secure repository at the token service provider and associated with a generated, unique token (e.g., token number, token identifier, etc.)”, which is directed to a first indication of data associated to the users’ first electronic transaction, in accordance to the indication of data example given in ¶0033 – 34, ¶0048 – 50 and Fig. 4 from Applicant disclosure. See ¶0036 wherein during a “process by which a user 102 may tokenize his or her payment card PANs 104, 106, 108”, the “user device may send provisioning data 112 associated with tokenizing the first PAN 104 to a payment network” such as “first PAN 104, an associated expiration date and/or security code, and an identifier for the user device 110”. See ¶0052 for a “method 300 for linking tokenized PANs” (i.e. such as “a first primary account number (PAN)”) wherein “at step 302, first provisioning data (e.g., provisioning data 112) may be received at a payment network (e.g., payment network 240) from a user device (e.g., user device 110; user device 202; etc.)” and the “first provisioning data may indicate a first PAN (e.g., debit PAN 104, a unique string of at least fifteen digits, etc.) and a first device identifier (e.g., wallet identifier 206) associated with the user device”.)
receiving, by the computing system, a second indication of second data respective of a second electronic transaction associated with the user; (In ¶0037; Fig. 3 (304 – 306); Fig. 4 (404 – 406); Fig. 5 (504 – 506): teaches that the “user 102 may subsequently use the wallet application on the user device 110 to tokenize a second PAN 106 associated with a credit card” by sending “provisioning data 112 associated with tokenizing the second PAN 106 to the payment network” such as “second PAN 106, an associated expiration date and/or security code, and the identifier for the user device 110.”)
O'Sullivan teaches that transactional data (i.e. a first, second, third “payment card account” or “PAN”; see ¶0024 and ¶0036; O'Sullivan) can be tokenized (i.e. referred as “tokenized PAN” or simply “the token”) when a user “during the tokenization process” obtains “a generated, unique token (e.g., token number, token identifier, etc.)” along with the “PAN” (see ¶0029 – 30; O'Sullivan). Further, O'Sullivan teaches that each PAN may be included as “provisioning data” stored in a “Token Vault 114” that is further associated with a token, for example: “the first PAN may associated with a first token (e.g., token number, token identifier, etc.)” which is inside a “first data structure” that includes “the first token, the first PAN 104, first mapping data (e.g., data cross-referencing the first token with the first PAN 104), and the device identifier” (see ¶0036 – 37; O'Sullivan). Similarly occurs for the second and third PANs wherein for each tokenized PAN, “Token Vault 114” can “cross-reference each data structure” that holds each token or “tokenized PAN”, by storing in each “data structure” a “reference” (e.g., “memory pointer, database cross-reference, etc.”) that is “associated with a location in the Token Vault 114 (e.g., memory address, database entry, etc.)” where another data structure is stored (see ¶0038 – 39; O'Sullivan). For example, for the “third PAN” wherein the “Token Vault 114” can “cross-reference each data structure” that holds the token or “tokenized PAN”, by storing “in the third data structure 108A the reference 104C (e.g., memory pointer, database cross-reference, etc.) associated with the location in the Token Vault 114 (e.g., memory address, database entry etc.) where the first data structure 104A is stored”, respective of the first “tokenized PAN” or first token (see ¶0039 and ¶0073 for another example; O'Sullivan). However, O'Sullivan does not explicitly teach the ability of having encoded tokens, that inside them, contain a pointer to a storage location of the data representing a respective electronic transaction and another token from the tokens. Thus, Matheson further teaches:
generating, by the computing system, an encoded first token, (In ¶0068; Fig. 3B (352): teaches that “platform server 312 may mint (generate and issue) the set of NFTs associated with purchase activity, where the NFTs represent various aspects of the purchase transaction.” Also, the “platform server 312” may generate “other blocks for a particular purchase transaction.” Finally, “NFTs may be generated before a purchase transaction, upon initiation or completion of steps in a purchase transaction, or after a purchase transaction.”)
the first token comprising a first pointer to a storage location of the first data; (In ¶0058; Fig. 3B (358): teaches an example in Fig. 3B, wherein “the transaction block 358 includes transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files. Further, the “blockchain 350 may contain a plurality of transaction blocks 358, each with pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”, in accordance to the given example of a token that embodies an “encrypted representation of the pointers included in the token” in ¶0029 from Applicant disclosure. The Examiner notes that this prior art reference teaches that “the transaction blocks 358 may be NFTs, rather than just a blockchain block (as in the blockchain 350).”)
and generating an encoded second token, (In ¶0078; Fig. 3B (358): teaches that a second token can be generated for a second purchase transaction since “the platform server 312 or merchant server 304 may mint a set of one or more new NFTs (not shown) based upon further purchase transactions initiated by the customer device 302 when accessing the restricted features of the merchant website.” See ¶0021, “blockchain implementation may mint and issue NFTs to customers based on the products or services sold, which the vendor's platform may track and review to provide the potential privileges or other features described herein.” Finally, refer ¶0089 and ¶0093 for example of another purchase transaction for “when the customer purchases concert tickets from an authorized ticket merchant, the merchant server 304 mints and issues the set of NFTs of the blockchain 350, including the purchase receipt token 352, the ticket stub token 356 for the ticket itself, the store access token 354 granting access or priority to an online merchandise store (e.g., souvenir shop) hosted by the merchant server 304, as well as a certificate of authenticity (not shown) and an event souvenir program (not shown)”.)
the second token comprising: a second pointer to a storage location of the second data, (In ¶0058; Fig. 3B (358): teaches that since tokens can be generated per transaction (i.e. second token for a second transaction), such tokens can include “transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files” (directed to storage location of the second data) and “pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”. Further, “transaction block 358 may represent the various types of transaction data”, such as “token identifiers associated with the NFTs of the purchase transaction, among others”. The “platform server 312 may generate the transaction blocks 358 on a portion of the blockchain 350 parallel from (or in-line with) the NFTs of the particular transaction. The transaction block 358 may further include the preceding hash of the purchase receipt token 352 and a new hash” (see ¶0073).)
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 O'Sullivan to provide the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction, as taught by Matheson in order to have tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Although Matheson teaches that an “NFT may include, for example, metadata associated with the purchase transaction, media data (e.g., image file, audio file), text file, application-specific file, or pointers (e.g., links, access rights) to a storage location containing some or all of the types of data represented by the particular NFT” (see ¶0014; Matheson). Neither, O'Sullivan or Matheson explicitly teach the ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens. Thus, Soon-Shiong teaches:
and a third pointer to a storage location of the first token. (In ¶0075: teaches the use of “expandable token” that “can be a set or a digital token that increases in scope as time passes”. For example, “a genesis token may be minted, which points to an off-chain location, which intern points to additional tokens created as part of the same set. As time passes, the complete set can be compiled from walking from the pointer in the genesis token through the pointers to new tokens on the ledger”. Further, this prior art teaches the use of a “chained token” which “can be a digital token linked to another token, such as for version control where each digital token corresponds to a version, and where the digital tokens are linked”. Thus, these types of tokens are directed to having pointers to a storage location of the previous (i.e. first) 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 O'Sullivan and Matheson to provide the ability of ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens, as taught by Soon-Shiong in order to have “expandable tokens” or “chained tokens” that further include pointers to point back to another token or previous tokens since such “an approach is advantageous for construction time-series data such as electronic medical or health records of an individual” (¶0075; Soon-Shiong). But generally, to use these types of tokens pointing to other tokens in order to “assess subsequently generated digital tokens for similarity, assess the use of data that the digital token represents, invoke program codes associated with the digital token, or send similarity/use notifications to relevant user devices” (¶0013; Soon-Shiong).
Claims 1 - 4, 7 - 8 and 10 - 21 are rejected under 35 U.S.C. 103 as being unpatentable over O'Sullivan (U.S. Pub No. 20200160298 A1) in view of Matheson (U.S. Pub No. 20230079195 A1) in further view of Soon-Shiong (U.S. Pub No. 20240086382 A1) and McHugh (U.S. Pub No. 20210042742 A1).
Regarding claim 1:
O'Sullivan teaches:
receiving, by a computing system, a plurality of indications of data representing a plurality of electronic transactions associated with a user; (In ¶0036 – 37; Fig. 3 (302); Fig. 4 (402); Fig. 5 (502): teaches that during a “process by which a user 102 may tokenize his or her payment card PANs 104, 106, 108”, the “user device may send provisioning data 112 associated with tokenizing the first PAN 104 to a payment network” such as “first PAN 104, an associated expiration date and/or security code, and an identifier for the user device 110” as well as to “send provisioning data 112 associated with tokenizing the second PAN 106 to the payment network”, which is directed to a first indication of data associated to the users’ first electronic transaction, in accordance to the indication of data example given in ¶0033 - 34, ¶0048 – 50 and Fig. 4 from Applicant disclosure. Refer to ¶0029 for another example. See ¶0052 for a “method 300 for linking tokenized PANs” (i.e. such as “a first primary account number (PAN)”) wherein “at step 302, first provisioning data (e.g., provisioning data 112) may be received at a payment network (e.g., payment network 240) from a user device (e.g., user device 110; user device 202; etc.)” and the “first provisioning data may indicate a first PAN (e.g., debit PAN 104, a unique string of at least fifteen digits, etc.) and a first device identifier (e.g., wallet identifier 206) associated with the user device”.)
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: (In ¶0036 – 37; Fig. 3 (302); Fig. 4 (402); Fig. 5 (502): teaches an example wherein through user application a “first PAN” and a “second PAN” may be tokenized for each credit card with their respective “provisioning data” that includes security codes and the user identifier and thus, this data is associated with their respective tokens while the “Token Vault 114” store them with their PANs, “mapping data” (e.g., “data cross-referencing” for each token) and their “device identifier” within a respective “data structure”.)
O'Sullivan teaches that transactional data (i.e. a first, second, third “payment card account” or “PAN”; see ¶0024 and ¶0036; O'Sullivan) can be tokenized (i.e. referred as “tokenized PAN” or simply “the token”) when a user “during the tokenization process” obtains “a generated, unique token (e.g., token number, token identifier, etc.)” along with the “PAN” (see ¶0029 – 30; O'Sullivan). Further, O'Sullivan teaches that each PAN may be included as “provisioning data” stored in a “Token Vault 114” that is further associated with a token, for example: “the first PAN may associated with a first token (e.g., token number, token identifier, etc.)” which is inside a “first data structure” that includes “the first token, the first PAN 104, first mapping data (e.g., data cross-referencing the first token with the first PAN 104), and the device identifier” (see ¶0036 – 37; O'Sullivan). Similarly occurs for the second and third PANs wherein for each tokenized PAN, “Token Vault 114” can “cross-reference each data structure” that holds each token or “tokenized PAN”, by storing in each “data structure” a “reference” (e.g., “memory pointer, database cross-reference, etc.”) that is “associated with a location in the Token Vault 114 (e.g., memory address, database entry, etc.)” where another data structure is stored (see ¶0038 – 39; O'Sullivan). For example, for the “third PAN” wherein the “Token Vault 114” can “cross-reference each data structure” that holds the token or “tokenized PAN”, by storing “in the third data structure 108A the reference 104C (e.g., memory pointer, database cross-reference, etc.) associated with the location in the Token Vault 114 (e.g., memory address, database entry etc.) where the first data structure 104A is stored”, respective of the first “tokenized PAN” or first token (see ¶0039 and ¶0073 for another example; O'Sullivan). However, O'Sullivan does not explicitly teach the ability of having encoded tokens, that inside them, contain a pointer to a storage location of the data representing a respective electronic transaction and another token from the tokens. Thus, Matheson teaches:
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; (In ¶0058; Fig. 3B (358): teaches an example in Fig. 3B, wherein “the transaction block 358 includes transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files. Further, the “blockchain 350 may contain a plurality of transaction blocks 358, each with pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”, in accordance to the given example of a token that embodies an “encrypted representation of the pointers included in the token” in ¶0029 from Applicant disclosure. The Examiner notes that this prior art reference teaches that “the transaction blocks 358 may be NFTs, rather than just a blockchain block (as in the blockchain 350).” Refer to ¶0068 wherein NFTs can be minted (generated or issued) for “purchase transactions” and “other blocks for a particular purchase transaction” can be generated as well.)
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 ¶0058; Fig. 3B (358): teaches that since tokens can be generated per transaction, such tokens can include “transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files” (directed to storage location of a respective electronic transaction of the plurality of electronic transactions) and “pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”. Further, “transaction block 358 may represent the various types of transaction data”, such as “token identifiers associated with the NFTs of the purchase transaction, among others”. The “platform server 312 may generate the transaction blocks 358 on a portion of the blockchain 350 parallel from (or in-line with) the NFTs of the particular transaction. The transaction block 358 may further include the preceding hash of the purchase receipt token 352 and a new hash” (see ¶0073).)
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 O'Sullivan to provide the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction, as taught by Matheson in order to have tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Although Matheson teaches that an “NFT may include, for example, metadata associated with the purchase transaction, media data (e.g., image file, audio file), text file, application-specific file, or pointers (e.g., links, access rights) to a storage location containing some or all of the types of data represented by the particular NFT” (see ¶0014; Matheson). Neither, O'Sullivan or Matheson explicitly teach the ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens. Thus, Soon-Shiong teaches:
and a respective pointer to a storage location of another one of the plurality of tokens; (In ¶0075: teaches the use of “expandable token” that “can be a set or a digital token that increases in scope as time passes”. For example, “a genesis token may be minted, which points to an off-chain location, which intern points to additional tokens created as part of the same set. As time passes, the complete set can be compiled from walking from the pointer in the genesis token through the pointers to new tokens on the ledger”. Further, this prior art teaches the use of a “chained token” which “can be a digital token linked to another token, such as for version control where each digital token corresponds to a version, and where the digital tokens are linked”. Thus, these types of tokens are directed to having pointers to a storage location of the previous (i.e. first) 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 O'Sullivan and Matheson to provide the ability of ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens, as taught by Soon-Shiong in order to have “expandable tokens” or “chained tokens” that further include pointers to point back to another token or previous tokens since such “an approach is advantageous for construction time-series data such as electronic medical or health records of an individual” (¶0075; Soon-Shiong). But generally, to use these types of tokens pointing to other tokens in order to “assess subsequently generated digital tokens for similarity, assess the use of data that the digital token represents, invoke program codes associated with the digital token, or send similarity/use notifications to relevant user devices” (¶0013; Soon-Shiong).
O'Sullivan teaches the abilities of decoding tokens and retrieving stored data from the storage locations of the respective pointers as the “Token Vault 114 may “detokenize” the Credit Token 162 by using the second mapping data to determine the value of the second PAN 106” and “use the second PAN 106 to determine a location (e.g., in memory of the Token Vault 114) where the data structure associated with the second PAN 106 (e.g., the second data structure 106A) is stored” to determine “that the second data structure 106A contains reference 104C to the first data structure 104A and reference 108C to the third data structure 108A” (see ¶0040; O'Sullivan). However, neither O'Sullivan, Matheson or Soon-Shiong explicitly teach the abilities of receiving a specific request for a time series of electronic transactions for a user to generate the time series by decoding the tokens and retrieving their respective data pointers. Thus, 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 or at least accessing 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 O'Sullivan, Matheson and Soon-Shiong to provide the abilities of receiving a specific request for a time series of electronic transactions for a user to generate the time series 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 13:
O'Sullivan further teaches:
receiving, by a computing system, indications of respective data of each of a plurality of electronic transactions associated with a user; (In ¶0036 – 37; Fig. 3 (302); Fig. 4 (402); Fig. 5 (502): teaches under BRI that during a “process by which a user 102 may tokenize his or her payment card PANs 104, 106, 108”, the “user device may send provisioning data 112 associated with tokenizing the first PAN 104 to a payment network” such as “first PAN 104, an associated expiration date and/or security code, and an identifier for the user device 110” as well as to “send provisioning data 112 associated with tokenizing the second PAN 106 to the payment network”, which is directed to a first indication of data associated to the users’ first electronic transaction, in accordance to the indication of data example given in ¶0033 - 34, ¶0048 – 50 and Fig. 4 from Applicant disclosure. Refer to ¶0029 for another example. See ¶0052 for a “method 300 for linking tokenized PANs” (i.e. such as “a first primary account number (PAN)”) wherein “at step 302, first provisioning data (e.g., provisioning data 112) may be received at a payment network (e.g., payment network 240) from a user device (e.g., user device 110; user device 202; etc.)” and the “first provisioning data may indicate a first PAN (e.g., debit PAN 104, a unique string of at least fifteen digits, etc.) and a first device identifier (e.g., wallet identifier 206) associated with the user device”.)
generating, by the computing system, a respective encoded token for each of the plurality of electronic transactions, (In ¶0036 – 37; Fig. 3 (302); Fig. 4 (402); Fig. 5 (502): teaches an example wherein through user application a “first PAN” and a “second PAN” may be tokenized for each credit card with their respective “provisioning data” that includes security codes and the user identifier and thus, this data is associated with their respective tokens while the “Token Vault 114” store them with their PANs, “mapping data” (e.g., “data cross-referencing” for each token) and their “device identifier” within a respective “data structure”.)
O'Sullivan does not explicitly teach the ability of having encoded tokens, that inside them, contain a pointer to a storage location of the data representing a respective electronic transaction and another token from the tokens. Thus, Matheson further teaches:
the token comprising a respective pointer to a storage location of the data associated with the electronic transaction; (In ¶0058; Fig. 3B (358): teaches an example in Fig. 3B, wherein “the transaction block 358 includes transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files. Further, the “blockchain 350 may contain a plurality of transaction blocks 358, each with pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”, in accordance to the given example of a token that embodies an “encrypted representation of the pointers included in the token” in ¶0029 from Applicant disclosure. The Examiner notes that this prior art reference teaches that “the transaction blocks 358 may be NFTs, rather than just a blockchain block (as in the blockchain 350).”)
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 O'Sullivan to provide the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction, as taught by Matheson in order to have tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Although Matheson teaches that an “NFT may include, for example, metadata associated with the purchase transaction, media data (e.g., image file, audio file), text file, application-specific file, or pointers (e.g., links, access rights) to a storage location containing some or all of the types of data represented by the particular NFT” (see ¶0014; Matheson). Neither, O'Sullivan or Matheson explicitly teach the ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens. Thus, Soon-Shiong 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 ¶0075: teaches the use of “expandable token” that “can be a set or a digital token that increases in scope as time passes”. For example, “a genesis token may be minted, which points to an off-chain location, which intern points to additional tokens created as part of the same set. As time passes, the complete set can be compiled from walking from the pointer in the genesis token through the pointers to new tokens on the ledger”. Further, this prior art teaches the use of a “chained token” which “can be a digital token linked to another token, such as for version control where each digital token corresponds to a version, and where the digital tokens are linked”. Thus, these types of tokens are directed to having pointers to a storage location of the previous (i.e. first) 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 O'Sullivan and Matheson to provide the ability of ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens, as taught by Soon-Shiong in order to have “expandable tokens” or “chained tokens” that further include pointers to point back to another token or previous tokens since such “an approach is advantageous for construction time-series data such as electronic medical or health records of an individual” (¶0075; Soon-Shiong). But generally, to use these types of tokens pointing to other tokens in order to “assess subsequently generated digital tokens for similarity, assess the use of data that the digital token represents, invoke program codes associated with the digital token, or send similarity/use notifications to relevant user devices” (¶0013; Soon-Shiong).
Neither O'Sullivan, Matheson or Soon-Shiong explicitly teach the ability of initiating payment transactions based on the respective tokens. Thus, McHugh further teaches:
initiating a payment transaction according to the at least one of the respective tokens. (In ¶0044: teaches an example wherein “to process the sale, external system 11 may generate and transmit a message to financial network 150. Financial network 150 may transmit a message to message system 114 hosted by the financial institution configured to process the payment of the sale”, thus allowing the payment transaction to initiate. See ¶0040 also.)
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 O'Sullivan, Matheson and Soon-Shiong to provide the ability of initiating payment transactions based on the respective tokens, as taught by McHugh in order to “detect events such as fraud or suspicious activity detection” and “allow for security when the tokens are used by being able to forecast, predict, and detect events, such as fraud or suspicious activity” (¶0067 and ¶0015, respectively; McHugh).
Regarding claim 2:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
O'Sullivan further teaches:
wherein the plurality of electronic transactions comprise electronic events associated with the user. (In ¶0024: teaches that the system similar to “Payment networks receive transaction data from merchants (e.g., from a merchant point of sale system (“POS”) and/or an acquirer bank associated with a merchant) and ensure that transactions associated with transaction data are appropriately processed and passed on to an issuer of a given payment card”, in accordance to examples given in ¶0012. Specifically, this system is applied to “payment card transactions” (see ¶0027) See ¶0033 – 34 and ¶0040 for examples.)
Regarding claim 3:
O'Sullivan, as shown in the rejection above, discloses the limitations of claim 2.
O'Sullivan further teaches:
wherein the electronic events comprise one or more of: an interaction between a user and an electronic transaction system; an interaction between the electronic transaction system and a third-party system; or a processing operation by the electronic transaction system. (In ¶0040; Fig. 1B: teaches in “FIG. 1B”, “a flowchart of a process whereby a user 102 initiates a payment transaction for travel arrangements (e.g., airline ticket, bus fare, rail ticket, hotel, rental car, etc.) using a tokenized PAN stored on his or her user device 110”. Further, “user 102 may send the token associated with the credit card PAN 106 to a merchant point of sale device (e.g., via RFID communication, near-field communication, Bluetooth™, website interface, etc.) and the “merchant point of sale device (or web interface, as the case may be) may send transaction data associated with the transaction, such as the token associated with the second PAN 106 (Credit Token 162) and travel data 150, to a payment network 160.” See ¶0048 – 49 for another example.)
Regarding claim 4:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
O'Sullivan further teaches:
wherein the plurality of data comprise electronic records of data of the transaction. (In ¶0048 – 49: teaches that the “user device 202 may send the Transaction Data 219 to a merchant bank 218 (e.g., via a physical merchant point of sale device and/or a merchant website)” wherein the transaction data includes “an ISO formatted transaction record”.)
Regarding claim 7:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
Neither O'Sullivan, Matheson or Soon-Shiong 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 O'Sullivan, Matheson and Soon-Shiong 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 O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 7.
Neither O'Sullivan, Matheson or Soon-Shiong 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 O'Sullivan, Matheson and Soon-Shiong 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 O'Sullivan, Matheson, Soon-Shiong 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
Neither O'Sullivan, Matheson or Soon-Shiong 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 O'Sullivan, Matheson and Soon-Shiong 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 O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claims 10 and 16, respectively.
O'Sullivan 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; (In ¶0057: teaches that a “third provisioning data may be received at the payment network”.)
and generating a third token, (In ¶0037: teaches that a “user 102 may again use the wallet application on the user device 110 to tokenize a third PAN 108 associated with a corporate credit card” that includes its respective “provisioning data” (i.e. “third PAN 108, an associated expiration date and/or security code, and the identifier for the user device 110”) that is further “associated with a third token (e.g., token number, token identifier, etc.)”. Further, the “Token Vault 114 may then store the third token, the third PAN 108, third mapping data (e.g., data cross-referencing the third token with the third PAN 108), and the identifier for the user device 110 in a third data structure 108A.”)
O'Sullivan further teaches a “third data structure associated with a third tokenized PAN” in a “Token Vault 114” that holds a “third token” for the “third PAN” and may be cross-referenced by storing a “reference 106C (e.g., memory pointer, database cross-reference, etc.)” in the “third data structure” that is “associated with the location in the Token Vault 114 (e.g., memory address, database entry etc.) where the second data stored” (see ¶0038 – 39; O'Sullivan). However, O'Sullivan does not explicitly teach the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction and another token from the tokens. Thus, Matheson further teaches:
the third token comprising: a fourth pointer to a storage location of the third data, (In ¶0058; Fig. 3B (358): teaches tokens can be generated per transaction, for example, a third token can include “transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files” (directed to a fourth pointer to a storage location of the third data) and “pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”. Further, “transaction block 358 may represent the various types of transaction data”, such as “token identifiers associated with the NFTs of the purchase transaction, among others”. Also, “the transaction block 358 may further include the preceding hash of the purchase receipt token 352 and a new hash” (see ¶0073). Refer to ¶0068 wherein NFTs can be minted (generated or issued) for “purchase transactions” and “other blocks for a particular purchase transaction” can be generated as well.)
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 O'Sullivan to provide the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction, as taught by Matheson in order to have transaction blocks with tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Although Matheson teaches that an “NFT may include, for example, metadata associated with the purchase transaction, media data (e.g., image file, audio file), text file, application-specific file, or pointers (e.g., links, access rights) to a storage location containing some or all of the types of data represented by the particular NFT” (see ¶0014; Matheson). Neither, O'Sullivan or Matheson explicitly teach the ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens. Thus, Soon-Shiong further teaches:
and a fifth pointer to a storage location of the second token (In ¶0075: teaches the use of “expandable token” that “can be a set or a digital token that increases in scope as time passes”. For example, “a genesis token may be minted, which points to an off-chain location, which intern points to additional tokens created as part of the same set. As time passes, the complete set can be compiled from walking from the pointer in the genesis token through the pointers to new tokens on the ledger”. Further, this prior art teaches the use of a “chained token” which “can be a digital token linked to another token, such as for version control where each digital token corresponds to a version, and where the digital tokens are linked”. Thus, these types of tokens are directed to having pointers (i.e. fifth pointer) to a storage location of the previous (i.e. 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 O'Sullivan and Matheson to provide the ability of ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens, as taught by Soon-Shiong in order to have “expandable tokens” or “chained tokens” that further include pointers to point back to another token or previous tokens since such “an approach is advantageous for construction time-series data such as electronic medical or health records of an individual” (¶0075; Soon-Shiong). But generally, to use these types of tokens pointing to other tokens in order to “assess subsequently generated digital tokens for similarity, assess the use of data that the digital token represents, invoke program codes associated with the digital token, or send similarity/use notifications to relevant user devices” (¶0013; Soon-Shiong).
Regarding claim 14:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 13.
Neither O'Sullivan, Matheson or Soon-Shiong 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 O'Sullivan, Matheson and Soon-Shiong 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 O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 14.
Neither O'Sullivan, Matheson or Soon-Shiong 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 O'Sullivan, Matheson and Soon-Shiong 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 O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 14.
O'Sullivan further teaches:
wherein: the plurality of electronic transactions comprise a first electronic transaction and a second electronic transaction, and (In ¶0055: teaches an examples wherein “After the first PAN and the second PAN are tokenized, the payment network may receive a transaction record (e.g., Travel Data 150, Transaction Data 219, etc.) associated with a purchase of travel arrangements (e.g., airline ticket, bus fare, rail ticket, hotel, rental car, etc.) using the first tokenized PAN”.)
O'Sullivan does not explicitly teach the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction and another token from the tokens. However, Matheson further teaches:
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 (In ¶0058; Fig. 3B (358): teaches an example of a first token in Fig. 3B, wherein “the transaction block 358 includes transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files. Further, the “blockchain 350 may contain a plurality of transaction blocks 358, each with pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”. The Examiner notes that this prior art reference teaches that “the transaction blocks 358 may be NFTs, rather than just a blockchain block (as in the blockchain 350).” Refer to ¶0068 wherein NFTs can be minted (generated or issued) for “purchase transactions” and “other blocks for a particular purchase transaction” can be generated as well.)
a second token, the second token comprising: a second pointer to a storage location of second data associated with the second electronic transaction, (In ¶0058; Fig. 3B (358): teaches that since tokens can be generated per transaction (i.e. second token for a second transaction), such tokens can include “transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files” (directed to storage location of the second electronic transaction) and “pointers to respective off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable”. Further, “transaction block 358 may represent the various types of transaction data”, such as “token identifiers associated with the NFTs of the purchase transaction, among others” and the “transaction block 358 may further include the preceding hash of the purchase receipt token 352 and a new hash” (see ¶0073).)
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 O'Sullivan to provide the ability of having encoded tokens containing a pointer to a storage location of the data representing a respective electronic transaction, as taught by Matheson in order to have transaction blocks with tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Although Matheson teaches that an “NFT may include, for example, metadata associated with the purchase transaction, media data (e.g., image file, audio file), text file, application-specific file, or pointers (e.g., links, access rights) to a storage location containing some or all of the types of data represented by the particular NFT” (see ¶0014; Matheson). Neither, O'Sullivan or Matheson explicitly teach the ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens. Thus, Soon-Shiong teaches:
and a third pointer to a storage location of the first token. (In ¶0075: teaches the use of “expandable token” that “can be a set or a digital token that increases in scope as time passes”. For example, “a genesis token may be minted, which points to an off-chain location, which intern points to additional tokens created as part of the same set. As time passes, the complete set can be compiled from walking from the pointer in the genesis token through the pointers to new tokens on the ledger”. Further, this prior art teaches the use of a “chained token” which “can be a digital token linked to another token, such as for version control where each digital token corresponds to a version, and where the digital tokens are linked”. Thus, these types of tokens are directed to having pointers to a storage location of the previous (i.e. first) 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 O'Sullivan and Matheson to provide the ability of ability of having encoded tokens containing a pointer to a storage location specifically, of another token from the tokens, as taught by Soon-Shiong in order to have “expandable tokens” or “chained tokens” that further include pointers to point back to another token or previous tokens since such “an approach is advantageous for construction time-series data such as electronic medical or health records of an individual” (¶0075; Soon-Shiong). But generally, to use these types of tokens pointing to other tokens in order to “assess subsequently generated digital tokens for similarity, assess the use of data that the digital token represents, invoke program codes associated with the digital token, or send similarity/use notifications to relevant user devices” (¶0013; Soon-Shiong).
Regarding claim 18:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 13.
Neither O'Sullivan, Matheson or Soon-Shiong explicitly teach the ability of having other types of electronic transactions that are not payment transactions. Thus, McHugh further teaches:
wherein the payment transaction is not one of the plurality of electronic transactions. (In ¶0034: teaches under BRI, an example wherein an “external system 110 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” wherein from the events mentioned is interpreted as an electronic transaction that can be other than a payment transaction, such as the “addition/deletion/modification of the account or payment device”, in accordance to examples of transactions that are different from being payment transactions as given in ¶0046 – 48 and ¶0052 from Applicant disclosure. See ¶0036 wherein an “account holder may execute various actions to their payment device using interface 118” such as “view, use, suspend, delete, or add a payment device with respect to the specific external system” and “each action may cause a creation of an event and a message to be sent to a financial network 150” to further generate a token. See ¶0040 for other transaction as tokens.)
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 O'Sullivan, Matheson and Soon-Shiong to provide the ability of having other types of electronic transactions that are not payment transactions, as taught by McHugh in order to “detect or predict events such as detect fraud, lost or stolen payment devices, or the like” and “detect suspicious activity based on location of an event associated with a token based on a known location of the account holder” or “based on the type of external system 110 which generated the token, as the analytical or predictive model may indicate that the type of external system 110 is different than the types of external systems 110 normally used by the account holder” (¶0041, respectively; McHugh).
Regarding claim 19:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 13.
O'Sullivan further teaches:
wherein the payment transaction comprises a payment from the user to a merchant. (In ¶0040; Fig. 1B: teaches in Fig. 1B, “process whereby a user 102 initiates a payment transaction for travel arrangements (e.g., airline ticket, bus fare, rail ticket, hotel, rental car, etc.) using a tokenized PAN stored on his or her user device 110” wherein “user 102 may send the token associated with the credit card PAN 106 to a merchant point of sale device (e.g., via RFID communication, near-field communication, Bluetooth™, website interface, etc.).” See ¶0034 for another example.)
Regarding claim 20:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 19.
O'Sullivan does not explicitly teach the ability of initiating payment transactions in response to merchant request. Thus, Matheson further teaches:
wherein the payment transaction is initiated in response to a request from a merchant. (In ¶0096; Fig. 4 (404 – 408): teaches upon “customer device accesses a merchant website and initiates a purchase transaction process for the particular product” (at step 402), “step 404, the platform server may receive an online merchant access request involving the blockchain wallet and a set of one or more merchant access rules” as well as the “merchant server transmits the merchant request to the platform server, where the merchant request includes query parameters for the platform server to query the customer wallets (as in step 406, below) to determine whether a particular customer's wallet contains the requisite NFT (as in step 408, below)” which is directed to a payment transaction initiated in response to a request from a merchant. Further at step 408 in ¶0101, once determined that the “customer's blockchain wallet contains the required access NFTs and that the customer's transaction history (of purchase events) satisfy the merchant's rules, then the platform server transmits a response to the merchant server indicating that the customer satisfies the merchant's rules” and “merchant server grants the customer device access to the controlled content of the merchant website and/or prioritizes purchase transactions (or other features of the merchant website) initiated”. See ¶0102 for an example of purchases being granted after merchant requesting a verification of access NFTs that the customer satisfy based on the merchant rules to execute purchase transaction.)
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 O'Sullivan to provide the ability of having a payment transaction specifically, initiated in response to a merchant request, as taught by Matheson as it would be obvious to try to have payment transactions initiated in response to a merchant request in order to ensure the consumer is satisfying the merchant rules and “prioritize customer purchases according to particular buying behaviors (according to the customer transaction history), as an additional restriction to the requirement to have the access NFT” (¶0101 – 102; Matheson).
Regarding claim 21:
The combination of O'Sullivan, Matheson, Soon-Shiong and McHugh, as shown in the rejection above, discloses the limitations of claim 1.
O'Sullivan does not explicitly teach the ability of having token pointers that point to a storage location including a memory address. Thus, Matheson further teaches:
wherein each storage location comprises a respective memory address. (In ¶0058: teaches that the NFT or “transaction block 358 includes transaction data for a particular purchase transaction, which may be in the form of pointers to storage memory locations containing actual data values or data files”. See ¶0014 also.).
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 O'Sullivan to provide the ability of having token pointers that point to a storage location including a memory address, as taught by Matheson in order to have transaction blocks with tokens or NFTs that further include pointers that have “off-chain storage memory locations that actually contain the transaction data, so the transaction blocks 358 could be relatively interchangeable” (¶0058; Matheson). But generally, to have NFTs that include pointers, “later referenced to track and predict purchasing behaviors” (¶0011; Matheson).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mancuso (U.S. Pub No. 20230394466 A1) is pertinent because it is about “systems can facilitate generating tokenized assets (either directly or via a third party system) from content items within a content management system that stores content items for user accounts in a cloud-based remote network” wherein “tokenized asset data” includes “ownership information, creator information, a ledger history, and/or a storage location indicator” (see ¶0033 from reference).
Mehrhoff (U.S. Pub No. 20210217005 A1) is pertinent because it “relates generally to contactless payment cards used for the payment of goods and/or services and, more particularly, to securing data stored on a contactless payment card through the use of tokens.” Further, teaches “the method includes updating, by the token requesting device, a pointer stored in the token data portion of the contactless payment card memory device to point to the contactless token.” (see ¶0005 and Figs. 4A and 4B (402) from reference).
Klebacha (U.S. Pub No. 20250069050 A1) is pertinent because it “relates to systems and methods providing an electronic transfer directory service for distillation or distribution of files.”
Janiga (U.S. Patent No 12063212 B1) is pertinent because it “relate generally to the field of computing, and more particularly, to systems, methods, and apparatuses for routing proceeds using secure tokens.”
Mokhasi (U.S. Pub No. 20200265422 A1) is pertinent because it “relates generally to payment device tokenization and, in some embodiments or aspects, to a system, method, and computer program product for generating, storing, and processing new payment device tokens in relation to old payment device tokens.”
D'Souza (U.S. Pub No. 20170132617 A1) is pertinent because it “relates to a method and network for accessing encrypted data.”
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.”
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