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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier provisional application filing date as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994)
The disclosure of the prior-filed application, Application No. 62/422,552, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. For example, the drawings in the instant application do not appear in the above cited provisional application. Provisional application 62/491,946 appears to provide adequate support to the currently filed claims. Accordingly, the effective filing date is determined to be 4/28/2017.
Application Status
Claims 2-18 and 20-21 are pending and have been examined.
Claim 19 is canceled.
This office action is Final, necessitated by amendment.
Withdrawn Objections
The claim objection of claim 9 is withdrawn in view of the amendments received.
Withdrawn Rejections
The 35 U.S.C. § 112(b) rejections of claims 2-10 drawn to contingent claim limitations including antecedent basis for claimed term “… token…” are withdrawn in view of the amendments received.
The 35 U.S.C. § 112(b) rejections of claim 19 drawn to clarity issues of “payment token” and “token” is withdrawn in view of the amendments received – claim 19 is canceled.
Claim Rejections
Claims 2-101 remain rejected under 35 U.S.C. § 112(a) for written description issues.
Claims 2-18 and 20-21 are rejected under 35 U.S.C. § 112(a) for written description issues pertaining to “…wherein the linking results in a registration of the user device at the third party transaction system…”.
Claims 2-18 and 20-212 remain rejected under 35 U.S.C. § 101 for being directed to an abstract idea without significantly more.
Acknowledgement of Issues Raised by Applicant
Applicant’s arguments drawn to the 35 U.S.C. § 101 rejections have been fully considered but are not persuasive – see “Response to Applicant Arguments” section immediately following this section.
Applicant’s arguments drawn to the 35 U.S.C. § 112(a) rejections of claims 2-10 have been fully considered but are not persuasive – Examiner notes applicant remarks are cursory and notes the rationales in the 35 U.S.C. §112(a) rejections (further below).
Response to Applicant Arguments
35 U.S.C. § 101
As an initial matter, examiner notes Applicant asserts claims 2-21 are patent eligible per the claims integrating the judicial exception into a practical application and/or amounting to significantly more, under Alice/Mayo analysis. The Examiner respectfully disagrees.
Applicant’s arguments asserting the claims impose a meaningful limit on the judicial exception3 are not persuasive for the following reasons:
The additional elements “(token issuance and transaction) system…”, “…(third party) transaction system …”, and “at an identity platform of the token issuance and transaction system” of claim 2, the additional elements “An identity and transaction system comprising: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the identity and transaction system to perform operations comprising:”, “(third party) transaction system”, “(identity and transaction) system”, and “(identity handle) at an identity platform of the identity and transaction system and an account of the user at an identity platform of the third-party transaction system” of claim 11, and the additional elements “…A non-transitory machine-readable medium having instructions stored thereon, the instructions executable to cause performance of operations …”, “(third party) transaction system”, “(token issuance and transaction) … system”, “(identity handle) at a first identity platform of the token issuance and transaction system”, and “(an identity handle of the user) at a second identity platform of the third-party transaction system” of claim 16 amount to no more than mere instructions to implement the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05 (f), (h)), even when considering each claim’s additional elements both separately and as an ordered combination. Stating an abstract idea while adding the words "apply it" (or an equivalent) is insufficient to impart patent eligibility under Alice. See Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014): "… Stating an abstract idea "while adding the words ‘apply it’ " is not enough for patent eligibility. … Nor is limiting the use of an abstract idea " ‘to a particular technological environment.’ … Stating an abstract idea while adding the words "apply it with a computer" simply combines those two steps, with the same deficient result”.
The Applicant’s claims fail to provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to any other technology or technical field (MPEP §§2106.04(d)(1) & 2106.05(a)). For example, the instant claims do not include any specific technical details as to how the claimed “determining, based on the transaction request, that the user is managed via different user representations”, “determining, based on the transaction request, that the user is authenticated via the different user representations at both the token issuance and transaction system and the third-party payment system”, or “…linking, via a token…” is specifically employed. This supports the aforementioned determination that the additional elements of the independent claims are merely applied. See MPEP §2106.05 (f)(1): “…claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words ‘apply it’”.
The judicial exception alone cannot provide the improvement under Alice/Mayo analysis, and an improvement in the abstract idea itself is not a technological solution to a technological problem (MPEP §§ 2106.05 (a), (a) II). See the following:
MPEP 2106.05(a) II: “… it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology … Merely adding generic computer components to perform the method is not sufficient.”
Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015): “... our precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea.”
Customedia Techs. V. Dish Network Corp., 951 F.3d 1359, (Fed. Cir. 2020): “We have held that ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ was insufficient to render the claims patent eligible as an improvement to computer functionality”.
Example 40 is not applicable to the instant claims – the instant claims are not directed to network visibilities tools that enable close monitoring of computer network traffic, unlike Example 40.
The arguments drawn to “without issuing a payment token” are not persuasive, as Applicant’s claims process the payment on the basis of receiving the token. Furthermore, Applicant’s specification and claims has not successfully delineated any distinction between the claimed tokens and the payment tokens as described in claim 19 and Applicant remarks – see the 112(b) rejection further below. Accordingly, Examiner respectfully disagrees that the claims clearly “reduces … costs … conserves … computing resources … improves … routing efficiency…”, as Applicant states.
Applicant’s arguments drawn to “amounting to significantly more” under step 2B are not persuasive for the following reasons:
With respect to Applicant’s supporting argument drawn to “a smoothed distribution probability map generated for the user account” (page 12 of Remarks), Examiner respectfully disagrees with the overall thrust of argument and maintains the claims do not recite any such subject matter – the argument is not commensurate with claim scope.
With respect to Applicant’s supporting arguments drawn to Bascom, Examiner respectfully disagrees. Even when considered as an ordered combination, the additional elements add nothing that is not already present when the steps are considered separately, and simply recite the abstract “transaction processing” as performed by a generic, general-purpose computer, with preliminary account linking steps (See ¶90 of Applicant Specification).
Accordingly, for the reasons listed above, as well as the reasons outlined in the 101 rejection (further below), the Examiner respectfully maintains the 35 U.S.C § 101 rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Written Description
Claims 2-18 and 20-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 2 (3-10 by virtue of dependency)
With respect to dependent claim 2, it recites:
“…
receiving a transaction request, at a token issuance and transaction system, … from a third party transaction system…
determining, based on the transaction request, that the user is managed via different user representations at the token issuance and transaction system and the third party transaction system, respectively; …
determining, based on the transaction request, whether the first representation of the user is linked with a second representation of the user at the third party transaction system;
based on a determination that the first representation of the user is not linked with the second representation of the user, linking via a token, the first representation of the user at the token issuance and transaction system and the second representation of the user at the third party transaction system, wherein the token includes a second identity handle … and wherein the linking is performed at least in part by linking the first identity handle to the second identity handle, …
sending the token to the third party transaction system; and
processing, based on the linking and a receipt of the token … the transaction ….”.
The Examiner respectfully fails to see any such sequence of steps described within Applicant’s specification. For example, none of the flows depicted in Figs. 3-5 (of which constitute all the drawings corresponding to flow diagrams/charts,) include such a sequence. Fig. 3 corresponds to an onboarding request being received (ref 302), and generating a link when bold users are onboarded (ref 304). Fig. 4 corresponds to a pre-transaction request, determining if a link is contained or indicated therein, and, if not linked, generate a token using a standard tokenization process (ref 406). Fig. 5 performs the linking prior to any transaction request being received (see Fig. 5, ref 502, in further view of ¶78). There is no support in applicant’s specification for the subsequent linking performed based on a determination that the first representation of the user is not linked, after the transaction request is received.
Claims 3-10 are rejected by virtue of dependency.
Claims 2, 11, and 16 (3-7, 9, 10, 12-14, 17, 18, 20, and 21 by virtue of dependency)
With respect to independent claims 2, 11, and 16, they recite limitations:
“…wherein the linking results in a registration of the user device at the third-party transaction system ….”.
The Examiner respectfully fails to see any written description in specification supporting the above claim limitation. Examiner acknowledges ¶46: “…Device Registration – Provides ability to register a device where tokens need to be provisioned. … The device registration can be implemented at one or more of steps 308-312.” and ¶29: “…The third-party IdP can include a user representation for the user of the user device 114.”.
In light of the above disclosure, it is correct that a device is registered as a result of a linking process, where the registered device is associated with the third-party transaction system. However, the registration of the device disclosed in Applicant specification is performed at the token issuance and transaction system, and not the at the third-party transaction system – see the following (underline emphasis added):
¶14: “The TSP 110 can provide registration and enrollment functionality (referred to as linking herein) to the third-party transaction system 104...”
¶30: “…The TSP 110 can generate the link 149 that indicates linking of the user representations between the third-party transaction system 1044 and the TSP issuance and transaction system 112…”
¶54: “…Beginning with 302, the TSP 110 can receive an onboarding request … The onboarding request can be received from … the third-party transaction system 104 … The onboarding request can indicate the user device 114…”
¶57: “…The TSP can perform the device registration process for the user device 114…”
Accordingly, in view of the above, Applicant’s specification supports device registration realized by a linking process at the token issuance and transaction system (e.g., either the TSP 110 or TSP issuance and transaction system 112), and not at the third-party transaction system (e.g., reference 104 of Applicant specification). This is additionally evident in view of ¶54, as the third-party transaction system is already determined to be associated with the third-party transaction system, per it being initially provided in the onboarding request by the third-party transaction system 104 (i.e., prior to any registration actually occurring).
Claims 3-7, 9, 10, 12-14, 17, 18, 20, and 21 are rejected by virtue of dependency.
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 2-18 and 20-21 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
As an initial matter, the relevant test is the Alice/Mayo test5. The following analysis provided in this section results from the instant application’s claims being examined within the scope of the Alice/Mayo test framework.
When analyzed under step 1 of the Alice/Mayo test6, claims 2-21 are directed to either a method, system, or product of manufacture (Step 1 of Alice/Mayo Test: YES).
When analyzed under prong I of revised step 2A, claims 2-18 and 20-21 each recite a method of organizing human activity,7 because independent claims 2, 11, and 16 recite:
“2. A method for transaction processing, the method comprising:
receiving a transaction request that originated from … a user, at a token issuance and transaction… [provider], for a transaction associated with a first representation of a user at the token issuance and transaction… [provider],
the transaction request involving a third-party … different from the token issuance and transaction …[provider], …. wherein the transaction is between the user and a merchant,
and wherein the merchant is different from the third-party … and the token issuance and transaction … [provider], and wherein the transaction request comprises a first identity handle of the user at an identity platform of the third-party …;
determining, based on the transaction request, that the user is managed via different user representations at the token issuance and transaction … [provider] and the third-party …, respectively;
determining, based on the transaction request, that the user is authenticated via the different user representations at both the token issuance and transaction … [provider] and the third-party …;
determining, based on the transaction request, that the first representation of the user is not yet linked with a second representation of the user at the third-party transaction system;
based on a determination that the first representation of the user is not yet linked with the second representation of the user, linking, via a token, the first representation of the user at the token issuance and transaction … [provider] and the second representation of the user at the third-party …, wherein the token includes a second identity handle that points to an account of the user … [provider] and wherein the linking is performed at least in part by linking the first identity handle to the second identity handle, wherein the linking results in a registration of the user … at the third party …, and wherein the linking is further performed at least in part by defining a transaction scope for the token;
sending the token to the third-party.”
“11. …
accessing a transaction request for a transaction associated with a first representation of a user, the transaction request originating from a user … and involving a third party … different from the identity and transaction …[provider], … wherein the transaction is between the user and a merchant, the merchant being different from the third party … and the identity and transaction …[provider], wherein the user is authenticated for the transaction at the identity and transaction… [provider];
determining, based on the transaction request, that the user is further authenticated via a second representation of the user at the third-party ...;
determining, based at least on the transaction request, that the first representation of the user is linked via a link with the second representation of the user, wherein the link includes a token that indicates an association between an account of the user … [provider], wherein the link enables a registration of the user … at the third party …, and wherein the link further specifies a scope for transactions that involve the token; and
providing the token to the third-party …;
processing, based on a determination that the first representation of the user is linked via the link with the second representation of the user and further based on a receipt of the token, the transaction between the user and the merchant.”
“16. …operations comprising:
accessing a transaction request for a transaction associated with a first representation of a user, the transaction request originating from a user …, the transaction request involving a third-party … different from a token issuance and transaction… [provider],
wherein the transaction is between the user and a merchant that is different from the third-party … and the token issuance and transaction … [provider],
wherein the user is authenticated for the transaction at the token issuance and transaction …[provider];
determining, based on the transaction request, that the user is further authenticated via a second representation of the user at the third-party …;
determining, based at least on the transaction request, that the first representation of the user is linked via a link with the second representation of the user, wherein the link is generated as a token and indicates an association between an identity handle of the user … [provider] and an identity handle of the user …, wherein the link further enables a registration … at the third party…, and wherein the token is further associated with a specified transaction scope;
transmitting the token to the third-party …; and
receiving the token from the third-party … or from the merchant.”
Under broadest reasonable interpretation, these are commercial interactions of
“provisioning transaction credentials”, comprising steps of sharing and linking two sets of account information / credentials / details of a user (e.g., consumer / purchaser) between distinct entities (e.g., token issuance provider and third-party transaction provider) – each entity managing one of the accounts – so as to allow for subsequent transaction processing between a merchant and a user, where the merchant and user are neither of the distinct entities. Thus, the claim recites an abstract idea (Step 2A Prong I of Alice/Mayo Test: Yes, the claims recite an abstract idea).
This judicial exception recited in independent claims 2, 11, and 16 is not integrated into a practical application because, when analyzed under prong II of revised step 2A of the Alice/Mayo test8:
The additional elements “…that originated from a user application executing on a user device …”, “…wherein the third party transaction system is implemented as a part of a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE),…”, “…of the user device…”, “(third party) …transaction system…” “(token issuance and transaction) system…”, “…(third party) transaction system …”, and “at an identity platform of the token issuance and transaction system” of claim 2, the additional elements “An identity and transaction system comprising: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the identity and transaction system to perform operations comprising:”, “…that originated from a user application executing on a user device …”, “…wherein the third party transaction system is implemented as a part of a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE),…”, “…of the user device…”, “(third party) …transaction system…”, “(third party) transaction system”, “(identity and transaction) system”, and “(identity handle) at an identity platform of the identity and transaction system and an account of the user at an identity platform of the third-party transaction system” of claim 11, and the additional elements “…A non-transitory machine-readable medium having instructions stored thereon, the instructions executable to cause performance of operations …”, “…application executing on a computing device…”, “…wherein the third party transaction system is associated with a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE),…”, “…of the computing device…”,“…(third party) transaction system…”, “(token issuance and transaction) … system”, “(identity handle) at a first identity platform of the token issuance and transaction system”, and “(an identity handle of the user) at a second identity platform of the third-party transaction system” of claim 16 amount to no more than mere instructions to implement the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05 (f), (h)), even when considering each claim’s additional elements both separately and as an ordered combination. Stating an abstract idea while adding the words "apply it" (or an equivalent) is insufficient to impart patent eligibility under Alice. See Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014): "… Stating an abstract idea "while adding the words ‘apply it’ " is not enough for patent eligibility. … Nor is limiting the use of an abstract idea " ‘to a particular technological environment.’ … Stating an abstract idea while adding the words "apply it with a computer" simply combines those two steps, with the same deficient result”.
The Applicant’s claims fail to provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to any other technology or technical field (MPEP §§2106.04(d)(1) & 2106.05(a)). For example, the instant claims do not include any specific technical details as to how the claimed “determining, based on the transaction request, that the user is managed via different user representations”, “determining, based on the transaction request, that the user is authenticated via the different user representations at both the token issuance and transaction system and the third-party payment system”, or “…linking, via a token…” is specifically employed. This supports the aforementioned determination that the additional elements of the independent claims are merely applied. See MPEP §2106.05 (f)(1): “…claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words ‘apply it’”.
The judicial exception alone cannot provide the improvement under Alice/Mayo analysis, and an improvement in the abstract idea itself is not a technological solution to a technological problem (MPEP §§ 2106.05 (a), (a) II). See the following:
MPEP 2106.05(a) II: “… it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology … Merely adding generic computer components to perform the method is not sufficient.”
Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015): “... our precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea.”
Customedia Techs. V. Dish Network Corp., 951 F.3d 1359, (Fed. Cir. 2020): “We have held that ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ was insufficient to render the claims patent eligible as an improvement to computer functionality”.
In light of the above rationales provided for step 2A Prong II analysis, the Examiner respectfully submits the focus of the claims is not on an improvement in computers as tools, but rather on an abstract idea that uses computers as tools. Considered both separately and as an ordered combination, the additional elements of the independent claims do not integrate the abstract idea into a practical application, as they do no more than represent computers performing functions that correspond to (,i.e., implement,) the acts of the abstract commercial interactions within a particular technological environment, and do not provide details such that one of ordinary skill in the art would recognize the claims as reflecting an improvement to the functioning of a computer or any other technology or technical field. (Step 2A Prong II of Alice/Mayo Test: NO, the additional elements do not integrate the judicial exception into a practical application). Accordingly, claims 2, 11, and 16 are determined to be directed to an abstract idea.
When analyzed under step 2B9, claims 2, 11, and 16 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims 2, 11, and 16, each when viewed as a whole, do not include elements amounting to significantly more, as their additional elements, each viewed both individually and as an ordered combination, amount to no more than mere instructions to implement the abstract commercial interactions within a particular technological environment – see MPEP §§ 2106.05 (f), (h) and Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014). Even though claims 2, 11, and 16 incorporate additional elements, the manner by which the claims’ additional elements are used is indistinguishable from mere addition of general-purpose computers added post-hoc to the abstract idea recited. Nothing in the claims indicate specific steps undertaken by computer elements that are beyond conventional functionality of computers being used at a high degree of generality, excepting the abstract idea it is merely used as a tool for. Accordingly, when considered both separately and as an ordered combination, none of the elements of the independent claims add significantly more to the abstract idea itself (i.e., an inventive concept), as merely employing computers as tools to automate and/or implement the abstract idea cannot provide significantly more than the judicial exception itself – see BSG Tech LLC vs. BuySeasons, Inc., 899 F.3d 1281, 1290 (Fed. Cir. 2018): “It has been clear since Alice that a Claimed invention’s use of the ineligible concept to which it is directed cannot supply the inventive concept that renders the invention ‘significantly more’ than that ineligible concept”.
Hence, independent claims 2, 11, and 16 are not patent eligible.
With respect to the dependent claims, they have each been given the full Alice/Mayo analysis, including analyzing the additional elements both individually and as an ordered combination (if any). The dependent claims are also held patent ineligible under 35 U.S.C. § 101 because of the same reasoning as above, and because the claim limitations of the dependent claims fail to establish that the claims are integrated into a practical application or amount to significantly more. The rationales for the aforementioned determinations are explained further below.
With respect to dependent claims 7, 10, 12, 14, and 21, the additional limitations, when considered individually and as an ordered combination, do not recite additional elements outside of the abstract idea that integrate the judicial exception into a practical application, and, even when considered as an ordered combination, do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and further fail to provide any other further additional elements for consideration. Accordingly, when considered as a whole, the claims do not improve the functioning of a computer, or to any other technology or technical field, do not integrate the judicial exception into a practical application, and do not amount to significantly more.
With respect to dependent claim 3, 6, 13, 15, and 18, the additional limitations, when considered individually and as an ordered combination, do not integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional elements “…(transaction) system …” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more.
With respect to dependent claim 4 and 17, the additional limitations, when considered individually and as an ordered combination, do not integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional elements “…or a processing network …” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more.
With respect to dependent claim 5, the additional limitations, when considered individually and as an ordered combination, do not integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional elements “…device …” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more.
With respect to dependent claims 8 and 20, the additional limitations, when considered individually and as an ordered combination, do not integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional elements “system”, and “redirect, to a user device [associated with]” do no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claims do not improve the functioning of a computer, or to any other technology or technical field, do not integrate the judicial exception into a practical application, and do not amount to significantly more.
With respect to dependent claim 9, the additional limitations, when considered individually and as an ordered combination, do not recite additional elements outside of the abstract idea that integrate the judicial exception into a practical application, and do not amount to significantly more than the abstract idea. The claims fail to establish that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either alone or in combination, and the additional elements “user device” and “…system…” do no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, the claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more.
No Prior Art Rejection
Claims 2-18 and 20-21 overcome 35 U.S.C. 102/103 for the following reasons:
Based on prior art search results, the prior art of record neither anticipates nor renders obvious the claimed subject matter when viewed either as a whole, or an ordered combination. Specifically, the prior art of record does not teach the following limitation, when viewed in light of the other claimed elements, as an ordered combination:
wherein the linking results in a registration of the user device at the third-party transaction system.
Closest Prior Art of Record
The closest prior art of record includes:
Kortina
United States Patent Application Publication No. US 20140143145 A1 (Kortina).
Kortina discloses A method for transaction processing, the method comprising:
receiving a transaction request that originated from a user application executing on a user device associated with a user (Fig. 1, item ①; ¶40, in further view of Fig. 1, ref 102), at a token issuance and transaction system (payment gateway; Fig. 1, ref 104), for a transaction associated with a first representation of the user (device ID / unique identifier … for uniquely identifying the mobile device 102) at the token issuance and transaction system, (payment gateway; Fig. 1, ref 104, see also ¶¶40, 41; With respect to the transaction of “for a transaction” limitation, see circled steps 2-4)
Examiner’s Note: Examiner takes the stance that claim language “…for a transaction associated with a first representation of a user at the token issuance and transaction system…” is recitation of intended use, and has limited patentable weight.
the transaction request associated with a third-party transaction system (Retail Mobile App; Fig. 1, ref 108; Retail Mobile App of an eWallet vendor, ¶7) different from the token issuance and transaction system (payment gateway; Fig. 1, ref 104),
PNG
media_image1.png
638
845
media_image1.png
Greyscale
wherein the transaction is between the user (of device 102) and a merchant, (See at least ¶¶5,11-13)
[0005] … When merchants conduct transactions using a credit card number, a variety of information is requested from the card holder….
[0011] In order for the third party transaction support solution to achieve a strong level of adoption by both merchants and their customers, the process for registering payment instruments with the intermediary party, in some implementations, is designed to include as few extra steps beyond a typical merchant checkout experience as possible. For example, rather than presenting the customer with registration steps including creating a new username, password, and email address to register the customer with the intermediary party service, in some implementations, the intermediary party service automates (or semi-automates) the registration process by saving a portion of the information related to the payment instrument (e.g., previously entered by the customer via a merchant software application). For example, the automated registration process may be initiated through the customer agreeing to save the payment instrument information with the intermediary party (e.g., via selecting an accept control in a user interface generated by a software library provided by the intermediary party). In some implementations, to uniquely identify the customer, the intermediary party may derive identifying information from the customer computing device (e.g., a unique device identifier, telephone number, unique identifier associated with the intermediary party software library installed upon the customer computing device, etc.).
[0012] In some implementations, unique identifying information is stored to the customer computing device. After registration of a customer with the intermediary party service, in some implementations, the customer can be automatically identified based upon information derived from and/or stored to the customer computing device. The identification, in some implementations, is made regardless of whether the customer is accessing a same merchant service (e.g., same merchant software application) or a different merchant service (e.g., a software application supplied by a second merchant registered with the intermediary service). In this manner, the intermediary party service may automatically look up saved payment instrument information related to the identified customer. In some implementations, the intermediary party service prompts the customer for authentication information prior to providing information regarding stored payment instruments. For example, the customer may be prompted, via a user interface, to enter a security code. Upon receipt of the security code, the intermediary party service may validate the security code in relation to the saved payment instrument(s).
[0013] Furthermore, for ease of use, the third party transaction support solution, in some implementations, includes migration of registered payment instruments between member merchants. After registration of a payment instrument with the third party payment gateway, in some implementations, payment instrument information may change (e.g., updated expiration date, etc.). Upon addition or change of credit card information, in some implementations, the information is shared (e.g., upon user authorization) with the intermediary party.
and wherein the merchant (merchant, ¶¶5,11) is different from the third-party transaction system (Retail Mobile App; Fig. 1, ref 108; Retail Mobile App of an eWallet vendor, ¶7)) and the token issuance and transaction system (payment gateway; Fig. 1, ref 104), (See at least ¶7, “…application provided by the eWallet Vendor…” and ¶¶11, reasonably indicating the payment gateway is distinct from merchants and customers: “…In order for the third party transaction support solution to achieve a strong level of adoption by both merchants and their customers”)
[0007] … a user, when conducting electronic transactions, may register with an electronic wallet (eWallet) vendor. Through a computer application provided by the eWallet vendor, for example, the user may receive authorization for conducting a transaction….
[0011] … In order for the third party transaction support solution to achieve a strong level of adoption by both merchants and their customers, …
and wherein the transaction request comprises a first identity handle (Device ID) of the user at an identity platform (payment software library; Fig. 1, ref 110;) of the third-party transaction system (Retail Mobile App 108 (e.g., of an eWallet vendor)); (See Fig. 1, ①’s Device ID, ref 128; See also ¶40)
determining, based on the transaction request, that the user is managed via different user representations at the token issuance and transaction system and the third-party transaction system, respectively; (¶40; See also Fig. 5B, refs 554 and 556a, in further view of ¶¶80,81)
PNG
media_image2.png
529
741
media_image2.png
Greyscale
[0040] A user may install the retail mobile application 108 upon the mobile device 102 and initiate a transaction. The payment software library 110, in some implementations, provides a unique device identifier 128 to the payment gateway 104 to identify any payment instruments already registered to the payment gateway 104 by the mobile device 102. For example, the unique device identifier may include the telephone number of the mobile device 102, a unique device identifier configured by the manufacturer of the mobile device 102, or a unique identifier allocated by the retailer via the retail mobile application 108.
[0080] Turning to FIG. 5B, an example method 550 for conducting a transaction with a registered credit card, in some implementations, begins with the entity application 502 requesting payment options (552a) from the entity server 504. The request may be provided by a payment software library portion of the entity application 502. The request, for example, may include information identifying the computing device executing the entity application 502. In some implementations, the entity server 504 forwards the request for payment options (552b) to the payment gateway 506. In other implementations, the entity application 502 communicates directly with the payment gateway 506.
[0081] In some implementations, the payment gateway 506 attempts to identify payment instruments registered with the computing device (554). The payment gateway, in some implementations, provides codes associated with one or more registered payment options (556a) to the entity server 504. In some implementations, the codes are each unique tokens previously generated by the payment gateway 506 to identify the registered payment options. In some implementations, the codes include information used to uniquely identify information (e.g., stored tokens, stored public information) related to the payment options. The unique identification information, for example, may be t stored by the entity server 504 or by the computing device executing the entity application 502.
determining, based on the transaction request, that the user is authenticated via the different user representations at both the token issuance and transaction system and the third-party transaction system; (¶40; See also Fig. 5B, refs 554 and 556a, in further view of ¶81)
Examiner’s Note: Examiner takes the stance that the above disclosure of Kortina implicitly discloses “that the user is authenticated via the different user system representations”, as the codes themselves are representative of prior authorizations identifying corresponding registered payment options – see ¶13: “…the information is shared (e.g., upon user authorization) …”. Similarly, see ¶14: “… If the user wishes to use the stored credit card information to perform a transaction with the second retailer, the user can authorize the intermediary party to share the stored credit card information via the software library embedded within the second retailer application so that the user does not have to manually enter all of the credit card information directly into a credit card entry form supplied by the second retailer….” and ¶22: “… prior to providing the one or more codes, requesting authorization to associate the one or more payment options with the retail entity identifier, and receiving authorization to associate the one or more payment options with the retail entity identifier.”.
determining, based on the transaction request, that the first representation of the user (device ID) is not yet linked with a second representation of the user at the third-party transaction system (payment instrument / options); (Fig. 5A, refs 512 and 514a, in further view of ¶72)
based on a determination that the first representation of the user (device ID) is not yet linked with the second representation of the user (a registered payment option / instrument; Fig. 5A, refs 512, 514a), linking, via a token (Unique Token; Fig. 5A, ref 528), the first representation of the user at the token issuance and transaction system (device ID at payment gateway 104; Fig. 5A, ref 534) and the second representation of the user at the third-party transaction system (payment instrument; Fig. 5A, ref 528);(See Fig. 5A, refs 514a, 518, 528, 534; ¶42)
[0042] If no cards are identified, a routine may be initiated by the retail mobile application 108 and a card storing engine 114 to collect and store information for a new payment instrument. The payment software library 110, in some implementations, includes one or more subprograms to encrypt and transmit payment instrument information to the payment gateway 104 for secure storage. The payment gateway 104, in some implementations, enables encryption of the information upon the mobile device 102 through an encryption key allocated to the retailer. The encryption mechanism, for example, may be described in U.S. patent application Ser. No. 13/633,106, entitled "Differential Client-Side Encryption of Information Originating from a Client", and filed Oct. 1, 2012, the contents of which are hereby incorporated by reference in its entirety.
wherein the token includes a second identity handle (Unique Token / Card ID; Fig. 5A, ref 528) that points to an account of the user at an identity platform (Fig. 1, ref 122, in further view of at least ¶41) of the token issuance and transaction system, (underlying accounts of the registered cards, having a unique card identifier, which may be identified via identity handles such as ¶43: “…a unique card identifier, a payment instrument type … the last four digits of the account number, and/or the expiration date…”, etc.; ¶44)
[0041] Each device identifier 124 within the payment gateway database 122, for example, may be associated with one or more card identifiers 126.
Examiner’s Note: Under broadest reasonable interpretation consistent with the specification, Examiner interprets the token and the second identity handle as one in the same. Examiner has not found support for “linking, via a token… wherein the token includes a second identity handle” where the token and second identity handle are disparate while the second identity handle constitutes a token – See ¶¶16,28,61 in further view of ¶¶58 of Applicant’s filed specification:
Exemplary Disclosure Showing linking via Tokens
¶16: “…The token may be used for … non-payment purposes (such as for linking user identities).”,
¶28: “…a link token, which can be one implementation of the link…”,
¶61: “…The transmitted link can be implemented as a link token.”
Exemplary Disclosure Showing linking via Handles
¶58: “In some embodiments, the TSP … can generate an identity handle indicating the link between the first representation at the first transaction system and the second representation at the second transaction system. An Account Identifier (AID) can serve as the identity handle…”
¶61: “…The transmitted link can be implemented as an identity handle 149 that points to the user account at the IdP of the TSP issuance and transaction system 110. The transmitted link can be implemented as an indication 149 of successful linking.”
I.e., Examiner fails to find support for “linking via a token”, where the token also “includes a second identity handle [disparate from the token]”, where the token and second identity handle are not co-extensive. As show above in the paragraphs of Applicant specification, Applicant specification does not appear to show Applicant contemplated a token which includes a second (disparate) identity handle. Most of these disclosures suggest them as alternatives for achieving / realizing the link. At best, Applicants appeared to have contemplated a system where both links and identity handles exist – see ¶64: “Each link 149 and/or identity handle can be associated with different scopes, e.g., that include transaction preferences”. Examiner’s stance is further supported by the fact Applicant’s specification does not once include a sentence with both “handle” and “token”10.
…a registration of the user device at the third-party transaction system (Fig. 5A, ref 534, in further view of Fig. 1 ref 124, and ¶¶12, 41 discloses the mobile device co-located with (i.e., “at the”) the mobile application (i.e., third party transaction system) is registered by the payment gateway 104 (i.e., the transaction issuance and transaction system)))
[0012] … unique identifying information is stored to the customer computing device. After registration of a customer with the intermediary party service11, … the customer can be automatically identified based upon information derived from and/or stored to the customer computing device. …
[0041] if a device identifier 128 has not yet been established, the payment software library 110 requests a unique identifier for the mobile device 102. For example, the payment gateway 104 may allocate a unique identifier (e.g., random number, string, etc.) for uniquely identifying the mobile device 102. The retail mobile application 108 may store the unique identifier in a memory location accessed by the payment software library 110 (e.g., a memory location available to any mobile application executing the functionality provided by the payment software library 110). The payment gateway 104, upon receipt of the device identifier 128, attempts to identify one or more stored (e.g., registered) cards using a card identification engine 116. For example, the card identification engine 116 may match the device identifier 128 to device identifiers 124 stored within a payment gateway database 122. Each device identifier 124 within the payment gateway database 122, for example, may be associated with one or more card identifiers 126. Although described in the following examples as operations performed in relation to a credit card, the card identifiers 126, in some examples, may include identifiers representing credit cards, debit cards, stored value cards, gift cards, and other electronic payment instruments.
and wherein the linking is performed at least in part by linking the first identity handle (unique identifier … for uniquely identifying the mobile device 102) to the second identity handle (unique card identifier / code; ¶41: “Each device identifier 124 within the payment gateway database 122, for example, may be associated with one or more card identifiers 126”; See also Fig. 5A, refs 528 & 534)
and wherein the linking is further performed at least in part by defining a transaction … [associations]… for the token; (Fig. 5A, ref 534); and
sending the token to the third-party transaction system; (Fig. 5A, refs 530, 532, “Forward Token…”; ¶79;)
Kortina fails to disclose:
and wherein the linking is further performed at least in part by defining a transaction scope for the token;
wherein the third-party transaction system is implemented as part of a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE),
wherein the linking results in a registration of the user device at the third-party transaction system
Dill
United States Patent Application Publication No. US 20150032626 A1 (Dill). Dill discloses the following deficiencies of Kortina:
and wherein … linking (between Token Requestor Identifier (¶75) and primary account number (PAN), via generating a token – see Fig. 4, refs 406, 404, and 402) is further performed at least in part by defining a transaction scope for the token (e.g., at least Fig 4, refs 408-418; see at least ¶¶55, 108, 167, Table 1);
¶55: “…’Token attributes’ may include any feature or information about a token. … token attributes may include any information that can determine how a token can be used … token attributes may include a type of token, frequency of use, token expiration date and/or expiration time … token attributes may include a wallet identifier associated with the token … a device identifier…a token requestor may provide token attributes at the time of generation of tokens…”
¶75: “…a token requestor identifier can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.,) with a token domain (e.g., e-commerce)”
¶104: “…the token registry may include a token requestor identifier and an account identifier (e.g., PAN) for each token.”
¶108: “…the token requestor 204 may send requests for multiple actions including token issuance … the token requestor 204 may send a token issuance request that includes a plurality of account identifiers (e.g., PANs) and a token requestor identifier. The network token system 202 may generate and return a plurality of tokens, where each token is associated with an account identifier (e.g., PAN) …In some embodiments, the token requestor 204 may optionally provide one or more token attributes with the request such as, for example … a token expiration date and/or time … expiration date, etc. ...the token requestor may further include one or more of an MSISDN … an alias … a UUID … an IMEI … IMSI…mobile application identifier …”
PNG
media_image3.png
611
795
media_image3.png
Greyscale
Table 1 (Exemplary Token Record Data in Token Registry): “Token Requestor Identifier … The token requestor identifier may restrict the token use to the token requestor associated with this identifier. A token requester identifier in the token registry database 202A may be matched with a token requestor identifier in an authorization request message in a transaction.”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the generated tokens of Kortina to include a transaction scope limiting the use of the generated tokens to the specified device, and any other desired limitations, as set in Dill, in order to advantageously increase the security of the tokens by limiting the domains by which they can be used.
Despite Kortina disclosing wherein the third-party transaction system (e.g., vendor eWallet app12 of Kortina) is implemented as part of … [a] user device, (¶7, in further view of ref 108 of Fig. 1 of Kortina), Kortina in view of Dill fails to disclose:
wherein the third-party transaction system is implemented as part of a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE).
wherein the linking results in a registration of the user device at the third-party transaction system
Krishnaiah
United States Patent Application Publication No. US 20160071094 A1 (Krishnaiah). Krishnaiah discloses the following deficiencies of Kortina in view of Dill:
wherein an electronic wallet app is implemented as part of a trusted execution environment on the user device via a Host Card Emulation (HCE), a Trusted Execution Environment (TEE), or a Secure Element (SE). (¶60: “…mobile wallet receiving dynamic mobile wallet tokens from wallet token service provider according to one embodiment. In an embodiment, dynamic tokens are implemented via Host Card Emulation (HCE) over NFC.”)
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have the application of Kortina utilize a HCE, resulting in the app of Kortina in view of Dill to be implemented as part of a trusted execution environment via a HCE, in order to advantageously increase the security of the mobile application of Kortina in view of Dill.
Kortina in view of Dill and Krishnaiah still fails to disclose (underline emphasis added, as Kortina generally discloses “a registration of the user device at the third-party transaction system”):
wherein the linking results in a registration of the user device at the third-party transaction system
Summary of Deficiencies in Closest Prior Art
Despite Kortina in view of Dill and Krishnaiah disclosing nearly every other claim limitation, there is realistically no reasonable basis by which it would be obvious for Kortina’s disclosed linking to result in registration of the user device at the third-party system (even in view of other potential prior art references found during search), as the linking process of Kortina necessarily requires the user device already being associated with the third-party transaction system (e.g., mobile application) as a prerequisite for the linking to occur (as shown in the above mapping).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 10990965 B2 (Levya). Levya discloses a single-sign on method involving a single sign-on link between a user account and a wallet application (abstract). At least Fig. 3 is relevant.
US 20130191227 A1 (Pasa). Pasa discloses a method for a user to access federated and/or non-federated cobranded wallets and partner-hosted wallets (abstract). Figs. 4A and 4B are relevant.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A MALKOWSKI whose telephone number is (313)446-6624. The examiner can normally be reached Monday - Friday, 9:00AM - 5:00PM ET.
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, Matthew Gart can be reached at (571) 272-3955. 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.
/M.A.M./Examiner, Art Unit 3696 /MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
1 I.e., the method claims.
2 The subject matter claimed.
3 Pages 10-11 of Remarks.
4 Examiner’s Note – ref 104 corresponds / is analogous to the claimed “token issuance and transaction system”.
5 See MPEP § 2106 I.
6 See MPEP §§ 2106.03 I, II.
7 See MPEP § 2106.04(a)(2) II
9 See MPEP § 2106.05.
10 Excepting originally filed claims 5 and 21, of which uses “token” in different context (referring to “token issuance and transaction system”, not a token).
11 ¶9 of Kortina: “… the intermediary party (e.g., payment gateway) [i.e., Fig. 1, ref 104]”
12 ¶7, in further view of Fig. 1, ref 108 of Kortina.
Prosecution Insights