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 .
Response to Arguments/Amendments
Regarding rejection of the claims under 35 USC 101, Applicant submits that the claims are not directed to an abstract idea but rather a specific technological architecture. The Examiner respectfully disagrees. While the claims may be directed to specific technological architecture such as the wallet server, SDK, mobile application, etc., these limitations constitute additional elements and are not considered during the abstract idea analysis under prong one of Step 2A. Additionally, Applicant’s argument that the claims provide a solution to the technical integration problem of distributed payment system architectures is not reflected in the claims. The only limitation that appears to be directed to the argued problem/solution is the generation of card push data “in accordance with a target token service provider.” However, there is no mention of how the push data is generated to specifically provide the claimed benefit nor is the “specialized” push data used in a particular manner by a target token service provider. Therefore, the claims remain directed to the abstract idea of card tokenization.
Applicant further submits that the claims integrate the alleged abstract idea into a practical application by providing technical improvements to efficiency and security. The Examiner respectfully disagrees. Applicant’s mere assertion that security is improved through use of the SDK to provide direct communication is insufficient. The additional elements such as a digital payment card, digital payment, mobile application, card push data, SDK and direct communication with the wallet server do no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. digital payment card, digital payment, card push data are merely substitutes for physical payments and payment card information and mobile application, SDK, and direct communication with the wallet server are merely generic software operations and functions programmed to carry out the abstract idea and executable upon any generic, off-the-shelf computing device). Furthermore, neither the computing device(s) performance nor functionality is clearly improved through implementation of these elements and any improvements to efficiency are merely improvements to the abstract idea itself rather than the computer(s) or technical field. Therefore, the claims fail to integrate the abstract idea into a practical application and the rejection is maintained.
Regarding rejection of claim 6 under 35 USC 103 over Arora in view of Kim, Applicant submits that the prior art does not disclose, funding card push data generated at the wallet server in accordance with a target token service provider. The Examiner respectfully disagrees. Paragraph 0057 of Arora discloses generating a payment token (i.e. funding card push data) configured for use specifically with a particular e-commerce merchant and may further include a pre-determined expiry time. While Arora does not explicitly disclose configuring the token in accordance with a “target token service provider,” under broadest reasonable interpretation the target token service provider can be any service provider, such as the e-commerce merchant, and configuring the push data/payment token “in accordance with” a particular service provider would be performed the same whether the service provider is an e-commerce merchant or a token service provider.
Applicant further submits that Arora in view of Kim does not disclose, an SDK incorporated in the mobile application of the card issuer and managed by an entity controlling the wallet server. The Examiner respectfully disagrees. Paragraphs 0199, 0207, and 0254 of Kim disclose multiple SDKs, including an SDK related to the card company/issuer operating the payment server, being installed on the mobile device and associated with the payment application/payment manager.
Applicant further submits that Arora in view of Kim does not disclose a data flow in which the wallet server sends funding card push data to the card issuer, the card issuer forwards the push data to the mobile application, and the wallet server receives it back from the SDK. The Examiner respectfully disagrees. Paragraphs 0058-0059 of Arora disclose the payment token being transmitted from the payment network server to the issuer server who then forwards the token to the issuer application. From there, the issuer application submits the payment token to the e-commerce site which will route a transaction request including the token back to the payment network server. Under broadest reasonable interpretation, the claim does not require the direct transmission of the push data from the mobile application to the wallet server. Therefore, Arora discloses the funding card push data being received by the wallet server from the mobile device application. Therefore, the combination of Arora in view of Kim discloses all limitations of claim 6 and the rejection is maintained.
Regarding rejection of claim 14 under 35 USC 103 over Arora in view of Kim, Applicant submits that the prior art does not disclose an SDK incorporated in the mobile application of the card issuer and managed by an entity controlling the wallet server. The Examiner respectfully disagrees and submits the same rebuttal as above for claim 6 in paragraph 5.
Applicant further submits that Arora in view of Kim does not disclose a wallet server mediating communications between the mobile device and token service provider. The Examiner respectfully disagrees. Fig. 6, Fig. 15 and paragraphs 0140 and 0290-0294 of Kim disclose the payment server 620 (i.e. wallet server) acting as a middleman (i.e. mediating) for communications between the payment application/payment manager comprising multiple SDKs and the token server 630. As discussed above, Kim discloses that the SDKs operable by the payment application/payment manager may be associated with the payment server and that the payment server may be controlled by the associated card company/issuer. Furthermore, the operator of the server(s) would not affect how the mediation of communication is performed. Therefore, Kim discloses the argued limitation(s) and the rejection is maintained.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, paragraphs 0138 and 0140 of Kim provide one of ordinary skill in the art motivation to combine Kim with the teachings of Arora to allow easy customization of payment tools associated with a specific card company/technology. Furthermore, it would be obvious to one of ordinary skill in the art to combine Arora in view of Kim to provide various SDKs for integration into a single mobile application and use a middleman server associated with the various SDKs based on the motivation above (e.g. ease of use).
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 6-21 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 6-13 are directed to a method and claims 14-21 are directed to a method. Therefore, these claims fall within the four statutory categories of invention.
Claim 6 recites: A method of integrating a digital payment card with a card issuer mobile application provided by a card issuer, the method comprising:
at a wallet server:
receiving, from the card issuer, card identification information including a card identifier that identifies the digital payment card and an identifier of a cardholder associated with the digital payment card;
generating funding card push data in accordance with a target token service provider to be used for the digital payment based on the card identification information;
sending the funding card push data to the card issuer; and
receiving from a software development kit (SDK) incorporated in an instance of the mobile application installed on a mobile device, first information representative of funding card push data from the mobile device, wherein:
the SDK is managed by an entity controlling the wallet server,
the SDK is configured to directly communicate with the wallet server, and
the funding card push data is provided to the mobile application from the card issuer and includes an identifier associated with the mobile device.
(Additional elements emphasized in bold)
The above claim describes a process for receiving from a card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card; generating tokenized card information in accordance with a target token service provider to be used for payment based on the card identification information; sending the tokenized card information to the card issuer; and receiving first information representative of tokenized card information from a client, wherein the tokenized card information is provided to the client from the card issuer and includes an identifier associated with the client. Therefore, claim 6 is directed to the abstract idea of payment card tokenization which is grouped within the “certain methods of organizing human activity” grouping under the “fundamental economic principles and practices” sub-grouping of abstract ideas in prong one of step 2A. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04), the additional elements of the claim such as digital payment card, mobile application, wallet server, card push data, digital payment, SDK, mobile device, and direct communication with the wallet server merely uses a computer as a tool to perform an abstract idea. The use of a digital payment card, digital payment, mobile application, card push data, SDK and direct communication with the wallet server does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. digital payment card, digital payment, card push data are merely substitutes for physical payments and payment card information and mobile application, SDK, and direct communication with the wallet server are merely generic software operations and functions programmed to carry out the abstract idea and executable upon any generic, off-the-shelf computing device). Finally, the use of a processor/computer (wallet server, mobile device) as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B (See MPEP 2106.05), the additional elements of digital payment card, mobile application, wallet server, card push data, digital payment, SDK, mobile device, and direct communication with the wallet server do not amount to significantly more than the abstract idea. As discussed above, taking the claim elements separately, the use of a digital payment card, digital payment, mobile application, card push data, SDK and direct communication with the wallet server does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. digital payment card, digital payment, and card push data are merely substitutes for physical payments and payment card information while the mobile application, SDK, and direct communication with the wallet server are merely generic software applications and operations programmed to carry out the abstract idea and are executable upon any generic, off-the-shelf computing device). Finally, the use of a wallet server and mobile device does no more than use processors/computers as tools to implement and/or automate the abstract idea (i.e. “apply it”). Viewed as a whole, the combination of elements recited in the claims merely recite the concept of managing a digital wallet. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 7-13 further recite characteristics of data (e.g. types of card push data) and the additional elements of cipher and token service provider/token-based payment feature do no more than continue to generally link the abstract idea to a particular field of use. Accordingly, the dependent 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, the dependent claims are also not patent eligible.
Claim 14 recites: A method comprising:
receiving a request for a token-based payment feature at a wallet server, the request being received directly from a software development kit (SDK) incorporated in an instance of a mobile application of a card issuer installed at the mobile device, the SDK being provided and managed by an entity controlling the wallet server, and configured to directly communicate with the wallet server;
reconstructing card information that corresponds to the request based on a stored cipher of the card information;
submitting the card information and transaction information from the wallet server to a token service provider for use of the token-based payment feature, the wallet server mediating communications between the mobile device and the token service provider;
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information; and
forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer.
(Additional elements emphasized in bold)
The above claim describes a process for receiving at a middleman, from a client, a request for a tokenized payment card; submitting card and transaction information to a tokenization service provider, the middleman mediating communications between the client and the service provider; receiving a response from the tokenization service indicating a result of submitting the card and transaction information; and forwarding the result to the client. Therefore, claim 14 is directed to the abstract idea of payment card tokenization which is grouped within the “certain methods of organizing human activity” grouping under the “fundamental economic principles and practices” sub-grouping of abstract ideas in prong one of step 2A. Claim 14 is also directed to the abstract idea of deciphering (“reconstructing”) data using a cipher information which is grouped within the “mathematical concepts” grouping under the “mathematical calculations” sub-grouping of abstract ideas in prong one of step 2A. Accordingly, the claims recite an abstract idea (See MPEP 2106.04).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (See MPEP 2106.04), the additional elements of the claim such as token-based payment feature, wallet server, SDK, mobile device, mobile application, direct communication with the wallet server, and reconstructing card information based on a stored cipher merely uses a computer as a tool to perform an abstract idea. The use of token-based payment feature, SDK, mobile application, direct communication with the wallet server, and reconstructing card information based on a stored cipher does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. token-based payment feature is merely a substitute for physical payment card information while the mobile application, SDK, direct communication with the wallet server, and reconstructing card information based on a stored cipher are merely generic software applications and operations programmed to carry out the abstract idea and are executable upon any generic, off-the-shelf computing device). Finally, the use of a processor/computer (wallet server, mobile device, token service provider) as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B (See MPEP 2106.05), the additional elements of token-based payment feature, wallet server, SDK, mobile device, mobile application, direct communication with the wallet server, and reconstructing card information based on a stored cipher do not amount to significantly more than the abstract idea. As discussed above, taking the claim elements separately, the use of token-based payment feature, SDK, mobile application, direct communication with the wallet server, and reconstructing card information based on a stored cipher does no more than generally link the abstract idea to a particular field of use (e.g. digital payments and mobile devices) due to reciting such elements at no more than a high level of generality (e.g. token-based payment feature is merely a substitute for physical payment card information while the mobile application, SDK, direct communication with the wallet server, and reconstructing card information based on a stored cipher are merely generic software applications and operations programmed to carry out the abstract idea and are executable upon any generic, off-the-shelf computing device). Finally, the use of a wallet server and mobile device does no more than use processors/computers as tools to implement and/or automate the abstract idea (i.e. “apply it”). Viewed as a whole, the combination of elements recited in the claims merely recite the concept of digital payment card tokenization. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 15-21 further recite characteristics of data (e.g. types of requests and identifiers) and the additional elements of card push data and cipher do no more than continue to generally link the abstract idea to a particular field of use. Accordingly, the dependent 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, the dependent claims are also not patent eligible.
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.
Claims 6-13 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 6 recites, “generating funding card push data in accordance with a target token service provider.” Paragraph 0042 of the instant specification discloses, “The funding card push data can include, for example, specific funding card tokens or cryptograms required by a token service provider, and are generated at the wallet server 102 in accordance with the target token service provider to be used.” However, the specification does not disclose any specific types of tokens or cryptograms nor methods/algorithms for generating the push data “in accordance with the token service provider.” Therefore, claim 6 lacks disclosure within the specification of what algorithms are used for performing certain actions within the claims (MPEP 2161.01 I “In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed”).
Claims 7-13 are also rejected due to their dependence on at least claim 6.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites the limitation "the digital payment" in “generating funding card push data in accordance with a target token service provider to be used for the digital payment.” There is insufficient antecedent basis for this limitation in the claim.
Claims 7-13 are also rejected due to their dependence on at least claim 6.
Claim 14 recites the limitation "the mobile device" in “an instance of a mobile application of a card issuer installed at the mobile device.” There is insufficient antecedent basis for this limitation in the claim.
Claims 15-21 are also rejected due to their dependence on at least claim 14.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 6-21 are rejected under 35 U.S.C. 103 as being unpatentable over Arora (US 20190236592 "Arora") in view of Kim et al. (US 20170337542 "Kim").
Regarding claim 6, Arora discloses: A method of integrating a digital payment card with a card issuer mobile application provided by a card issuer, the method comprising:
at a wallet server ("payment network server"):
receiving from the card issuer, card identification information including a card identifier that identifies the digital payment card and an identifier of a cardholder associated with the digital payment card (Fig. 1-2, 0055-0057, 0062-0063);
generating funding card push data ("payment token") in accordance with a target token service provider (“e-commerce site of merchant”) to be used for the digital payment based on the card identification information (Fig. 1-2, 0057);
sending the funding card push data to the card issuer (Fig. 1-2, 0057-0058, 0064-0065);
receiving from... an instance of the mobile application installed on the mobile device, first information representative of funding card push data from the mobile device (Fig. 1-2, 0059, 0066), wherein:...the funding card push data is provided to the mobile application from the card issuer (0058-0059)...
Arora does not disclose: ...a software development kit (SDK) incorporated in an instance of the mobile application...wherein: the SDK is managed by an entity controlling the wallet server, the SDK is configured to directly communicate with the wallet server, and the funding card push data includes an identifier associated with the mobile device.
However, in the same field of endeavor, Kim discloses: ...a software development kit (SDK) (“payment manager” and “payment relay module”) incorporated in an instance of the mobile application...wherein: the SDK is managed by an entity controlling the wallet server, the SDK is configured to directly communicate with the wallet server (Fig. 6, Fig. 9, 0138, 0140, 0199, 0207, 0254), and the funding card push data includes an identifier associated with the mobile device (0178-0179, 0293, 0296).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 6 disclosed by Arora by including an SDK managed by and directly communicating with the wallet server as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to allow easy customization of payment tools associated with a specific card company and their technology (Kim 0138).
Regarding claim 7, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the mobile application is provided by the card issuer (0055).
Kim further discloses: wherein the SDK being provided by an entity controlling the wallet server for integration with the mobile application (Fig. 6, 0138, 0142, 0199, 0254)...
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 7 disclosed by Arora in view of Kim by including an SDK as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to allow easy customization of payment tools associated with a specific card company and their technology (Kim 0138).
Regarding claim 8, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the funding card push data includes at least one of a unique identifier of the payment card or a primary account number (PAN) and an expiry date of the payment card (0057, 0064).
Regarding claim 9, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the information representative of the funding card push data comprises the funding card push data (0059, 0064, 0066).
Regarding claim 10, Arora in view of Kim discloses all limitations of claim 6. Arora further discloses: wherein the information representative of the funding card push data includes a cipher of the funding card push data (0057, 0064).
Regarding claim 11, Arora in view of Kim discloses all limitations of claim 10. Kim further discloses: wherein the SDK retains second information representative of the funding card push data, and wherein reconstruction of the funding card push data at the SDK requires both the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 11 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 12, Arora in view of Kim discloses all limitations of claim 11. Kim further discloses: wherein the cipher comprises an exclusive-or operation executed on the funding card push data at the SDK to generate the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 12 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 13, Arora in view of Kim discloses all limitations of claim 6. Kim further discloses: receiving a request for a token-based payment feature at the wallet server, the request being received directly from the SDK (Fig. 6, 0138, 0142, 0199, 0254);
submitting card and transaction information from the wallet server to a token service provider for use of the token-based payment feature (Fig. 6, Fig. 15, 0290-0294);
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information (Fig. 15, 0304, 0308);
and forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer (Fig. 15, 0306, 0309).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 13 disclosed by Arora in view of Kim by including a token service provider as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to issue and manage payment information in a secure tokenized format (Kim 0143).
Regarding claim 14, Arora discloses: A method comprising:
receiving a request for a token-based payment feature at a wallet server (Fig. 1-2, 0055-0057, 0062-0064).
Kim further discloses: receiving a request for a token-based payment feature at a wallet server (“payment server”), the request being received directly from a software development kit (SDK) (“payment manager” and “payment relay module”) incorporated in an instance of a mobile application of a card issuer installed at the mobile device, the SDK being provided and managed by an entity controlling the wallet server, and configured to directly communicate with the wallet server (Fig. 6, Fig. 9, 0138, 0142, 0199, 0207, 0254);
reconstructing card information that corresponds to the request based on a stored cipher of the card information (Fig. 9, 0201, 0245);
submitting the card information and transaction information from the wallet server to a token service provider (“token server”) for use of the token-based payment feature, the wallet server mediating communications between the mobile device and the token service provider; (Fig. 6, Fig. 15, 0140, 0290-0294);
receiving, at the wallet server, a response from the token service provider indicating a result of submitting the card and transaction information (Fig. 15, 0304, 0308);
and forwarding the result to the mobile device via the SDK, the result being provided to the mobile application provided by the card issuer (Fig. 15, 0306, 0309).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 13 disclosed by Arora in view of Kim by including a token service provider and SDK as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to issue/manage payment information in a secure tokenized format and to allow easy customization of payment tools associated with a specific card company/technology (Kim 0138, 0143).
Regarding claim 15, Arora in view of Kim discloses all limitations of claim 14, Kim further discloses: receiving, at the SDK, a user request for use of a token-based payment feature provided by a token service provider via the mobile application (Fig. 6, 0138, 0142, 0199, 0254);
and receiving, at the SDK, user authentication information from a user of the mobile device, wherein receiving the user request and the user authentication information occurs prior to receiving the request at the wallet server (Fig. 15, 0293-0294, 0296).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 15 disclosed by Arora in view of Kim by including authentication information as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification as a simple substitution of one known element for another to obtain predictable results (KSR International Co. v. Teleflex Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007)).
Regarding claim 16, Arora in view of Kim discloses all limitations of claim 15. Arora in view of Kim does not disclose: wherein the request for the token-based payment feature is generated by the SDK at least in part based on successful authentication of the user via the user authentication information.
However, the above limitation contains intended result language and as such will not differentiate claims from the prior art. Applicant(s) are reminded that intended result language does not have patentable weight. See Texas Instruments Inc. v. International Trade Commission, 26 USPQ2d 1010 (Fed. Cir. 1993); Amazon.com Inc. v. Barnesandnoble.com Inc., 57 USPQ2d 1747 (CAFC 2001). ("A (whereby/wherein) clause that merely states the result of the limitations in the claim adds nothing to the patentability or substance of the claim"); Griffin v. Bertina, 62 USPQ2d 1431 (Fed. Cir. 2002).
Regarding claim 17, Arora in view of Kim discloses all limitations of claim 14. Arora further discloses: prior to receiving the request: receiving, at the wallet server from the card issuer, card identification information including a card identifier that identifies a payment card and an identifier of a cardholder associated with the payment card (Fig. 1-2, 0055-0057, 0062-0063);
sending, from the wallet server, card push data to the card issuer (Fig. 1-2, 0057-0058, 0064-0065);
and receiving first information representative of funding card push data from the mobile device (Fig. 1-2, 0059, 0066).
Kim further discloses: the funding card push data including an identifier associated with the mobile device (0178-0179, 0293, 0296).
Regarding claim 18, Arora in view of Kim discloses all limitations of claim 17. Arora in view of Kim fails to expressly disclose: wherein the identifier of the cardholder comprises at least one of a wallet identifier or a client identifier.
However, the difference between a cardholder identifier and a wallet or client identifier is only found in the non-functional descriptive material and is not functionally involved in the steps recited. The receiving card identification information step would be performed the same regardless of the descriptive material since none of the steps explicitly interact therewith. Limitations that are not functionally interrelated with the useful acts, structure, or properties of the claimed invention carry little or no patentable weight. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Ngai 367 F.3d 1336, 1339, 70 USPQ2d 1862 (Fed. Cir. 2004); In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP § 2111.05; Cf. In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983).
Therefore, it would also have been obvious to a person of ordinary skill in the art at the time of applicant' s invention to include any identification information because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention.
Regarding claim 19, Arora in view of Kim discloses all limitations of claim 17. Arora further discloses: wherein the information representative of the funding card push data includes a cipher of the funding card push data (0057, 0064)...
Kim further discloses: ...and wherein the SDK retains second information representative of the funding card push data (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including retaining representative card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 20, Arora in view of Kim discloses all limitations of claim 19. Kim further discloses: wherein reconstruction of the funding card push data at the SDK requires both the first information and the second information (Fig. 9, 0201, 0203).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
Regarding claim 21, Arora in view of Kim disclose all limitations of claim 17. Kim further discloses: in response to the request, providing information representative of funding card push data from the wallet server to the SDK (Fig. 15, 0297-0298);
and receiving reconstructed funding card push data from the SDK at the wallet server and providing the funding card push data as part of the card and transaction information to the token service provider (Fig. 15, 0301-0303), wherein reconstructed funding card push data is based on the information representative of the funding card push data stored at the wallet server and second information maintained at the SDK (Fig. 15, 0291-0292).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify claim 19 disclosed by Arora in view of Kim by including reconstructing card data as disclosed by Kim. One of ordinary skill in the art would have been motivated to make this modification to improve security of card data via encryption (Kim 0201).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR RAK whose telephone number is (571)270-1575. The examiner can normally be reached Monday-Friday 11:00-7:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W Hayes can be reached at (571)-272-6708. 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.
/T.R./Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights