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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1-8, filed on 09/26/2025 is acknowledged.
This communication is a Non-Final Office Action rejection on the merits. Claims 1-10 are currently pending and have been addressed below.
Examiner’s Comments
Claims 1, 3-5 and 8-9, is objected to because it does contain element that could invoke 112f,claim interpretation, if not amended. The claims contains the language “payment means” and/or “means of payment issuer”. There is not currently a function associated with these “means” so they do not invoke 112(f), but the examiner is providing this insight as a courtesy. Applicant is advised to amend this language to a language in the art, for example “payment instrument”, “payment card”, or “card issuer”, “payment card issuer”.
Optional Language/Contingent Limitation
The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. The broadest reasonable interpretations of a system (or apparatus or product) claim having structure that performs a functions, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016) (precedential) for an analysis of contingent claim limitations in the context of both method claims and system claims. See also MPEP 2111.04.
Claim 1 recites “if the identifying information of the holder of the payment means exists in the database, then:
searching the database for associations comprising brand tokens, merchants, payment means and identifying information of the holder of the payment means;
providing, via the interface, the associations together with a list of update options calculated on the basis of default management criteria and the associations found;”
Because the “searching…” and “providing…” steps may not occur, as they are predicated to the identifying information of the holder of the payment means exists in the database. This is a conditional limitation that doesn’t have patentable weight.
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-10, are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-7 are directed to a process (i.e., a method), and claims 8-10 is directed to a machine (i.e., system), therefore, these claims fall within the four statutory categories of invention. Thus, the eligibility analysis proceeds to Step 2A.1.
The limitations of independent claim 1, which is representative of independent claim 8, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
[A] A method for secure updating of payment means tokens, the method comprising:
[B] capturing data of a payment means and of a holder of the payment means;
[C] sending a request for a brand token for the payment means to a cloud system via an interface connected to the cloud system, wherein the request includes at least one piece of identifying information of the holder of the payment means;
[D] checking whether the identifying information of the holder of the payment means exists in a database contained in the cloud system;
[E] if the identifying information of the holder of the payment means exists in the database, then:
[F] searching the database for associations comprising brand tokens, merchants, payment means and identifying information of the holder of the payment means;
[G] providing, via the interface, the associations together with a list of update options calculated on the basis of default management criteria and the associations found;
[H] requesting a new brand token for each of the associations from a means of payment issuer via the cloud system;
[I] sending the new brand token to the respective merchants via the cloud system and for each of the associations.
Limitations A-I under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically recites managing a commercial or legal interaction (e.g., updating of payment means tokens, capturing data of a payment means, sending a request for a brand token, identifying information of the holder of the payment means, checking, searching, providing, and sending the new brand token to the respective merchants for each associations). For example, the disclosure establishes following rules or instructions to update payment information at many merchants when a user gets a new payment instrument, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas. Therefore, limitations A and I recite at least one abstract idea.
Accordingly, claim 1, recite at least one abstract idea and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular,
claim 1, recites the additional elements in bold below:
[A] A method for secure updating of payment means tokens, the method comprising:
[B] capturing data of a payment means and of a holder of the payment means;
[C] sending a request for a brand token for the payment means to a cloud system via an interface connected to the cloud system, wherein the request includes at least one piece of identifying information of the holder of the payment means;
[D] checking whether the identifying information of the holder of the payment means exists in a database contained in the cloud system;
[E] if the identifying information of the holder of the payment means exists in the database, then:
[F] searching the database for associations comprising brand tokens, merchants, payment means and identifying information of the holder of the payment means;
[G] providing, via the interface, the associations together with a list of update options calculated on the basis of default management criteria and the associations found;
[H] requesting a new brand token for each of the associations from a means of payment issuer via the cloud system;
[I] sending the new brand token to the respective merchants via the cloud system and for each of the associations.
[J] And also, claim 8 recites a system for securely updating payment means tokens, characterised in that it comprises the system comprising at least one interface, a cloud system and a means of payment issuer, wherein the cloud system (1) comprises at least one database that stores associations comprising brand tokens merchants and identifying information of holders of the payment means.
The additional elements (“a cloud system via an interface”, “payment issuer via the cloud system”, “a system for securely updating payment means tokens, characterised in that it comprises the system comprising at least one interface, a cloud system and a means of payment issuer, wherein the cloud system (1) comprises at least one database that stores associations comprising brand tokens merchants and identifying information of holders of the payment means”), are no more than a generic computer performing operations to automate the updating payment instrument transaction. Also, the additional elements of “an interface”, this identify the data to which the abstract idea applies as being “digital” or “electronic,” which is a general link to a technological environment. When the additional elements are considered individually and as an ordered combination, the claim as a whole, amounts to no more than or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment (e.g., “a cloud system via an interface”, “payment issuer via the cloud system”, “a system for securely updating payment means tokens, characterised in that it comprises the system comprising at least one interface, a cloud system and a means of payment issuer, wherein the cloud system (1) comprises at least one database that stores associations comprising brand tokens merchants and identifying information of holders of the payment means”), defined by high level recitations of a computer/a decentralized distributed ledger and the Internet. Additionally, the additional element of (“an interface”) which are mere data used for automation of manual processes, such as using a generic computer to process an application for updating a payment instrument transaction. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an
instruction to “apply it” on a computer. This is not enough to provide an inventive
concept. Therefore, claims 1 and 8 are not patent eligible.
Dependent claims 2-6, further recites further comprising: updating the associations with the new brand token in the database; wherein characterised in that the list of update options comprises: updating all the brand tokens with the payment
means; updating the brand tokens selected by the holder of the payment means; not updating any brand tokens; wherein characterised in that the identifying information of the holder of the payment means is the MainID; further comprising enabling the holder of the payment means to use the interface via a personal blockchain ID; enabling the merchant to use the interface via encrypted authentication. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing legal/commercial behavior. For example, the claims establish updating payment instrument with the each identifying information, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. The claims do not recite any new additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, claims 2-4 are not patent eligible.
Dependent claims 7 and 9-10, further recites further comprising: enabling an external data source communicated with the cloud system to use the interface via encrypted authentication; wherein the interface, the cloud system and the means of payment issuer are interconnected by means of encryption protocols; wherein the encryption protocol is selected from TLS1.2 and TLS1.3. Under the broadest reasonable interpretation covers steps or functions of certain methods of organizing human activity, specifically managing legal/commercial behavior, and mathematical concept. For example, the claims establish obfuscating received external input data and distributed among other associated entities, which is a form of commercial and legal activities, fits squarely within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of Step 2A. As discussed under Step 2A.2, the additional element(s) of “the interface, the cloud system and the means of payment issuer” amount to no more than generally link the abstract idea to a technological environment through “instructions” processed or performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept.
The claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, claims 7 and 9-10 are not patent eligible.
In summary, the dependent claims considered both individually and as an
ordered combination do not provide meaningful limitations to transform the abstract idea
into a patent eligible application of the abstract idea such that the claims amount to
significantly more than the abstract idea itself. The claims do not recite an improvement
to another technology or technical field, an improvement to the functioning of the
computer itself, or provide meaningful limitations beyond generally linking an abstract
idea to a particular technological environment. Therefore, the claims 1-10, are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Best et al., (US 20160189121 A1) in view of McCandless et al., (US 20180268400 A1).
With respect to claims 1 and 8, Best teaches a method and system for securely updating payment means […], the system comprising at least one interface, a cloud system and a means of payment issuer, wherein the cloud system comprises at least one database that stores associations comprising brand […] merchants and identifying information of holders of the payment means {see at least Fig., 1 ¶¶ 0035, 0039-0040}, the method comprising:
capturing data of a payment means and of a holder of the payment means {see at least Fig., 3E item 341-342 ¶ 0028 “…The method might comprise providing a user interface to a user device associated with a user via an account management application running on the user device, the user interface enabling the user to manage a plurality of user accounts with vendors, the plurality of user accounts being associated with the user. The method might also comprise receiving, with the user interface of the account management application, a first set of inputs and a second set of inputs, from the user…”, ¶ 0050 “…With reference to FIG. 2A, method 200 might comprise receiving, with a computer (e.g., with server 115 and/or server 155 shown in FIG. 1) and from a user (e.g., with user device(s) 105 shown in FIG. 1), a first set of inputs comprising instructions to push payment information associated with the user (block 205), and receiving, with the computer and from the user, a second set of inputs comprising instructions indicating two or more user accounts (which are associated with the user), with which the payment information is to be updated (block 210)…”}.
checking whether the identifying information of the holder of the payment means exists in a database contained in the cloud system {see at least ¶0047 “…data associated with user account(s) with a management service provider (with which server 115 might be associated), data associated with user account(s) with one or more financial institutions (with which financial institutions' servers 155 might be associated), data associated with one or more vendors 135 (with which servers 140 might be associated), data associated with one or more credit cards (with which the user might be associated), and/or data associated with billing information (with which the user might be associated) might be collected by the two or more user devices 105, by server 115, by server 155, or by any combination of these computing devices. The database 130 (and/or database 160) might store some or all of these collected data”, also “Fig., 3A item 301 ¶¶ 0053, 0063 “…FIG. 3A, Method 300 might comprise logging into a user account for managing vendor accounts and/or for managing card and/or payment information on various vendor accounts on various vendor websites (block 301). In some cases, the user account might be an account for a card/payment management system of a card/payment management service provider. According to some embodiments, managing card information (and/or payment information) on various vendor accounts might be implemented in a “card-not-present” scenario, such as by logging into or otherwise accessing the various vendor accounts on various vendor websites. In some cases, managing card information (and/or payment information) might be implemented in a “card present” scenario, such as by presenting the card (and/or account information) to a representative of a vendor in a store or other physical location associated with the vendor (e.g., presenting a credit card issued in the name of a retail store to a cashier at the retail store, in order to manage card and/or payment information, or the like). At block 302, method 300 might comprise providing the user with access to the user account, with a remote computer system(s) (e.g., server 115 shown in FIG. 1, which might be associated with the card/payment management service provider). At block 303, a determination may be made by the remote computer system(s) as to whether any vendor account has been setup for the user. If so, the process proceeds to block 331 (following marker “D”). If not, the process proceeds to block 304 (following marker “A”)”}.
if the identifying information of the holder of the payment means exists in
the database, then:
searching the database for associations comprising […], merchants, payment means and identifying information of the holder of the payment means {see at least ¶¶ 0047, 0053, 0068 “Turning to block 314, the remote computer system(s) might request, of the user, the user's credentials for accessing the user's account(s) on the vendor website or server, which request might be received by the user, at block 315. When the user provides the user's vendor credentials (block 316), the remote computer system(s) might relay the user's vendor credentials to the vendor website or server (block 317), which receives and validates the user's vendor credentials (block 318)”, ¶ 0069 If the vendor website or server determines, at block 319, that the user credentials are valid, the process proceeds to block 320 (following marker “B” to FIG. 3C). At block 320, the vendor website or server might send a notification that the user credentials are valid…”}.
providing, via the interface, the associations together with a list of update options calculated on the basis of default management criteria and the associations found {see at least ¶ 0028 “…The method might comprise providing a user interface to a user device associated with a user via an account management application running on the user device, the user interface enabling the user to manage a plurality of user accounts with vendors, the plurality of user accounts being associated with the user…”, ¶ 0035 “In some instances, automatically concurrently pushing the payment information might comprise automatically concurrently pushing the payment information to the two or more user accounts corresponding to the at least two vendor websites of the plurality of vendor websites, via application programming interfaces (“APIs”) associated with each of the corresponding at least two vendor websites. According to some embodiments, automatically concurrently pushing the payment information to the two or more user accounts corresponding to the at least two vendor websites of the plurality of vendor websites, via APIs associated with each of the corresponding at least two vendor websites…”, and ¶ 0052 “…when accessing the user's account on the computer—that is, a card/payment management service provider system (e.g., server 115 of FIG. 1) or a financial institution's system (e.g., server 155 of FIG. 1)—the user might be provided a list of existing vendor websites (of which the user has previously provided account information and user credentials, and of which the card/payment management service provider has established a connection/relationship/etc.) and a list of accounts for each existing vendor website associated with the user, and the user might be given the option to select one or more of the listed vendors and one or more of the listed accounts”}.
sending the new […] {e.g., new payment card information} to the respective merchants via the cloud system and for each of the associations {see at least Fig., 3D step 337-340 ¶ 0075 “…the process proceeds to block 335, at which the remote computer system(s) might store the new credit card information in the database. At block 336, the database might store the new credit card information in relation to the selected account(s) and/or selected vendor(s). The remote computer system(s) might, at block 337, push the new credit card information to all selected accounts of all selected vendors, resulting in the credit card information being added for selected accounts for each selected vendor…”}.
requesting a new […] {e.g., new payment card information} for each of the associations from a means of payment issuer via the cloud system {see at least Fig., 3E step 341-347 ¶ 0076 “…the user selects the option to update information for a credit card for selected accounts of selected vendors (block 341; following marker “K” to FIG. 3E), the process proceeds to block 342, at which the remote computer system(s) might store the updated credit card information in the database. At block 343, the database might store the updated credit card information in relation to the selected account(s) and/or selected vendor(s). The remote computer system(s) might, at block 344, push the updated credit card information to all selected accounts of all selected vendors, resulting in the credit card information being updated for selected accounts for each selected vendor (block 345). At block 346, the vendor website or server might notify the user of the update of the credit card information…”}.
Best does not explicitly disclose generating a “token” corresponding to the payment means, and
sending a request for a brand token for the payment means to a cloud system via an interface connected to the cloud system, wherein the request includes at least one piece of identifying information of the holder of the payment means;
However, McCandless discloses generating a “token” corresponding to the payment means {see at least ¶ 0019 “In the exemplary embodiment, to use the electronic wallet application, an accountholder first registers the payment card account with the electronic wallet application on the user computing device hosting the electronic wallet application. Registering the payment card account with the electronic wallet application may include a payment processor first generating a “token” corresponding to the payment card account. In at least some implementations, the token is a computer-generated alphanumeric string of predetermined length, or it may be a hash value, a key number, a purely numeric or purely alphabetic string, a code sequence, a binary or hexadecimal character sequence, or the like. The payment processor transmits the token to the user computing device for storage. The user computing device stores the token and the association between the token and the payment card account. In one embodiment, the user computing device stores the token in its local memory as well as the primary account number (PAN) associated with the payment card account. In another embodiment, the user computing device stores only the token and the PAN is stored within payment processor computers in addition to the token“, and also ¶ 0075 “…CAM API 630 transmits this list to e-wallet application 620 to inform the accountholder that the merchants on the list will need to update their stored payment card information. In one embodiment, CAMP API 630 transmits this list and requests permission from the accountholder to notify each merchant of the compromise and provide each merchant with the updated card information, such as a new PAN generated by issuing bank 640. Alternatively, CAM API 630 simply transmits this list for the accountholder to notify each merchant himself”}.
sending a request for a brand token [e.g., Visa card token] for the payment means to a cloud system via an interface connected to the cloud system, wherein the request includes at least one piece of identifying information of the holder of the payment means {see at least ¶¶ 0019-0020 “The electronic wallet application is configured to transmit and receive signals from compatible point-of-sale (POS) devices in order to perform payment card transactions. A payment card transaction may involve a user selecting a card or account from the electronic wallet application on the user computing device, with the user computing device… the user computing device transmits the token in lieu of the primary account number (PAN) to a POS device and then on to the payment processor. The payment processor uses the token to look up the PAN and transmits that to the financial institution, to continue the transaction”, ¶ 0068 “…an accountholder (such as accountholder 201 in FIG. 2) presses, taps, or otherwise activates a feature called “LOST MY PLASTIC.” In the exemplary embodiment, this is a button that can be pressed as part of, for example, a software application on a user computing device display. Pressing the button initiates a communication to CAM API 630. The communication at 602 includes at least an account identifier for one or more of the accountholder's accounts, such as a token, a hash, a key number, or some other alphanumeric identifier that is stored on the accountholder's device in lieu of the account's primary account number (PAN). The communication at 602 may also include details of the compromise incident such as type of compromise. CAM API 630 may also be configured to receive a date/timestamp and GPS-based location of the computing device at the instant the “LOST MY PLASTIC” button was pressed”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best to include the elements of McCandless. One would have been motivated to do so, in order to have a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument. McCandless is merely relied upon to illustrate the functionality of having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, as well as having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless.
With respect to claim 2, Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Best discloses, further comprising updating the associations with the new brand […] {e.g., new payment Instrument} in the database {see at least Fig., 3E step 341-347 ¶ 0076 “…the user selects the option to update information for a credit card for selected accounts of selected vendors (block 341; following marker “K” to FIG. 3E), the process proceeds to block 342, at which the remote computer system(s) might store the updated credit card information in the database. At block 343, the database might store the updated credit card information in relation to the selected account(s) and/or selected vendor(s). The remote computer system(s) might, at block 344, push the updated credit card information to all selected accounts of all selected vendors, resulting in the credit card information being updated for selected accounts for each selected vendor (block 345). At block 346, the vendor website or server might notify the user of the update of the credit card information…”}.
And McCandless further discloses generating a “token” corresponding to the payment means {see at least ¶¶ 0019, 0075}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best to include the elements of McCandless. One would have been motivated to do so, in order to have a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument. McCandless is merely relied upon to illustrate the functionality of having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, as well as having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless.
With respect to claim 3, Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Best discloses, wherein characterised in that the list of update options comprises:
updating all the brand […]{e.g., new payment Instrument} with the payment means; updating the brand […] selected by the holder of the payment means; not updating any brand […] {see at least Fig., 3E step 341-347 ¶¶ 0050, 0052, 0075-0076 “…instructions indicating which of a plurality of vendors the user intends to update payment information with (i.e., "selected vendor(s)") and instructions indicating which account(s) with the selected vendor(s) the user intends to update payment information with, the user might be provided a list of existing vendor websites (of which the user has previously provided account information and user credentials, and of which the card/payment management service provider has established a connection/relationship/etc.) and a list of accounts for each existing vendor website associated with the user, and the user might be given the option to select one or more of the listed vendors and one or more of the listed accounts, the remote computer system(s) might store the new credit card information in the database, the remote computer system(s) might store the updated credit card information in the database. At block 343, the database might store the updated credit card information in relation to the selected account(s) and/or selected vendor(s)"}.
And McCandless further discloses generating a “token” corresponding to the payment means {see at least ¶¶ 0019, 0075}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best to include the elements of McCandless. One would have been motivated to do so, in order to have a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument. McCandless is merely relied upon to illustrate the functionality of having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, as well as having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless.
With respect to claim 4, Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above.
Furthermore, McCandless discloses, wherein characterised in that the identifying information of the holder of the payment means is the MainID {see at least ¶ 0069 “…The communication at 602 includes at least an account identifier for one or more of the accountholder's accounts, such as a token, a hash, a key number, or some other alphanumeric identifier that is stored on the accountholder's device in lieu of the account's primary account number (PAN). The communication at 602 may also include details of the compromise incident such as type of compromise. CAM API 630 may also be configured to receive a date/timestamp and GPS-based location of the computing device at the instant the “LOST MY PLASTIC” button was pressed”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best to include the elements of McCandless. One would have been motivated to do so, in order to have a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument. McCandless is merely relied upon to illustrate the functionality of having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, as well as having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless.
Claims 5 - 7 are rejected under 35 U.S.C. 103 as being unpatentable over Best et al., (US 20160189121 A1) in view of McCandless et al., (US 20180268400 A1) and further in view of Sead Muftic (US Pat. 9,635,000 B1).
With respect to claim 5, the combination of Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above, but Best in view of McCandless does not explicitly disclose further comprising enabling the holder of the payment means to use the interface via a personal blockchain ID.
However, Muftic discloses, further comprising enabling the holder of the payment means to use the interface via a personal blockchain ID {see at least Abstract “The invention describes an identity management system (IDMS) based on the concept of peer-to-peer protocols and the public identities ledger. The system manages digital identities, which are digital objects that contain attributes used for the identification of persons and other entities in an IT system and for making identity claims. The identity objects are encoded and cryptographically encapsulated. Identity management protocols include the creation of identities, the validation of their binding to real-world entities, and their secure and reliable storage, protection, distribution, verification, updates, and use”, col 6 lines 1-10 “In conclusion, the essence of the blockchain in the Bitcoin system is to make available and to guarantee the correctness of all transactions in the system and to provide the mechanisms to validate their correctness. Interpreting these two features formally and applying them to an IDMS leads to the conclusions that (a) the identities of individual entities can be included in the blockchain and thus be available to the entire community, and (b) identities and their blocks should be hashed
and signed based on proof-of-work by miners, so that their content is guaranteed”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best in view of McCandless to include the elements of Muftic. One would have been motivated to do so, in order to have a blockchain identity management system (IDMS). Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument, and McCandless discloses having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Muftic is merely relied upon to illustrate the functionality of having a blockchain identity management system, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, and having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument as well as, having a blockchain identity management system, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless, and in view of Muftic, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless/Muftic.
With respect to claim 6, the combination of Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above, but Best in view of McCandless does not explicitly disclose further comprising enabling the merchant to use the interface via encrypted authentication.
However, Muftic discloses further comprising enabling the merchant to use the interface via encrypted authentication {see at least Abstract, col 2 lines 43-55 “it is also important to maintain and guarantee the correctness, integrity, and continuous availability of data. In distributed, large-scale environments, the components and protocols for using them— federation—are very complicated. For an IDMS, its protection, authenticated access, secure administration, and authorized use are important considerations. Because identification data must be protected when transferred outside of the security perimeter, a centralized IDMS is very expensive to establish, maintain, operate, and protect. Finally, all participants in an IT system must place a high level of trust in the correct operation and accuracy of the data stored in, and distributed by, an IDMS… in addition to identifying system entities, the data stored in an IDMS are often also used for other security services, such as the authentication, authorization, management of secret keys, and others. At the time of this invention, the security services always required users sensitive and secret data to be stored in IDMS repositories”, also col 6 lines 1-10}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Best in view of McCandless to include the elements of Muftic. One would have been motivated to do so, in order to have a blockchain identity management system (IDMS) authenticated access. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument, and McCandless discloses having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Muftic is merely relied upon to illustrate the functionality of having a blockchain identity management system authenticated access, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, and having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument as well as, having a blockchain identity management system authenticated access, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless, and in view of Muftic, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless/Muftic.
With respect to claim 7, the combination of Best in view of McCandless teaches all the subject matter as disclosed in claim 1 above, but Best in view of McCandless does not explicitly disclose further comprising enabling an external data source communicated with the cloud system to use the interface via encrypted authentication.
Furthermore, Best discloses, further comprising enabling an external data source
communicated with the cloud system to use the interface via […] authentication {see at least ¶ 0068 “…When the user provides the user's vendor credentials (block 316), the remote computer system(s) might relay the user's vendor credentials to the vendor website or server (block 317), which receives and validates the user's vendor credentials (block 318)”, ¶ 0069 “If the vendor website or server determines, at block 319, that the user credentials are valid, the process proceeds to block 320 (following marker “B” to FIG. 3C). At block 320, the vendor website or server might send a notification that the user credentials are valid, which, at block 321, might be received by the remote computer system(s). The remote computer system(s) might, at block 322, store the user credentials and notify the user, resulting in the user credentials being stored in association with the vendor information (and/or with the user's account with the card/payment management service provider)”, ¶ 0087 “The list of vendors represents that each listed vendor has an existing connection or relationship with the card/payment management service provider. In some cases, the vendor(s) might have provided the card/payment management service provider with an application programming interface (“API”) for ease of transfer of information between server(s) of the vendor(s) and the remote computer system(s) of the card/payment management service provider…”, ¶ 0104 “…providing a user interface to a user device associated with a user via an account management application running on the user device, the user interface enabling the user to manage a plurality of user accounts with vendors, with the plurality of user accounts being associated with the user”}.
Best does not explicitly disclose the communications are encrypted.
However, Muftic further discloses the communications are encrypted (see at least col 11 lines 14-22 “If the communication between BIX system entities (in fact between their BIX Identities Agents) is indirect, then the BIX Synchronization System must be used in addition to BIX Identities Agents. One of its functions is to support secure (end-to-end encrypted) instant messages used to distribute identities objects and in that way update distributed instances of the global identities ledger, maintaining consensus for all participants of the global Synchronized state of the ledger”, and col 13 lines 23-29 “Upon activation of the BIX Identities Agent, the application displays the panel to specify local authentication (login) personal identification number (PIN)/password and then the registration panel. The login PIN/password is not stored in the system and is used is the seed in a special authentication protocol…”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify Best in view of McCandless to include the elements of Muftic. One would have been motivated to do so, in order to have a secured and encrypted communication and authenticated access. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument, and McCandless discloses having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument. Muftic is merely relied upon to illustrate the functionality of having a secured and encrypted communication and authenticated access, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, and having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument as well as, having a secured and encrypted communication and authenticated access, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless, and in view of Muftic, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless/Muftic.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Best et al., (US 20160189121 A1) in view of McCandless et al., (US 20180268400 A1) and in view of Sead Muftic (US Pat. 9,635,000 B1), and further in view of Debasish et al., an NPL - “Management of Security and Privacy Issues of Application development in Mobile Cloud Environment: A Survey”.
With respect to claim 9, the combination of Best in view of McCandless, and in view Muftic teaches all the subject matter as disclosed in claim 8 above.
Furthermore, Best discloses wherein the interface, the cloud system and the means of payment issuer are interconnected […] {see at least Fig., 1 ¶ 0030 “In some embodiments, automatically concurrently pushing the payment information to the two or more user accounts might comprise automatically concurrently pushing, with the account management application via a server computer in the one or more networks and over one or more networks in communication at least with the server computer and with each of the at least two vendor websites, the payment information to the two or more user accounts, in response to receiving the first and second sets of inputs from the user, each user account being associated with the two or more vendor websites. In some cases, the server computer might be associated with a web-based service provider. In some instances, the server computer might be associated with a financial institution”, ¶¶ 0039-0040}, but Best in view of McCandless, and in view Muftic, does not explicitly disclose “…are interconnected by means of encryption protocols”.
However, Debasish discloses “…are interconnected by means of encryption protocols” {see at least Section V, paragraph E “Cryptography is used to implement authentication and identity verification and to ensure confidentiality and integrity of data during transmission, processing or at rest… Therefore, avoid proprietary encryption algorithms, select proper key size as appropriate for the data being protected; for high assurance applications 256-bit symmetric keys and 2048-bit asymmetric keys are sufficient. Use secure communication such as TLS (Transport Layer Security)/SSL (Secure Socket Layer) or IPSec when data is in transit. Comply with regulatory and Government rules on encryption and key management for a specific country”, and also Section J, and Section K}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Best in view of McCandless, and in view of Muftic, to include the elements of Debashish. One would have been motivated to do so, in order to have a secured and encrypted communication protection policy implemented. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument, McCandless discloses having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, and Muftic discloses having a secured and encrypted communication and authenticated access. Debasish is merely relied upon to illustrate the functionality of having a secured and encrypted communication protection policy implemented, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, and having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, also having a secured and encrypted communication and authenticated access as well as, having a secured and encrypted communication protection policy implemented, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless, in view of Muftic, and in view of Debasish, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless/Muftic/Debasish.
With respect to claim 10, the combination of Best in view of McCandless, in view Muftic, in view of Debasish teaches all the subject matter as disclosed in claim 9 above.
Furthermore, Debasish discloses wherein the encryption protocol is selected
from TLS1.2 and TLS1.3. {see at least Section V, paragraph E “Cryptography is used to implement authentication and identity verification and to ensure confidentiality and integrity of data during transmission, processing or at rest… Therefore, avoid proprietary encryption algorithms, select proper key size as appropriate for the data being protected; for high assurance applications 256-bit symmetric keys and 2048-bit asymmetric keys are sufficient. Use secure communication such as TLS (Transport Layer Security)/SSL (Secure Socket Layer) or IPSec when data is in transit. Comply with regulatory and Government rules on encryption and key management for a specific country”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Best in view of McCandless, and in view of Muftic, to include the elements of Debashish. One would have been motivated to do so, in order to have a secured and encrypted communication protection policy implemented. Furthermore, Best discloses updating a payment instrument transaction at many merchants when a user get a new payment instrument, McCandless discloses having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, and Muftic discloses having a secured and encrypted communication and authenticated access. Debasish is merely relied upon to illustrate the functionality of having a secured and encrypted communication protection policy implemented, in the same or similar context. Because both updating a payment instrument transaction at many merchants when a user get a new payment instrument, and having a secured and protected payment instrument in a payment transaction by tokenizing the payment instrument, also having a secured and encrypted communication and authenticated access as well as, having a secured and encrypted communication protection policy implemented, are implemented through well-known computer technologies, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Best, in view of McCandless, in view of Muftic, and in view of Debasish, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Best/McCandless/Muftic/Debasish.
Conclusion
The prior art made of record and not relied upon:
1) (US Pat. 9990622 B2) – Choi et al., Authentication And Payment System And Method Using Mobile Communication Terminal - relates, in general, to an authentication and payment system and method using a mobile communication terminal and, more particularly, to an authentication and payment system and method using a mobile communication terminal, which separately processes authentication and approval using the terminal of a merchant (a mobile communication terminal, wired terminal or terminal connected via a leased line) and the mobile communication terminal of a purchaser without leaking payment information about the purchaser, in direct sales transactions between a merchant and a purchaser offline and mail order sales transactions using multimedia or printed media, such as terrestrial broadcasting, satellite broadcasting or catalogs.
2) (KR 20130153880 A) – Jeon Woo Jeong, Method and System for Totally Managing Electronic Payment Means – relates to a system and a method for the integrated management of an electronic payment means of an electronic payment means relay system to provide a service using the integrated electronic payment means.
3) (US 20200076884 A1) – Li et al., Methods and Apparatus for Performing Distributed Computing Using Blockchain – relates to distributed computing tasks, networks and methods which can be used to provide computing services through the use of computing nodes, e.g., without the need for a centralized control device to assign and distribute computation tasks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights