Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
2. Claims 1,3-5, 7-11,13-15 and 17-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. Patent Pub. 2004/0235450 to Rosenberg in view of U.S. Patent Pub. 2007/0075133 to Yeager and U.S. Patent Pub. 2006/0000900 to Fernandes.
Regarding claims 1 and 11 Rosenberg teaches a method for conducting a Near Field Communication (NFC) transaction using an NFC protocol, the method comprising:
maintaining an identification code associated with a user in a secure element memory, the secure element memory, a secure element processor and a secure element transceiver supporting a first communication channel comprising the NFC protocol included in a secure element embedded within the body of a mobile device (see sections [0052] to [0057], which teach storing a user account code in a “secure element” which is transmitted via NFC to the POS device and see Fig. 8 and sections [0096] to [0098], which shows the embodiment with the smartlink device embedded),
executing the secure element in response to an NFC inductive signal by an NFC terminal (see Figs. 3-5 and 9, and [0044], [0052], [0058], [0069] to [0071] and [0100] to [0108] of Rosenberg, which teach executing the payment application in the secure element upon receiving the POS inductive signal); and
wirelessly transmitting, a transaction request including the identification code associated with the user via the secure element transceiver over a first communication channel to the NFC terminal in response to the NFC inductive signal by the NFC terminal, wherein the transaction request including the identification code associated with the user is transmitted over a second communication channel that is different than the first communication channel to a remote server for processing the NFC transaction using a payment method maintained at the remote server that corresponds to the identification code associated with the user, wherein the NFC terminal and the first communication channel is configured to use the NFC protocol (see for example, Fig. 9 of Rosenberg, which teaches that the transaction is performed using the first NFC channel and the second channel is a cellular SMS channel to the server, as described in sections [0100] to [0108]).
Regarding the recited conventional features of a mobile device “the mobile device comprising of a mobile device memory, a mobile device processor, and a mobile device wireless transceiver”, although these features are present in the mobile phone of Rosenberg, as Rosenberg does not explicitly show them, Yeager is added.
In an analogous art, Yeager teaches an attachable adapter 100, which attaches to a mobile phone to enable NFC transactions to be performed. As shown in Fig. 2, the NFC adapter of Yeager includes the recited structures of the mobile device. See also sections [0021] to [0023], which teach that the NFC R2R adapter may function in any type of NFC mode, i.e. being a reading device or a writing device. See section [0029] which is for POS “payment without cash” software application, and see step 810 “Update Account on Adapter” as described in sections [0035] and [0036]. See also sections [0031] to [0035] of Yeager which teaches transmitting the account number 626 (which is the “identification code of the account associated with the user”) and is programmed into the attachable adapter 100) during the POS transaction using NFC.
Therefore, as Rosenberg and Yeager teach storing user account information in the secure element and also store this information in the backend financial server, and as Yeager explicitly teaches the conventional recited structures in a mobile device, it would have bene obvious to modify Rosenberg to use the structures of Yeager, as these components are essential to enabling wireless communications.
Regarding the feature of the “identification code associated with a user”, although sections [0006] and [0057] of Rosenberg teach sending an account number, section [0044] teaches a “unique identification code”, (and Yeager also teaches sending account numbers to the servers for each transaction), which is the “identification code” of the account and the account number would have to be “associated with a user”, Fernandes is added to more explicitly teach a “code associated with the user” per se.
In an analogous art, Fernandes teaches a personal trusted device (PTD or mobile device) which incorporates a secure element card which stores financial information and user information which allows a user to conduct an NFC transaction with a POS device. See for example, sections [0056] to [0059], which teach that server 60 stores each user’s data which includes codes associated with the user and each type of payment (after being received from the user’s personal trusted device (PTD)). See also section [0074], which explicitly teaches that the PTD stores “unique subscriber identity codes”. Fig. 21 and sections [0206] to [0210] also show user codes associated with payment methods for each merchant.
Therefore, as Rosenberg/Yeager teach storing user account information in the secure element and also store this information in the backend financial servers, and as Fernandes explicitly teaches storing a “unique subscriber identity code” and also transmits this code to the backend servers, it would have been obvious to modify Rosenberg/Yeager to use a code of this type for the reasons given in all these references which is that the properly identified user should be billed for their transaction.
Regarding the feature of claim 1 reciting: “a secure element processor configured to use NFC protocol”, see Fig. 2 and sections [0042] to [0046] of Rosenberg which show the direct connection between the processing chip 210 and antennas 250/260, where the communications from chip 210 to the POS device are NFC protocol signals. Chip 210 converts digital signals to NFC protocol for transmission and also receives NFC signals from the POS. See also claim 1 of Rosenberg, which recites “smartcard processor comprising: a first data channel being adapted to wirelessly communicate data between said smartcard processor and a third party (which is the POS) terminal...”.
As the above claimed features have remained the same (as was affirmed in the PTAB decision of 7-17-24) the newly added features are addressed below.
Regarding the new feature of “maintaining a secure element application configured to use an NFC protocol”, as described above, all of the Rosenberg, Yeager and Fernandes references use an NFC protocol application for their POS transactions.
See for example, sections [0044], [0052]-[0058], [0069] to [0071] and [0100] to [0108] of Rosenberg, which teach executing the “secure element” NFC payment application in the secure element upon receiving the POS/NFC signal, see sections [0029]-[0030] and Figs. 4-5 of Yeager, which teach the NFC reader device executing Master Card, Visa, Expresspay applications, and see sections [0003], [0041]-[0043], [0058], [0065], [0072], [0079]-[0082], [0089] to [0100] and [0105] of Fernandes, which teach the personal trusted device (PTD) storing NFC protocol applications used for the POS transactions (such as ISO/IEC 14443 which is NFC).
Regarding the new feature of “maintaining a mobile application”, this mobile application used by the mobile device itself may be an SMS texting application or any other type of application running on the mobile device. See for example, sections [0072], [0077], [0093], [0101] and [0108] of Rosenberg, which teach using an SMS mobile application, and sections [0047] to [0049], [0063] [0189] and [0192] of Fernandes, which teach storing and communicating with an SMS mobile application.
Regarding the newly added feature of a “coupon”, see sections [0009] and [0134]-[0135] of Rosenberg, see sections see sections [0029], [0031] and [0033]-[0034] of Yeager, and see sections [0048], [0083], [0103], [0149] and [0159] of Fernandes, which all teach the use of coupons.
Regarding the newly added feature (similar to the feature previously recited in claims 2 and 12) which recites “receiving at the mobile application on the mobile device a transaction response over the second communication channel”, as above, see Rosenberg Fig. 9, sections [0100] to [0108], which teach receiving an SMS “transaction response” receipt (SMS application is the newly recited “mobile application”).
Regarding claims 3 and 13 which recite “wherein the transaction response comprises at least one of a transaction number, receipt, ticket, coupon, or content”, as described above, the SMS response from the server in Rosenberg is a receipt, as recited.
Regarding claims 4 and 14 which recite “wherein the payment method is a credit card, debit card, or cash card”, Rosenberg teaches that the server performs credit card types of payments, as recited.
Regarding claims 5 and 15 which recite “further wherein based on information related to the identification code associated with the user, the NFC terminal transmits the identification code associated with the user to a specific remote server for processing the NFC transaction using the payment method maintained at the remote server that correspond to the identification code associated with the user”, as described above, see Figs. 5 and 9 and sections [0069]-[0071] and [0100]-[0108] of Rosenberg, and sections [0056] to [0059], [0074] and [0206] to [0210] of Fernandes, which teach that the backend financial servers store the user codes, as recited.
Regarding claims 7 and 17 which recite “further wherein the mobile application sends an alert to the remote server if it has not received the transaction response from the remote server within a certain period of time”, Fernandes teaches displaying the transaction amounts, and see for example, sections [0135] to [0137] of Fernandez which teach polling for confirmation and time-out periods. Therefore, as both Rosenberg and Yeager teach determining if receipts have been successfully received, it would have been obvious to modify the combination of references to include the “time-out” feature of Fernandes.
Regarding claims 8 and 18 which recite “further wherein the remote server is configured to store a single identification code associated with the user for a plurality of the user’s mobile devices and further wherein the configuration means the remote server scales”, see for example, section [0022] of Yeager, which teaches that the adapter may be used with any one of the plurality of user devices, as recited.
Regarding claims 9 and 19 which recite “further wherein after a payment has been processed by the remote server, the NFC terminal transmits a transaction response to the secure element via the NFC terminal during an NFC inductive interaction between the secure element and the NFC terminal”, see sections [0072] to [0077] and [0093] of Rosenberg and section [0049] of Fernandes, which teach that the secure element receives a receipt from the NFC terminal device, as recited.
Regarding claims 10 and 20 which recite “further wherein, the mobile application receives the transaction response from the secure element using an internal wired communication channel between the secure element and the mobile device”, see Fig. 8 and sections [0097] to [0099] of Rosenberg which teach that the secure element has a wired connection to the mobile device, as recited.
Claims 6 and 16 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over the references as applied to claims 1 and 11 above, and further in view of U.S. Patent Pub. 2005/0143051 to Park.
Regarding claims 6 and 16 which recite “further wherein, the transaction response is based on the remote server correlating the identification code associated with the user, information related to the payment method, information related to a user, information related to the NFC transaction, and information related to a transaction history”, as described above, see section [0052] of Rosenberg which teaches that the bank server stores all the recited types of information relating to the user except for a transaction history, although the bank servers of Rosenberg, Yeager and Fernandes would implicitly store the user’s transaction history, Park is added.
In an analogous art, Park teaches wireless POS transactions using a mobile terminal. The authentication process performed in the backend servers includes a transaction history. See for example, section [0073], which teaches using the stored purchase history along with the other stored information of the user and their account.
Therefore, as Rosenberg/Yeager teach the conventionality of using NFC attachable devices to perform POS transactions along with storing the user account data on backend servers, and as Park teaches using the transaction history, it would have been obvious to one of ordinary skill in the art to modify Rosenberg/Yeager to also use the transaction history to authenticate the user transaction, as is conventional and as taught by Park.
Response to Arguments
Applicant's arguments filed 10-24-25 have been fully considered but they are not persuasive.
Regarding “Argument (1)” Applicant sets forth (on page) that “The cited references do not suggest a “secure element application””.
It is noted that there are no arguments per se, only a citation of claim 1 in its entirety and the sentence “Neither Rosenberg, Yeager or Fernandes teach or suggest the claimed “Secure element application which is recited in independent claims below.” The Examiner sets forth that this new feature has been addressed with the citations of these three references, as described above.
Therefore, Applicant’s points relating to “Argument (1)” are not persuasive.
Regarding “Argument (2)”, Applicant sets forth (on pages 8-17) that the references do not teach the feature of “maintaining an identification code associated with a user stored in the secure element memory” and “a remote server used to process the NFC transaction using a payment method maintained at the remote server which corresponds to the identification code associated with the user”.
It is first noted, that these two disputed features were present in claim 1 (see claims 7-6-22) which were appealed and previously decided upon by the PTAB (see decision 7-17-24). The RCE papers filed on 9-13-24, 1-17-25 and 10-24-25 have not changed or amended these features since the PTAB decision. As the PTAB decision of 7-17-24 has affirmed the rejection of these features in view of Rosenberg, Yeager and Fernandes, the Examiner respectfully asserts that the currently applied prior art meets these features. Therefore, in light of the previous PTAB decision in this instant application, these two claimed features stand properly rejected.
To briefly address these previously considered points, the Examiner sets forth responses to Applicant’s arguments.
Pages 8-11 of Applicant’s remarks are directed toward why the user codes of Fernandes cannot be used in Rosenberg and/or why there is a lack of motivation to combine these references. For example, Applicant sets forth that Rosenberg does not teach a “user code” and “simple substitution with Fernandes does not apply” (page 11).
In response to these points, the Examiner notes that Applicant has raised similar points in the previous Appeal in the instant application. Pages 33-34 of the previous PTAB decision (mailed 7-17-24) are reproduced below for convenience.
“As discussed above, the Examiner refers to the 5-2-23 Decision: A person of ordinary skill in the art would have recognized that incorporating the unique subscriber identification codes of Fernandes for the user's PTD, with the credit card information of Rosenberg, which is stored on the buyer's financial institution server 470, would improve Rosenberg by providing an alternative method for identifying the user (e.g., supporting accounting functions). See KSR Int'l Co. v. Teleflex Inc., 550 US. 398, 417 (2007) (“[I]f a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious unless its actual application is beyond his or her skill.”).
Alternatively, the combination of Rosenberg and Fernandes is nothing more than incorporating the known unique subscriber identification codes of Fernandes for the user's PTO with the known credit card information of Rosenberg, which is stored on the buyer's financial institution server 470, to yield predictable results. Id. at 416 (2007) (“The combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results.”[]).
This combination of Rosenberg and Fernandes would result in incorporating the unique subscriber identification codes of Fernandes for identifying the user's PTD, with the credit card information of Rosenberg, which is stored on buyer's financial institution server 470. Accordingly, this combination of references teaches the limitation “maintaining, at a server, a payment method that corresponds to an identification code of a user.”
Thus, we agree with the Examiner (Final Act. 6) that modifying Rosenberg to include the unique subscriber identification codes of Fernandes would have been obvious."
The above Examiner’s findings and conclusions are reasonable”.
Pages 12-18 of Applicant’s remarks are directed toward why Rosenberg is deficient and/or why the inventive concept of Rosenberg is destroyed by the combination. For example, Applicant sets forth at the bottom of page 14 that “Rosenberg does not teach or suggest storing the actual credit card or bank account number in the smartlink module” and page 18 summarizes the arguments by stating “This is because a person of ordinary skill would not be motivated to modify a reference by contradicting its basic teaching”.
As described above, these points have already been addressed (and Affirmed in the PTAB decision mailed 7-17-24) as being taught and/or rendered obvious by the combination of Rosenberg and Fernandes.
Therefore, Applicants arguments are not persuasive.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN SHAUN KELLEY whose telephone number is (571)272-5652. The examiner can normally be reached Mondays to Fridays.
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, Matt Anderson can be reached on (571)272-4177. 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.
/STEVEN S KELLEY/Primary Examiner, Art Unit 2646