DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 9 and 18-19 are canceled.
Claims 1-8, 10-17 and 20 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set
forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this
application is eligible for continued examination under 37 CFR 1.114, and the fee set
forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action
has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 20
January 2026 has been entered.
Response to Arguments
Applicant’s remarks/amendment was filed on 20 January 2026.
Applicant's arguments have been considered but they are not persuasive. However, the Examiner welcomes any suggestion(s) Applicant may have on moving prosecution forward.
Regarding the current rejection of Claims 1-8, 10-17 and 20 under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, Applicant argues:
The previously presented claim recites " ... - based on the authentication of the
contextual service delivery device, obtaining an IP address associated with the contextual service delivery device ... ".
With regards to the limitation " ... based on the authentication of the contextual service delivery device, obtaining an IP address associated with the contextual service delivery device ... " Applicant points to para [0029] which recites "Step 203 includes collecting user credentials, reading the SRCC tag ID and the contextual service point code from the passive SRCC tag by the mobile device, and sending the read information to the server 107 over the network 111. Step 204 includes receiving an authentication message from the server 107 if the SRCC tag, user credentials, and retrieved contextual service point IP address are all authentic." Clearly, a PHOSITA would recognize that the question of retrieving/obtaining "contextual service point IP
address" does not arise without SRCC tag and user authentication. Further MPEP
§ 2163 guidelines state "The examiner has the initial burden of presenting evidence or
reasoning to explain why persons skilled in the art would not recognize in the original
disclosure a description of the invention defined by the claims. See Wertheim, 541 F.2d at 263, 191 USPQ at 97". Yet additionally, MPEP §2163 guidelines state "To comply with the written description requirement of 35 U.S.C. 112(a) or pre-AJA 35 U.S.C. 112, first paragraph, or to be entitled to an earlier priority date or filing date under 35 U.S.C. 119,120,365, or 386, each claim limitation must be expressly, implicitly, or inherently supported in the originally filed disclosure.
In response, the Examiner submits:
Claims 1, 10 and 20 recite “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
Paragraph 0027 of Applicant’s Specification teaches "Step 203 includes collecting user credentials, reading the SRCC tag ID and the contextual service point code from the passive SRCC tag by the mobile device, and sending the read information to the server 107 over the network 111. Step 204 includes receiving an authentication message from the server 107 if the SRCC tag, user credentials, and retrieved contextual service point IP address are all authentic."
Paragraph 0027 clearly teaches the authentication of (1) the SRCC tag, (2) user credentials, and (3) retrieved contextual service point IP address.
The “contextual service point IP address” does not arise from SRCC tag and user authentication. Rather, the Applicant’s Specification explicitly and clearly teaches “an authentication message” that arises from the successful authentication of (1) the SRCC tag, (2) user credentials, and (3) retrieved contextual service point IP address.
Applicant further argues:
With regards to the limitation " ... based on the authentication of the contextual
service delivery device, obtaining an IP address associated with the contextual service delivery device ... " para [0029] recites "Step 205 includes accepting or rejecting the requesting user, depending on the authenticity check conducted in step 204. If authenticated, step 206 includes releasing a queued service request by the server 107, and executing and delivering the contextual service to the user at contextual service point 105." Any PHOSITA would recognize that releasing a queued service would not be possible without obtaining/retrieving an IP address associated with the contextual service delivery device, and the IP address would not ordinarily be retrieved without authentication of the SRCC tag and user credentials.
Further, para [0037] recites" ... The app now has three raw pieces of information - the user credentials, the tag info, and the additional context info, in addition to having established presence of the user in the context due to the nature of the technology. The app sends all of the information to the server, which authenticates the user and the tag. Once authenticated, it can use the additional context info to deliver the service in the context." Clearly, the IP address is retrieved/obtained on "once authenticated" which authentication, expressly stated is of "the user and the tag". Additional context info or/and IP address even if retrieved is of no consequence if the user and tag are not authenticated.
In response, the Examiner submits:
Claims 1, 10 and 20 recite “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
Paragraph 0035 of Applicant’s Specification teaches “the app now has three raw pieces of information—the user credentials, the tag information, and the additional context information, in addition to having established presence of the user in the context due to the nature of the technology. The app sends all of the information to the server, which authenticates the user and the tag. Once authenticated, it can use the additional context information to deliver the service in the context”.
Paragraph 0035 is not related to the limitation of “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device” because it is not related to IP address associated with the contextual service delivery device.
Paragraph 0035 teaches authentication of “the user and the tag” and delivery of service in the context once authenticated. Paragraph 0035 does not teach delivery or obtaining IP address associated with contextual service delivery device.
Applicant further argues:
Additionally FIG. 2 is explicit in reciting the sequence of events according to an embodiment, and is reproduced below for the benefit of the Examiner.
…
As shown above in step 204 the server authenticates the SRCC tag, authenticates user credentials, and retrieves context service point IP address. Applicant further notes that the claims require the IP address to be obtained "based on" authentication, not that the IP address must be retrieved strictly after authentication, a distinction fully supported by the specification and embodiments. Embodiments disclosed illustrate the server authenticating the contextual service device and the mobile device via the mobile device wherein the authenticated mobile device is enabled to authenticate the contextual service delivery device to release a requested service, and wherein the requested service is released " ... based on the authentication of the contextual service delivery device ... ". after " ... obtaining an IP address associated with the contextual service delivery device." as is recited by Applicant's previously presented claim 1.
Consequently. and in light of the above, the 35 USC 112(a) rejection is inapposite and
Applicant respectfully requests that the 35 USC 112(a) rejections to claims 1-18 and 20 be withdrawn and a notice of allowance be made.
In response, the Examiner submits:
Paragraph 0027 of Applicant’s Specification teaches “Step 204 includes receiving an authentication message from the server 107 if the SRCC tag, user credentials, and retrieved contextual service point IP address are all authentic. Step 205 includes accepting or rejecting the requesting user, depending on the authenticity check conducted in step 204. If authenticated, step 206 includes releasing a queued service request by the server 107, and executing and delivering the contextual service to the user at contextual service point 105“.
Paragraph 0027 clearly teaches receiving (or obtaining) “an authentication message” rather than an IP address that’s recited in the independent claims.
Paragraph 0027 teaches that an authentication message would be received (or obtained) “if the SRCC tag, user credentials, and retrieved contextual service point IP address are all authentic”.
Applicant’s Specification does not teach the recited limitation of “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
In light of Applicant’s Specification, the rejection of claims 1-8, 10-17 and 20 under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph is maintained.
Regarding the current rejection of Claims 1, 10 and 20 under 35 U.S.C. 103, Applicant argues:
Further, Galrani (U.S. Patent No. 10,999,379) claims priority to U.S. Application No. 16/583,838, filed September 26, 2019 whereas Applicant's Divisional derives its priority to parent Application filed 7/11/2015.
In response, the Examiner submits:
Galrani is relied upon for the teaching of based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device (Galrani: at least Col. 2 Lines 44-52; “A client device may connect to a network node (e.g., an access switch) for authentication to connect to a network. After the network node successfully authenticates the client device, the client device may receive a network address (e.g., an internet protocol (IP) address) from a network protocol server, such as a Dynamic Host Configuration Protocol (DHCP) server, with a lease time (e.g., a few days) and the client device may be connected to the network during the lease time”).
US Application 14/797,091 from which Applicant's Divisional derives its priority does not teach or suggest “IP address” or “contextual service delivery device”. Therefore, the priority date of 07/11/2015 does not apply to the feature of “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
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 1-8, 10-17 and 20 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.
Claims 1, 10 and 20 recite “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
Applicant’s original specification teaches the following:
[0027] “step 203 includes collecting user credentials, reading the SRCC tag ID and the contextual service point code or/and contextual service point IP address from the passive SRCC tag by the mobile device, and sending the read information to the server 107 over the network 111. Step 204 includes receiving an authentication message from the server 107 if the SRCC tag, user credentials, and retrieved contextual service point IP address are all authentic”,
[0030] “step 403 includes collecting user credentials, reading the NFC tag ID and the printer code or/and printer IP address from the NFC tag 306, and sending the read information to the server 307 over the network. Step 404 includes receiving an authentication message from the server 307 if the NFC tag, user credentials, and retrieved printer IP address are all authentic”.
While Applicant’s original specification teaches “reading IP address” and determining whether IP addresses are authentic, it does not appear to teach the specific feature of “based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device”.
Dependent Claims 2-8 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph for the same reason as independent Claim 1 above.
Dependent Claims 11-17 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph for the same reason as independent Claim 10 above.
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.
Claim Rejections - 35 USC § 103
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-2, 4-5, 7, 10-11, 13-14, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPUB 2011/0238573 by Varadarajan in view of US Patent 10,999,379 by Galrani et al. (“Galrani”).
As to Claim 1, Varadarajan teaches a computer automated system for processing financial transactions (Varadarajan: at least ¶0022; “system 10 further includes the first provider system 50 corresponding to a first provider A which may be typically a bank or other financial institution engaged in conducting ATM based transactions, and which may also be referred to as the provider A system 50”), comprising: a processor (Varadarajan: at least ¶¶0024, 0027, 0030; “provider A system 50 is configured with a memory 57 and a CPU 58”, “provider B system 60 may be configured with a memory 67 and a CPU 68”, “system 50, the provider C system 70 may be configured with a memory 77 and a CPU 78 and may include one or more servers performing various functions”); a memory (Varadarajan: at least ¶¶0024, 0027, 0030);
encoded instructions stored in the memory which when implemented by the processor cause the computer automated system (Varadarajan: at least ¶0013; “system 10 includes an ATM 30, and a plurality of provider systems 50, 60, 70, which are each configured to communicate with a network 40, which may be, for example, the internet”) to: authenticate a preconfigured mobile device (Varadarajan: at least ¶0005; “mobile user device is configured to communicate with one or more of the network, the ATM and the provider system”; ¶0015 further discloses “ATM application 22 on the mobile user device 20 may include one or more algorithms configured to conduct communications with an automated teller machine such as the ATM 30. The DVG 26 may include one or more algorithms configured to generate one or more types of dynamic values, such as one-time passcodes, transaction identifiers and authentication values”; ¶¶0024 & 0027 further disclose “an authentication system 56” and “system 50 may be configured by programming to conduct ATM related transactions, which may include conducting transaction authorization and authentication”; ¶¶0039-0040 further disclose “inputted to the ATM 30 from the mobile user device 20 may include all of the information required to complete the user's ATM transaction, including, for example, authentication information” and “authenticate the user or the mobile user device 20”; ¶0043 further discloses “provider B system 60 provides an affirmative transaction authorization result to the ATM 30, and at step 118 the ATM 30 completes the requested transaction”), wherein a pre-configuration comprises invoking a contextual service application (Varadarajan: at least ¶0005; “mobile user device is configured to communicate with one or more of the network, the ATM and the provider system”; ¶0015 further discloses “ATM application 22 on the mobile user device 20 may include one or more algorithms configured to conduct communications with an automated teller machine such as the ATM 30. The DVG 26 may include one or more algorithms configured to generate one or more types of dynamic values, such as one-time passcodes, transaction identifiers and authentication values”) triggered by a short-range communication with a contextual service delivery device (Varadarajan: at least ¶0007; “ATM may be configured for communication with the mobile user device through a contact or contactless means, which may include communication through any suitable wireless connection such as RFID, Bluetooth.TM. or other near field communication means, or through a USB port or other suitable means of contact”; ¶0032 also discloses “an ATM transaction using a mobile device in communication with an ATM” and ¶0038 further discloses “connects the mobile user device 20 to the ATM 30, for example, by using the device interface 23 and the ATM interface 33. As described previously, the device interface 23 and the ATM interface 33 may be configured by any means suitable for communication of transaction and authentication information between the mobile user device 20 and the ATM 30”);
wherein the invoked contextual service application is caused to transmit a user credential collected by the mobile device (Varadarajan: at least ¶0036; “transaction information may further include authentication information such as the user account holder's PIN, an OTP, a transaction identifier, challenge or challenge response, digital signature, key, secret, datum, device identifier, biometric value and/or other authentication information or value, or a combination of these”; ¶0039 further discloses “transaction information inputted to the ATM 30 from the mobile user device 20 may include all of the information required to complete the user's ATM transaction, including, for example, authentication information such as the user's account PIN or OTP”; ¶0042 further discloses “provider B system 60 receives the inputted transaction information, which may include the authentication information“ and “… communicate with an authentication system 66 to determine validation of the user's authentication information”), and a unique identifier (Varadarajan: at least ¶0044; “transaction record may include any element or combination of elements of information typically found on a transaction record, such as the transaction date, the transaction time, an account identifier, a transaction amount, an account balance, a transaction identifier, a confirmation number, an ATM identifier, an ATM location, etc”; ¶0064 further discloses “transaction record may be provided by the ATM 30 to the user”; claim 4 also discloses “transaction information includes at least one of a provider identifier, a user identifier, an account identifier, a transaction identifier”) and additional context information comprised in the contextual service delivery device (Varadarajan: at least ¶0036; “transaction information may further include authentication information such as the user account holder's PIN, an OTP, a transaction identifier, challenge or challenge response, digital signature, key, secret, datum, device identifier, biometric value and/or other authentication information or value, or a combination of these”; ¶0042 further discloses “provider B system 60 receives the inputted transaction information, which may include the authentication information“ and “… communicate with an authentication system 66 to determine validation of the user's authentication information”), collected via the short-tanged communication, to the computer automated system (Varadarajan at least ¶0007; “any suitable wireless connection such as RFID, Bluetooth.TM. or other near field communication means, or through a USB port or other suitable means of contact” and “mobile user device may provide transaction information or authentication information to an ATM or to an authentication system in communication with an ATM”);
based on the transmitted user credential, the unique identifier, and the additional context information, authenticate the contextual service delivery device using the authenticated pre-configured mobile device (Varadarajan: at least ¶¶0006, 0042-0043; “providing a transaction authorization result to the ATM using the provider system, and completing the authorized transaction using the ATM” and “transaction authorization system 62 may, for illustrative example, verify the user's provider B account information, confirm sufficient funds availability in the user's provider B account to complete the requested transaction, communicate with an authentication system 66 to determine validation of the user's authentication information, check for security alerts on the user's account which may require additional user input or validation to authorize the transaction, and generate a transaction authorization result” and “affirmative transaction authorization result to the ATM 30, and at step 118 the ATM 30 completes the requested transaction”; note: ATM authenticated to complete transaction);
initiate a transaction notification service directed to the contextual service delivery device (Varadarajan at least ¶0044; “transaction record is provided by the ATM 30. The transaction record may include any element or combination of elements of information typically found on a transaction record, such as the transaction date, the transaction time, an account identifier, a transaction amount, an account balance, a transaction identifier, a confirmation number, an ATM identifier, an ATM location, etc”, “transaction record is preferably provided in a paperless form, or may also be provided in printed form” and “transaction record … may be provided through another means, for example, from the provider system through the network 40 to the user or to the mobile user device 20 as an short message service (SMS), text message or email”; ¶0052 further discloses “transaction authorization result may be provided to the user through the mobile user device 20. The transaction authorization result may be of the same format provided in step 116 to the ATM 30 the user interfaces with to complete the transaction, or may be in a different format. For example, the transaction authorization may be provided in human readable characters in a message displayed by the application 22 on the display 24 of the mobile user device 20”).
Varadarajan does not explicitly disclose, but Galrani discloses based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device (Galrani: at least Col. 2 Lines 44-52; “A client device may connect to a network node (e.g., an access switch) for authentication to connect to a network. After the network node successfully authenticates the client device, the client device may receive a network address (e.g., an internet protocol (IP) address) from a network protocol server, such as a Dynamic Host Configuration Protocol (DHCP) server, with a lease time (e.g., a few days) and the client device may be connected to the network during the lease time”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Galrani’s feature of based on the authentication of the contextual service delivery device, obtain an IP address associated with the contextual service delivery device (Galrani: at least Col. 2 Lines 44-52) with the Galrani’s computer automated system.
The suggestion/motivation for doing so would have been to allow for connection of authenticated clients to a network (Galrani: at least Col. 2 Lines 44-52).
Claim 10 (a method claim) corresponds in scope to Claim 1, and are similarly rejected.
Claim 20 (a method claim) corresponds in scope to Claim 1, and are similarly rejected.
As to Claim 2, Varadarajan and Galrani teach the computer automated system of claim 1 wherein: the short-range communication comprises near-field communication (NFC) capability (Varadarajan: at least ¶0007; “any suitable wireless connection such as RFID, Bluetooth.TM. or other near field communication means, or through a USB port or other suitable means of contact”).
Claim 11 (a method claim) corresponds in scope to Claim 2, and are similarly rejected.
As to Claim 4, Varadarajan and Galrani teach the computer automated system of claim 1 wherein the contextual service delivery device comprises a mobile device configured to provide a token via a secure element (Varadarajan: at least ¶¶0039-0040 further disclose “inputted to the ATM 30 from the mobile user device 20 may include all of the information required to complete the user's ATM transaction, including, for example, authentication information” and “authenticate the user or the mobile user device 20"; ¶0042 further discloses “.. at step 114, in the present example, the provider B system 60 receives the inputted transaction information, which may include the authentication information as described previously, from the ATM 30”, “provider B system 60 processes the transaction request through a transaction authorization system 62” and “transaction authorization system 62 may, for illustrative example, ... communicate with an authentication system 66 to determine validation of the user's authentication information”; note: mobile (adj) can mean “able to move or be moved freely or easily”; ¶0034 & 0040 further disclose “one-time passcode generator or other DVG 26 to provide an authenticating value or transaction identifier” and “authentication information transmitted at step 110 may be, for example, one or more of a PIN, authentication information inputted in step 104, a machine identifier unique to user device 20, a value provided by a DVG 26 on the mobile user device 20”).
Claim 13 (a method claim) corresponds in scope to Claim 4, and are similarly rejected.
As to Claim 5, Varadarajan and Galrani teach the computer automated system of claim 1 wherein the unique identifier is verified by the mobile device (Varadarajan: at least ¶0039; “cryptographically securing the transaction information using a key, and/or secret shared by the user's mobile user device 20 and the provider system of the provider with which the transaction is to be conducted, such that the transaction information, even if susceptible to an interception attack, is not discernible by other than the provider system possessing the shared key”)
Claim 14 (a method claim) corresponds in scope to Claim 5, and are similarly rejected.
As to Claim 7, Varadarajan and Galrani teach the computer automated system of claim 1 wherein: the transaction notification service comprises a notification sent to the contextual service delivery device following transaction authorization (Varadarajan at least ¶¶0043, 0044; “transaction authorization result is based upon the authorization and authentication criteria of the provider, in this example, the provider B” and “transaction record is provided by the ATM 30. The transaction record may include any element or combination of elements of information typically found on a transaction record, such as the transaction date, the transaction time, an account identifier, a transaction amount, an account balance, a transaction identifier, a confirmation number, an ATM identifier, an ATM location, etc”, “transaction record is preferably provided in a paperless form, or may also be provided in printed form” and “transaction record … may be provided through another means, for example, from the provider system through the network 40 to the user or to the mobile user device 20 as an short message service (SMS), text message or email”; ¶0052 further discloses “transaction authorization result may be provided to the user through the mobile user device 20. The transaction authorization result may be of the same format provided in step 116 to the ATM 30 the user interfaces with to complete the transaction, or may be in a different format. For example, the transaction authorization may be provided in human readable characters in a message displayed by the application 22 on the display 24 of the mobile user device 20”).
Claim 16 (a method claim) corresponds in scope to Claim 7, and are similarly rejected.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over unpatentable over US PGPUB 2011/0238573 by Varadarajan in view of US Patent 10,999,379 by Galrani et al. (“Galrani”), and further in view of US PGPUB 2011/0191161 by Dai.
As to Claim 3, Varadarajan and Galrani teach the computer automated system of claim 1.
Varadarajan and Galrani do not explicitly disclose, but Dai discloses wherein the collected user credential comprises a merchant identifier associated with a merchant account (Dai: at least ¶0008; “collecting a user pin number, generating a secured transaction description” and “wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Dai’s feature of wherein the collected user credential comprises a merchant identifier associated with a merchant account (Dai: at least ¶0008) with the computer automated system disclosed by Varadarajan and Galrani.
The suggestion/motivation for doing so would have been to process “secured transactions” in a secured transaction system (Dai: at least Abstract, ¶0012).
Claim 12 (a method claim) corresponds in scope to Claim 3, and are similarly rejected.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over unpatentable over US PGPUB 2011/0238573 by Varadarajan in view of US Patent 10,999,379 by Galrani et al. (“Galrani”), and further in view of US PGPUB 2012/0239570 by Wolfs et al. (“Wolfs”).
As to Claim 6, Varadarajan and Galrani teach the computer automated system of claim 1.
Varadarajan and Galrani do not explicitly disclose, but Wolfs discloses wherein the IP address is used to deliver a notification over an IP-based communication network (Wolfs: at least ¶0055; “IP addresses, routing numbers, and other data for routing messages between financial institutions 20 and merchants 60”; ¶0033 also discloses “automated teller machine ("ATM") 70 may also be connected to FI 20 through network 10”; ¶0135 also discloses “ATM 70 may also transmit a message to FI 20 to notify FI 20 that the transaction has been declined by ATM 70”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wolfs’ feature of wherein the IP address is used to deliver a notification over an IP-based communication network (Wolfs: at least ¶¶0033, 0055, 0135) with the computer automated system disclosed by Varadarajan and Galrani.
The suggestion/motivation for doing so would have been to “performing financial transactions” with enhanced security (Wolfs: at least ¶0028).
Claim 15 (a method claim) corresponds in scope to Claim 6, and are similarly rejected.
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over unpatentable over US PGPUB 2011/0238573 by Varadarajan in view of US Patent 10,999,379 by Galrani et al. (“Galrani”), and further in view of US PGPUB 2014/0101728 by Defrance et al. (“Defrance”).
As to Claim 8, Varadarajan and Galrani teach the computer automated system of claim 1.
Varadarajan and Galrani do not explicitly disclose, but Defrance discloses wherein the contextual service application is provisioned to the pre-configured mobile device (Defrance: at least ¶0040; “application 213 that is stored in a server 221, the server being connected to the Internet via link 999. The application 213 is downloaded on gateway 220 and is executed in an application container environment 212, and uses the services offered by the network organizer 211. According to the present invention, it is thus possible for the gateway 220 to decide to make visible or not any of the shared data folders to a downloaded application 213 that is executed in an application container environment 212”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Brinkley’s feature of wherein the contextual service application is provisioned to the pre-configured mobile device (Defrance: at least ¶0040 with the computer automated system disclosed by Varadarajan and Galrani.
The suggestion/motivation for doing so would have been to provide protected execution environment (application container) in which application downloaded can be securely executed (Defrance: at least ¶0039).
Claim 17 (a method claim) corresponds in scope to Claim 8, and are similarly rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270-3426. The examiner can normally be reached on Monday - Friday (10:30AM EST - 6:30PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.W/Examiner, Art Unit 2168 02 March 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168