DETAILED ACTION
This is a final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 22 in application 17/506914.
Claims 5, 13, 20, 21-22 are canceled.
Claims 1, 9, and 17 are amended.
Claims 1-4, 6-12, and 14-19 are pending and have been examined on the merits.
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Claim Rejections – 35 USC 103
Applicant's arguments filed on 02/24/2026 have been fully considered but they are not persuasive. The claim requires outputting an anti-collision command based on token equality, not based on the UID or cryptogram content. Chen teaches the terminal output the anti-collision command: “an anti-collision command may be sent from the access device 102 to the communication device 104 (¶ 0064)” and the device returns UID in response: “the UID value is provided…in response to an anti-collision command (¶ 0025).” Chen also teaches the terminal receives a response artifact distinct from a payment token, supporting the “request response token…stored” concept. Chen cites transaction level data may include a “payment token (¶ 0026)” and that the terminal is “is now in possession of the cryptogram, the first UID, and the transaction level data (¶ 0029).”
Sequencing anti-collision as the standard first NFC operation after a prior go or no-go condition is conventional and does not render Chen as inoperable. Thueringer confirms the anti-collision command is “know per se” and performed before further communication: “after an anti-collision procedure which is known per se, select one of the transponders…(¶ 0093).”
Therefore, the 103 rejection is maintained. Sin supplies the token comparison outcome (token match condition), while Chen and Thueringer supply the conventional anti-collision/UID exchange and sequencing.
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 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.
Claim(s) 1-4, 6-12, and 14-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US20190362341), hereinafter Chen, in view of Thueringer et al. (US20110078549A1), hereinafter Thueringer, in further view of Sin (KR20170072847A – Google Doc).
Regarding Claims 1 and 17. Chen teaches (in BOLD):
An operating method of a payment terminal configured to perform a payment, the method comprising: [Embodiments of the invention can address the above relay attack scenario described in FIG. 1. In the scenario described with respect to FIG. 1, transaction level data such as a transaction amount and/or an account number can be passed between, for example, the contactless card 40 and the access device 102 via the phones 20, 30. However, interoperability level data such as a first UID would be obtained by the contactless terminal 10 from the application 20A or the phone 20 after the phone 20 is proximate to the contactless terminal 10. Interoperability level data would not be received by the contactless card 40. The received first UID would be specific and unique to the application 20A or the phone 20. In subsequent messaging between the contactless terminal 10 and the contactless card 40, the contactless card 40 will possess information such as an account number and a transaction amount (the latter of which is received from the contactless terminal 10). The contactless card 40 may also generate a cryptogram by signing a second UID value in response to its interaction with the phone 30, and transaction level data such as the account number and/or transaction amount with a first cryptographic key. The first cryptographic key may be an authorizing entity cryptographic key such as an issuer private key. This cryptogram will then be transmitted from the contactless card 40 to the contactless terminal 10 via the phones 20, 30 (Paragraph 0027-0028, Chen)].
outputting, by the payment terminal, a payment request command and the first payment token to at least one payment information generator; [In step S152, the access device 102 may transmit an information request to the communication device 104. The information request may contain certain data elements from the access device 102. Such data elements may include a transaction amount, an access device identifier, a resource provider identifier, an unpredictable number, etc (Paragraph 0065, Chen)].
receiving, by the payment terminal from the at least one payment information generator, a second payment token generated based on the first payment token and a request response token in response to the payment request command, [In step S154, the communication device 104 may generate a cryptogram as described above. After generating the cryptogram, the communication device 104 may provide the cryptogram to the access device 102. Additional data elements which may be transaction level data may be included in the response in step S156. For example, a primary account number, CVV, etc. may be transmitted to the access device 104 by the communication device 102 in step S156 (Paragraph 0066, Chen). In response to receiving the account data request from access device 102, communication device 104 may send the account data stored at the location indicated by the AFL to access device 102. In some embodiments, the account data may be sent in the form of a read record response S216. The account data may include, for example, application usage control that indicates the issuer's restrictions on the usage and services allowed for the application, the cardholder's name, account number, payment token, customer exclusive data, issuer country code, token requester ID (e.g., if a token is used), and/or other account related data that is accessible at the AFL location (¶ 0081, Chen)].
wherein the request response token is different from the second payment token, and wherein the request response token is stored in the payment terminal after being received by the payment terminal; [Examples of transaction level data may include a…payment token (¶ 0026, Chen). The contactless terminal 10 is now in possession of the cryptogram, the first UID, and the transaction level data (¶ 0029, Chen) – Note: the “payment token” is transaction-level data. The response sent back by the communication device is a cryptogram (generated using UID and transaction data) that the terminal receives and possesses. Thus, the response (cryptogram) is different from the payment token, and it held/stored by the terminal upon receipt (different from the second payment token and stored in the payment terminal)].
based on the first payment token and the second payment token being the same, outputting, by the payment terminal, an anti-collision command to the at least one payment information generator. [an anti-collision command may be sent from the access device 102 to the communication device 104. The communication device 104 may respond with a UID or a PUPI (¶ 0064, Chen) – Note: the payment terminal = access device 102. Chen expressly teaches the terminal outputs an anti-collision command to the counterpart device (“payment information generator “) and receives a UID/PUPI in reply].
receiving, by the payment terminal from the at least one payment information generator, unique identification information generated based on the request response token in response to the anti-collision command; and [The interoperability level data may include, for example, a UID (unique identifier) value. In the normal interaction between a communication device such as contactless card and an access device such as a contactless terminal, the UID value is provided by the communication device in response to an anti-collision command sent by the access device to the communication device. The UID value is used by the access device to allow the access device to continue to communicate with the correct communication device, in the event that other communication devices are within the vicinity of the access device. Other communication devices within the vicinity of the access device will not have the UID of the correct communication device (¶ 0025, Chen). The contactless terminal 10 is now in possession of the cryptogram, the first UID, and the transaction level data… The contactless terminal 10 may attempt to use the first UID and the transaction level data and a second cryptographic key corresponding to the first cryptographic key to validate the received cryptogram (¶ 0029). In step S150, a transaction may be initiated by a series of communications between the access device 102 and the communication device 104. For example, in one embodiment, an anti-collision command may be sent from the access device 102 to the communication device 104 in a contactless interaction. The communication device 104 may respond with a UID or a PUPI. In another example, a reset action may be implemented from the access device 102 to the communication device 104 in a contact interaction. The communication device 104 may respond with an ATR value. In these examples, the UID, PUPI, and ATR values can examples of interoperability level data that can only be provided by the communication device 104 to the access device 102. These or other subject values can be fixed or randomized generated each time the interaction is initiated (¶ 0064, Chen)].
performing security authentication by comparing, by the payment terminal, the unique identification information with the stored request response token; and [the UID value is provided by the communication device in response to an anti-collision command (¶ 0025, Chen). The contactless terminal 10 may attempt to use the first UID and the transaction level data and a second cryptographic key corresponding to the first cryptographic key to validate the received cryptogram (¶ 0029, Chen) – Note: Chen’s UID is produced because of the anti-collision command. The terminal then uses that UID to validate (i.e., authenticate by comparison against the received cryptogram – the stored response token. (In some embodiments, the cryptogram could be decrypted with a cryptographic key to obtain the interoperability level data and the transaction level date. This data may be compared to the determined interoperability level data and transaction level data to determine if there is a match. In other embodiments, a separate cryptogram may be calculated by the access device 102 (using the obtained interoperability level data and the transaction level data, and an appropriate cryptographic key) and this may be compared with the received cryptogram to determine if there is a match. In this example, the separate cryptogram may be generated using a symmetric key, and a corresponding symmetric key may be on the communication device and may have been used to generate the received cryptogram. In yet other embodiments, the received cryptogram was generated using a private key of a public/private key pair. The received cryptogram can be validated with a public key, a verification algorithm, the interoperability level data, and the transaction level data. Public key verification methods are known in the art (¶ 0067, Chen).
Chen does not teach, however Thueringer teaches (in BOLD):
generating a first payment token including an encrypted random number; [receiving, by the reader, an encryption of the first random number and of the second random number (particularly in an encrypted form) from the transponder (step 3) (Paragraph 0014)].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the payment command of Chen with the encryption of Thueringer because doing so allows the payment to be completed in an encrypted way to avoid fraud.
The combination of Chen and Thueringer does not teach, however Sin teaches (in BOLD):
based on the first payment token and the second payment token being the same, outputting payment approval information and an anti-collision command to the at least one payment information generator; [One embodiment of the present invention is a terminal for generating and transmitting a second security token using a second unique number assigned to a subscriber identity module concatenated with second payment information input by a user, A franchisee terminal for receiving and transmitting at least one of the second unique number and the second security token in a non-contact manner; Extracts first payment information based on the subscriber information and a first unique number assigned to the subscriber identity module, generates and stores a first security token using the first payment information and the first unique number, A communication management device for processing payment approval for the electronic settlement request signal based on a result of comparing the second security token previously stored from the merchant terminal with the previously stored first security token when the electronic settlement request signal is received, ; And a financial settlement providing device for performing an electronic settlement for the fee when the approval signal for the electronic settlement approval request signal is received from the communication management apparatus (Abstract, Sin)].
based on the security authentication being successful, outputting payment approval information. [based on a result of comparing the second security token previously stored from the merchant terminal with the previously stored first security token when the electronic settlement request signal is received, ; And a financial settlement providing device for performing an electronic settlement for the fee when the approval signal for the electronic settlement approval request signal is received (Abstract, Sin) – Note: successful token comparison (i.e., successful authentication) to processing payment approval].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the command of Chen with the encryption of Thueringer with the payment token of Sin because doing so allows the processor approval transactions through a process preventing fraud.
Regarding Claims 2, 10, 18. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 1, wherein the payment request command corresponds to payment request from among a plurality of payment requests, and [The cryptogram generation 104E-2 in the memory 104 may include code executable by the data processor 104A to generate a cryptogram as described above. Any suitable encryption technique may be used including DES, triple DES, AES, etc (Paragraph 0089, Chen)].
wherein the first payment token is encrypted with a different value for each payment request of the plurality of payment requests. [The cryptogram generation 104E-2 in the memory 104 may include code executable by the data processor 104A to generate a cryptogram as described above. Any suitable encryption technique may be used including DES, triple DES, AES, etc (Paragraph 0089, Chen)].
Regarding Claims 3 and 11. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 1, wherein the second payment token is a data packet generated by the at least one payment information generator based on the first payment token. [A method is disclosed. The method includes generating, by a communication device during an interaction with an access device, a cryptogram using transaction level data and interoperability level data; transmitting the transaction level data and interoperability level data to the access device; and transmitting the cryptogram the access device, wherein the access device or a remote server computer in communication with the access device validates the received cryptogram before allowing the transaction to proceed (Abstract, Chen)].
Regarding Claims 4, 12, and 19. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 1, wherein the receiving of the second payment token includes receiving, from the at least one payment information generator, request response information and a request response token corresponding to the payment request command. [Upon receiving the command in S202, the communication device 104 may include an application which may identify and process the request by recognizing the payment environment identifier (e.g., PPSE name) included in the request, and respond by sending an available applications response S204 back to access device 102. The available applications response S204 may include a list of available AIDs, and may include the payment environment identifier (e.g., PPSE name). In some embodiments, the available applications response S204 may be in the form of a select PPSE response and may include PPSE file control information (FCI) (Paragraph 0071, Chen)].
Regarding Claims 6 and 14. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 1, wherein the outputting of the payment approval information includes, based on a determination that the unique identification information does not correspond to the request response token, suspending a payment approval. [The interaction processing module 600D-1 may include code, executable by the data processor 600A to process transaction level data. Such processing may including performing fraud analyses and determining if authorization request messages should be approved or declined (Paragraph 0105, Chen). A “secure element” can refer to a component that can perform a function securely. A secure element may be a memory that securely stores data, such that its access is protected. An example of a “secure element” is a Trusted Execution Environment (TEE), a secure area of a processor. Another example of a secure element is a Universal integrated-circuit card (UICC), a secure smart card. Yet another example of a secure element is an embedded secure element, an embedded hardware component in a larger mechanical or electrical system. Another example of a secure element is a hardware security module (HSM), which is a physical computing device that can safeguard and manage cryptographic keys for authentication and provide crypto-processing functions (Paragraph 0051, Chen)].
Regarding Claims 7 and 15. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 1, wherein the unique identification information includes at least one piece of unique identification information corresponding to the at least one payment information generator, and [A “secure element” can refer to a component that can perform a function securely. A secure element may be a memory that securely stores data, such that its access is protected. An example of a “secure element” is a Trusted Execution Environment (TEE), a secure area of a processor. Another example of a secure element is a Universal integrated-circuit card (UICC), a secure smart card. Yet another example of a secure element is an embedded secure element, an embedded hardware component in a larger mechanical or electrical system. Another example of a secure element is a hardware security module (HSM), which is a physical computing device that can safeguard and manage cryptographic keys for authentication and provide crypto-processing functions (Paragraph 0051, Chen)].
wherein the operating method further comprises: based on a determination that a piece of unique identification information from among the at least one piece of unique identification information corresponds to the request response token, outputting a select command including the piece of unique identification information; and [The interoperability level data may include, for example, a UID (unique identifier) value. In the normal interaction between a communication device such as contactless card and an access device such as a contactless terminal, the UID value is provided by the communication device in response to an anti-collision command sent by the access device to the communication device. The UID value is used by the access device to allow the access device to continue to communicate with the correct communication device, in the event that other communication devices are within the vicinity of the access device. Other communication devices within the vicinity of the access device will not have the UID of the correct communication device (Paragraph 0025, Chen)].
receiving select response information from a payment information generator corresponding to the piece of unique identification information. [The interoperability level data may include, for example, a UID (unique identifier) value. In the normal interaction between a communication device such as contactless card and an access device such as a contactless terminal, the UID value is provided by the communication device in response to an anti-collision command sent by the access device to the communication device. The UID value is used by the access device to allow the access device to continue to communicate with the correct communication device, in the event that other communication devices are within the vicinity of the access device. Other communication devices within the vicinity of the access device will not have the UID of the correct communication device (Paragraph 0025, Chen)].
Regarding Claims 8 and 16. The combination of Chen, Thueringer and Sin further teaches:
The operating method of claim 7, wherein the outputting of the payment approval information includes: transmitting the first payment token and a transaction approval command to the payment information generator; and [An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g. POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization (Paragraph 0047, Chen)].
determining whether to output the payment approval information according to a result of comparison between the first payment token and the second payment token included in the transaction approval command from the payment information generator. [[One embodiment of the present invention is a terminal for generating and transmitting a second security token using a second unique number assigned to a subscriber identity module concatenated with second payment information input by a user, A franchisee terminal for receiving and transmitting at least one of the second unique number and the second security token in a non-contact manner; Extracts first payment information based on the subscriber information and a first unique number assigned to the subscriber identity module, generates and stores a first security token using the first payment information and the first unique number, A communication management device for processing payment approval for the electronic settlement request signal based on a result of comparing the second security token previously stored from the merchant terminal with the previously stored first security token when the electronic settlement request signal is received, ; And a financial settlement providing device for performing an electronic settlement for the fee when the approval signal for the electronic settlement approval request signal is received from the communication management apparatus (Abstract, Sin)].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the command of Chen with the encryption of Thueringer with the payment token of Sin because doing so allows the processor approval transactions through a process preventing fraud.
Regarding Claim 9. Chen teaches (in BOLD):
A payment terminal comprising: an interface circuit configured to output a payment request command and a first payment token to at least one payment information generator, and to [In step S152, the access device 102 may transmit an information request to the communication device 104. The information request may contain certain data elements from the access device 102. Such data elements may include a transaction amount, an access device identifier, a resource provider identifier, an unpredictable number, etc (Paragraph 0065, Chen)].
receive, from the at least one payment information generator, a second payment token generated based on the first payment token and a request response token in response to the payment request command, wherein the request response token is different from the second payment token, and wherein the request response token, and [Examples of transaction level data may include a…payment token (¶ 0026, Chen). The contactless terminal 10 is now in possession of the cryptogram, the first UID, and the transaction level data (¶ 0029, Chen) – Note: the “payment token” is transaction-level data. The response sent back by the communication device is a cryptogram (generated using UID and transaction data) that the terminal receives and possesses. Thus, the response (cryptogram) is different from the payment token, and it held/stored by the terminal upon receipt (different from the second payment token and stored in the payment terminal). In step S154, the communication device 104 may generate a cryptogram as described above. After generating the cryptogram, the communication device 104 may provide the cryptogram to the access device 102. Additional data elements which may be transaction level data may be included in the response in step S156. For example, a primary account number, CVV, etc. may be transmitted to the access device 104 by the communication device 102 in step S156 (Paragraph 0066, Chen)].
receive, from the at least one payment information generator, unique identification information generated based on the request response token in response to an anti-collision command; [an anti-collision command may be sent from the access device 102 to the communication device 104. The communication device 104 may respond with a UID or a PUPI (¶ 0064, Chen) – Note: the payment terminal = access device 102. Chen expressly teaches the terminal outputs an anti-collision command to the counterpart device (“payment information generator “) and receives a UID/PUPI in reply].
compare the first payment token with the second payment token, and[Examples of transaction level data may include a…payment token (¶ 0026, Chen). The contactless terminal 10 is now in possession of the cryptogram, the first UID, and the transaction level data (¶ 0029, Chen) – Note: the “payment token” is transaction-level data. The response sent back by the communication device is a cryptogram (generated using UID and transaction data) that the terminal receives and possesses. Thus, the response (cryptogram) is different from the payment token, and it held/stored by the terminal upon receipt (different from the second payment token and stored in the payment terminal)].
based on the first payment token and the second payment token being the same, [Another embodiment of the invention is directed to a communication device comprising: a data processor, and a non-transitory computer readable medium coupled to the data processor. The non-tangible computer readable medium comprises code executable by the data processor for performing a method comprising generating, during an interaction with an access device, a cryptogram using transaction level data and interoperability level data, transmitting the transaction level data and interoperability level data to the access device, and transmitting the cryptogram to the access device, wherein the access device or a remote server computer in communication with the access device validates the received cryptogram before allowing the transaction to proceed (Paragraph 0009, Chen)].
output payment approval information and an anti-collision command to the at least one payment information generator through the interface circuit; and [an anti-collision command may be sent from the access device 102 to the communication device 104. The communication device 104 may respond with a UID or a PUPI (¶ 0064, Chen) – Note: the payment terminal = access device 102. Chen expressly teaches the terminal outputs an anti-collision command to the counterpart device (“payment information generator “) and receives a UID/PUPI in reply].
a memory configured to store the request response token. [A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation (¶ 0049)].
performing security authentication by comparing, by the payment terminal, the unique identification information with the stored request response token; and [the UID value is provided by the communication device in response to an anti-collision command (¶ 0025, Chen). The contactless terminal 10 may attempt to use the first UID and the transaction level data and a second cryptographic key corresponding to the first cryptographic key to validate the received cryptogram (¶ 0029, Chen) – Note: Chen’s UID is produced because of the anti-collision command. The terminal then uses that UID to validate (i.e., authenticate by comparison against the received cryptogram – the stored response token. (In some embodiments, the cryptogram could be decrypted with a cryptographic key to obtain the interoperability level data and the transaction level date. This data may be compared to the determined interoperability level data and transaction level data to determine if there is a match. In other embodiments, a separate cryptogram may be calculated by the access device 102 (using the obtained interoperability level data and the transaction level data, and an appropriate cryptographic key) and this may be compared with the received cryptogram to determine if there is a match. In this example, the separate cryptogram may be generated using a symmetric key, and a corresponding symmetric key may be on the communication device and may have been used to generate the received cryptogram. In yet other embodiments, the received cryptogram was generated using a private key of a public/private key pair. The received cryptogram can be validated with a public key, a verification algorithm, the interoperability level data, and the transaction level data. Public key verification methods are known in the art (¶ 0067, Chen).
Chen does not teach, however Thueringer teaches (in BOLD):
a processor configured to: generate the first payment token including an encrypted random number, [receiving, by the reader, an encryption of the first random number and of the second random number (particularly in an encrypted form) from the transponder (step 3) (Paragraph 0014)].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the payment command of Chen with the encryption of Thueringer because doing so allows the payment to be completed in an encrypted way to avoid fraud.
The combination of Chen and Thueringer does not teach, however Sin teaches:
based on the security authentication being successful, outputting payment approval information. [based on a result of comparing the second security token previously stored from the merchant terminal with the previously stored first security token when the electronic settlement request signal is received, ; And a financial settlement providing device for performing an electronic settlement for the fee when the approval signal for the electronic settlement approval request signal is received (Abstract, Sin) – Note: successful token comparison (i.e., successful authentication) to processing payment approval].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the command of Chen with the encryption of Thueringer with the payment token of Sin because doing so allows the processor approval transactions through a process preventing fraud.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Hubert et al. (US20190245848) - Methods and systems for faster and more efficient smart card logon in a remote computing environment are described herein. Fast smart card logon may be used to reduce latency and improve security. For example, the system may reduce the number of operations (e.g., interactions) between a server device used for authentication and the client device. A remoting channel may be established between the server device and the client device. The server may receive, from the client device and/or via a personal computer/smart card (PC/SC) protocol, a message comprising an identifier for a smart card. The server device may replace the identifier for the smart card with a substitute identifier. Based on the substitute identifier, the server may determine one or more cryptographic service providers to use for one or more cryptographic operations associated with the smart card. One or more requests for cryptographic operations involving the smart card may be transmitted to the client device, such as via the cryptographic service provider and/or via the remoting channel.
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 CHRISTINA C STEVENSON whose telephone number is (571)270-7280 and whose email is christina.mention@uspto.gov. The examiner can normally be reached on Monday – Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee, can be reached at telephone number 571-272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698