DETAILED ACTION
The present application is being examined under the pre-AIA first to invent provisions.
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 October 10, 2025 has been entered.
Response to Amendment
Applicant amended claims 4, 8, 15, and 41.
Applicant cancelled claim 40.
Applicant previously cancelled claims 1-3, 5-7, 9-14, 16-39, and 47.
Examiner notes that although Applicant has cancelled claims 40 and 43-49 and the claims have that as the status identifier, the body of the claim still remains. Examiner respectfully suggests writing Claims 43-49 (Cancelled) similar to the other cancelled claims in Applicant’s claim set.
Claims 4, 8, 15, and 41-42 are pending and have been examined.
Response to Arguments
Applicant's arguments filed October 10, 2025 have been fully considered but they are not persuasive.
Regarding 112 Rejections
Examiner initially rejected claims 4, 8, 15, and 40-42 under 35 USC 112(b) / 2nd paragraph as being indefinite. Applicant addressed many of the antecedent basis issues identified in the claims, those rejections have been withdrawn. Applicant did not address certain antecedent basis issues which remain rejected. Applicant did not address the 112b rejections regarding the unclear nature of certain limitations. Particularly, Applicant attempted to address the indefiniteness of “geolocation Consumer information”; however the issue is due to the syntax of the limitation, as opposed to identifying that the information is associated with a consumer’s handheld device. Examiner believes that Applicant means to say “Consumer’s geolocation information”
Examiner maintains this rejection.
Regarding Prior Art Rejections
Examiner initially rejected claims 4, 8, 15, and 40-42 under 35 USC 103 as being unpatentable over the prior art.
Applicant argued that Examiner did not present a prima facie case and used impermissible hindsight to for the combination. Examiner does not find this argument persuasive. Examiner has presented a prima facie case. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Applicant presented an affidavit asserting that the use of a one-time password with a QR code would not have been obvious. Examiner does not find this argument persuasive. Applicant argument relies on Non-Patent Literature that has not been provided. For the sake of compact prosecution, and due to the Applicant being a pro-se application, Examiner has provided the NPL at issue. The main problem with Applicant’s argument is that it does not actually address the combination at issue. The primary reference Dai teaches a QR code containing a one-time use password. The password created in Dai reflects a specific transaction, thus any password reflective of that one time transaction would be a one-time use password. The secondary reference is not being used to teach the general concept of a one-time use password in a QR code but rather that the one-time password is a time-synchronized password. All the combination addresses is that the primary reference teaches a general type of password as opposed to a specific type of password. This is the actual combination of references that would need to be addressed. Furthermore, regarding Applicant’s argument, it is based on specious reasoning. Merely because an idea is in a peer-reviewed journal does not necessarily mean the underlying idea is novel. The level of “novelty” of a peer-reviewed journal is not the same as the one required by 35 USC 102/103. The standards to include an article can vary from publication to publication and are reflective of the various editors. They do not include the standard that the USPTO considers, is this the first person to file an application/first to invent the idea and there being no permissible prior art anywhere that describes the idea. Merely because the idea is included in a journal article does not mean the idea is novel; this being evidenced by the fact that Applicant had filed an application on the general idea of using a one-time password in a QR code 4 years before the article, that application being published 3 years before the article, as well as the various cited references being published before even Applicant’s application. Merely because an idea is described in a scientific journal does not mean it meets the USPTO’s standards of novelty required for patentability.
Examiner maintains this rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4, 8, 15, and 41-42 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claim 4, the limitation “wherein a transaction validation from a third party is created and sent on behalf of the Consumer to a Vendor or Service Provider,” is indefinite. This is a limitation defining the methodology without the limitation being appropriately tied to the system performing the method step.
Claim 4 recites the limitation "the visual display" in the 1st line of the 2nd page of the claim (and subsequently in the claim). There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitation " the third party server" in the last line of the 2nd page of the claim. There is insufficient antecedent basis for this limitation in the claim.
In the 2nd line of claims 4 “compare geolocation Consumer information associated with a consumer’s handheld device” is indefinite because it is unclear what this refers to. For the sake of compact prosecution Examiner will interpret this as a grammatical mistake. Examiner believes Applicant means “compare geolocation information associated with a Consumer”.
Claims 8, 15, and 41-42 are rejected due to their dependence on claim 4.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) 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.
Claims 4, 8, 15, 40-46, 48, and 49 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Dai, U.S. Patent Application Publication No., 2011/0191252 in view of Saxena, U.S. Patent Application Publication No., 2011/0321144, in further view of Mina, U.S. Patent Application Publication No., 2011/0119190.
Regarding claims 4
Dai teaches:
A system for facilitating a transaction, comprising: at least one processor configured to compare geolocation Consumer information associated with a consumer's handheld device with geolocation information associated with a Vendor or Services Provider and
See Dai [0007], [0036] ‘the secured transaction description may further include the global positioning system (GPS) location 129 of the mobile client device”
“In one implementation, every mobile payment may be monitored by comparing the transaction location (for example GPS terminal location) against the location of the mobile client device”
See also Figures 1A and 2A
at least one computer readable hardware storage device configured to store a non- transitory storage media, the non-transitory storage media configured to accept geolocation information, wherein the computer readable hardware storage device is not a transitory signal,
See Dai [0082] “Memory can be implemented within the processing unit or external to the processing unit. As used herein the term "memory" refers to any type of long term, short term, volatile, nonvolatile, or other storage devices and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored”
[0036] ‘the secured transaction description may further include the global positioning system (GPS) location 129 of the mobile client device”
the at least one processor determine whether a… one-time use password generated by software on a handheld device is valid,
See Dai [0011] decode the secured transaction description and verify the secured transaction description is valid based on the mobile client device or the point-of-sale device,
[0040] “the secured transaction description is a scrambled multi-dimensional bit map 159 that includes information of issuer ID 123, account ID 124, user password 125, merchant ID 126, transaction amount 127, time stamp 128, and GPS location 129.”
[0062] In block 528, the MTPA server 505 routes the transaction packet to the issuer server 504. In one approach, the MTPA server 505 decrypts the account ID, performs checks on identity and validity of accounts, and routs the account ID and transaction dollar amount to the issuer server 504 for further validation and authorization. In block 530, the issuer server 504 authorizes the transaction. According to an exemplary implementation, the Issuer server 504 validates the account ID, performs the payment transaction, and appends transaction packets with an authentication/acknowledge field, and sends the authorization to the MTPA server 505.
the at least one processor is configured to determine whether a unique identification (ID) of a Consumer and Vendor or Service Provider is valid,
See Dai [0070] “With such a secured encoding, only the payee's bank can authenticate that the security stamp is created by the payee using the payee's user ID, and perform verification and acknowledgement of this secured transaction.” See also [0070-0072]
[0051], “In block 420, the MTPA server receives a payment request from a mobile payee device 404 (also referred to as the payee for short). Note that in this case, there is a transaction between the payer and payee, and the MTPA serves as a processing agent to facilitate the transaction. Prior to the transaction, both the payer and the payee have established accounts with the MTPA, and money may be deposited by the payer in its account with the MTPA. The payment request from the payee includes the payer information. In block 422, the MTPA verifies the payer account information in association with the payment request. In block 424, upon verifying the payer account information, the MTPA processes the payment request by sending a request for digital signature to the payer. In block 426, the MTPA receives a digital signature from the payer, which is used to authenticate the transaction. After authenticating the transaction with the received digital signature, the MTPA debits the payer's account and credits the payee's account with the transaction amount. In block 428, the MTPA sends a transaction receipt to both the payer and the payee, and concludes the transaction.”
at least one computer readable hardware storage device storing the non-transitory storage media that accepts time-synchronized one-time use password information,
See Dai [0039], “The secured transaction description may be read from the mobile client device or be transmitted from the mobile client device in accordance with the function performed in block 118 of FIG. 1B.”
at least one computer readable hardware storage device storing the non-transitory storage media that is configured to accept input from a digital camera,
See Dai [0048], [0054] [0071] “the scanning may be performed using a phone camera, or using conventional scanner of a cash register.”
wherein the computer readable hardware storage device that accepts… one-time use password information is not a transitory signal,
See Dai [0039] Screens 154 and 156 implement the block 114 where the mobile device requests the user to enter a password 155; and a masked password 157 is entered by the user.
[0082] For a firmware and/or software implementation, the methodologies can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions . described herein. Any machine readable medium tangibly embodying instructions can be used in implementing the methodologies described herein. For example, software codes can be stored in a memory and executed by a processing unit. Memory can be implemented within the processing unit or external to the processing unit. As used herein the term "memory" refers to any type of long term, short term, volatile, nonvolatile, or other storage devices and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored.
wherein the Consumer's handheld device does not require internet access,
See Dai [0011] In yet another embodiment, a mobile transaction processing agent system includes a communication module configured to receive a secured transaction description from a mobile client device or an encrypted transaction description from a point-of-sale (POS) device, wherein the secured transaction description is in the form of a bar code generated by the mobile client device, an authentication module configured to decode the secured transaction description and verify the secured transaction description is valid based on the mobile client device or the point-of-sale device, and a transaction processing module configured to process the transaction in accordance with the secured transaction description.
wherein the… one-time use password periodically generated by an algorithm running on software on a handheld device of the Consumer is encrypted and encoded within a code generated by a handheld device
See Dai [0031], “In block 116, based on the information preinstalled in the mobile device and the information entered by the user during the transaction, such as the pin number and the transaction amount, the mobile device generates a secured transaction description dynamically.”
[0008] generating a secured transaction description dynamically using the transaction type and the user pin number, wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp, and transmitting the secured transaction description to a mobile transaction processing agent for processing.
[0009] In yet another embodiment, a point-of-sale (POS) system includes an input module configured to receive a transaction description from a mobile client device, an encryption engine configured to generate an encrypted transaction description using the transaction description from the mobile client device, and a communication module configured to transmit the encrypted transaction description for processing.
See also [0029], [0009], [0054]
and displayed on the visual display-on the consumer's handheld device
See Dai [0054] “In block 520, the mobile client device 501 generates a bar code for a transaction. In block 522, the POS device 503 scans bar code displayed by the mobile client 501”
and read in by a Vendor or Service Provider device's camera,
See Dai [0048], [0054] [0071] “the scanning may be performed using a phone camera, or using conventional scanner of a cash register.”
wherein a geolocation of the Consumer and is encrypted and encoded within a code generated by a handheld device
See Dai [0040] “the secured transaction description is a scrambled multi-dimensional bit map 159 that includes information of issuer ID 123, account ID 124, user password 125, merchant ID 126, transaction amount 127, time stamp 128, and GPS location 129.”
[0008] generating a secured transaction description dynamically using the transaction type and the user pin number, wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp, and transmitting the secured transaction description to a mobile transaction processing agent for processing.
[0009] In yet another embodiment, a point-of-sale (POS) system includes an input module configured to receive a transaction description from a mobile client device, an encryption engine configured to generate an encrypted transaction description using the transaction description from the mobile client device, and a communication module configured to transmit the encrypted transaction description for processing.
and displayed on a visual display on the consumer's handheld device and read in by a Vendor or Service Provider's device,
See Dai [0054] “In block 520, the mobile client device 501 generates a bar code for a transaction. In block 522, the POS device 503 scans bar code displayed by the mobile client 501”
wherein the time-synchronized one-time use password periodically generated by an algorithm running on software on a handheld device generated by a handheld device of the Consumer is encrypted and encoded within a code and displayed on the visual display on the consumer's handheld device and read in by a Vendor or Service Provider's device is provided to the at least one processor and stored in at least one storage device,
See Dai [0054] “The transaction ID may include Issuer ID, Account ID, Merchant ID, time stamp, and transaction amount. In block 524, the POS device 503 sends the transaction ID to the acquirer server 502.”
[0008] generating a secured transaction description dynamically using the transaction type and the user pin number, wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp, and transmitting the secured transaction description to a mobile transaction processing agent for processing.
[0009] In yet another embodiment, a point-of-sale (POS) system includes an input module configured to receive a transaction description from a mobile client device, an encryption engine configured to generate an encrypted transaction description using the transaction description from the mobile client device, and a communication module configured to transmit the encrypted transaction description for processing.
See also [0007], [0033], [0050], [0034]
wherein a transaction validation from a third party is configured to create and sent on behalf of a Consumer to a Vendor or Service Provider,
See Dai [0033] “In block 120, upon verification and approval of the transaction by the MTPA servers, the mobile device receives an acknowledgement of the transaction from the MTPA servers.”
wherein the at least one processor is configured to send confirmation of success to a Vendor or Service Provider,
See Dai [0033], “In block 120, upon verification and approval of the transaction by the MTPA servers, the mobile device receives an acknowledgement of the transaction from the MTPA servers. The acknowledgement may include a confirmation number, transaction amount, time and date of the transaction, name of the seller, and remaining balance on the M-cash account. Similar to block 118, the mobile device may receive the acknowledgement wirelessly from the MTPA servers, or from the MTPA servers via the POS device”
wherein a transaction validation from the third party is created on behalf of the Consumer and sent to the Vendor or the Service Provider.
See Dai [0033], “In block 120, upon verification and approval of the transaction by the MTPA servers, the mobile device receives an acknowledgement of the transaction from the MTPA servers. The acknowledgement may include a confirmation number, transaction amount, time and date of the transaction, name of the seller, and remaining balance on the M-cash account. Similar to block 118, the mobile device may receive the acknowledgement wirelessly from the MTPA servers, or from the MTPA servers via the POS device”
and wherein a creation of a transaction validation from the third party comprises:
a. transmitting a request for a transaction validation to a third party,
wherein a request is transmitted over a network;
See Dai [0050], “In block 410, the MTPA server 400 (also referred to as MTPA for short) receives a payment request from a mobile payer device 402” See also Figure 4A
b. the third party server is configured to receive the request, wherein the third party server is on a network;
See Dai [0050], “In block 410, the MTPA server 400 (also referred to as MTPA for short) receives a payment request from a mobile payer device 402” See also Figure 4A
c. the third party is configured to generate a transaction validation, wherein a transaction validation is generated based upon the received request;
See Dai [0050], “In block 410, the MTPA server 400 (also referred to as MTPA for short) receives a payment request from a mobile payer device 402” See also Figure 4A
d. the third party is configured to transmit a transaction validation to the vendor, wherein a transaction validation is transmitted over a network.
See Dai [0050], “In block 414, upon verifying the payer account information, the MTPA acknowledges the payment request by sending an acknowledgement to the payer.” See also Figure 4A
Dai does not teach:
a time-synchronized one-time use password
a transaction maximum allowable total value
Saxena teaches:
a time-synchronized one-time use password
See Saxena [0004] “Given enough time for attempts, it's relatively easy for unauthorized intruders to crack a static password. Unlike static passwords, a one-time password changes each time user logs in with the password being generated either by time-synchronized or counter-synchronized methods that typically requires the user to carry a small piece of hardware.”
[0029] FIG. 5. is a flow diagram illustrating the steps of mutual authentication of a user and a server. … The first instance of the CPA uses a cryptographic one time password algorithm like OTHP or similar approach to compute the dynamic identifier (DI-1). P….The validity of this dynamic identifier (DI-1) can be for a time span configured by the server. … The dynamic identifier (DI-1) received by second instance of the CPA is used to determine the authenticity of the webpage by cryptographic means. …The authentication process is terminated if the second instance of the CPA does not validate the dynamic identifier (DI-1)…
It would have been obvious to one of ordinary skill in the art to include in the one-time use passwords of the combined references, the ability to have the one-time use passwords be time-synchronized as taught by Saxena, since the claimed invention is merely a combination of old elements, and in the combination, each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes allowing the password to be time-synchronized increases the security of the password.
Mina teaches:
a transaction maximum allowable total value
See Mina [0068] “The buyer may have additional information requested of him or her, such as an approximate and/or maximum transaction amount, a time limit for the buyer's transaction authorization code to remain active, a description of an item or items potentially being purchased, and/or a selection of whether to bill the buyer's credit card or bank account for the transaction being prepared.”
It would have been obvious to one of ordinary skill in the art to include in the transaction of the combined references, the ability to encode a transaction maximum as taught by Mina, since the claimed invention is merely a combination of old elements, and in the combination, each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes compare the transaction total to a transaction maximum to see if it is lower than the maximum prevents a user from spending more money than they have available.
Regarding claim 8;
(Claim 8) The system of claim 4, wherein one or more of the following items: a one-time use password periodically generated by an algorithm running on software on a handheld device of the Consumer or a geolocation is communicated to a Vendor or Service Provider via encoding within a matrix barcode, a barcode, an image, or a number, and through Internet, cellular or Near Field Communication (NFC) data channels.
See Dai [0039] “In screen 158, a secured transaction description is generated by the mobile client device, which corresponds to the function performed in block 116 of FIG. 1B. The secured transaction description may be read from the mobile client device or be transmitted from the mobile client device in accordance with the function performed in block 118 of FIG. 1B.”
[0040] “In this implementation, the secured transaction description is a scrambled multi-dimensional bit map 159”
Regarding claim 15;
(Claim 15) The system of claim 4, wherein a geolocation information employed includes at least one of Global Positioning System (GPS) coordinates, cell-phone radio tower triangulation, an IP address, street address data, or a manual location entry.
Se Dai [0036] “In yet another embodiment of the present invention, the secured transaction description may further include the global positioning system (GPS) location 129 of the mobile client device, which further contributes to the security of the transaction”
Regarding claim 41;
(Claim 41) The system of claim 4, wherein a timestamp at a time of the print to the display is encrypted and encoded within a code generated by a handheld device
See Dai [0039] “In screen 158, a secured transaction description is generated by the mobile client device, which corresponds to the function performed in block 116 of FIG. 1B. The secured transaction description may be read from the mobile client device or be transmitted from the mobile client device in accordance with the function performed in block 118 of FIG. 1B.”
[0055-0061] “DUKPT allows the processing of the encryption to be moved away from the devices that hold the shared secret. The encryption is done with a derived key, which is not re-used after the transaction. DUKPT is used to encrypt electronic commerce transactions. While it can be used to protect information between two companies or banks, it is typically used to encrypt PIN information acquired by Point-Of-Sale (POS) devices.”
[0048] “an encryption engine 304”
See also [0009-0011]
[0008] generating a secured transaction description dynamically using the transaction type and the user pin number, wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp, and transmitting the secured transaction description to a mobile transaction processing agent for processing.
[0009] In yet another embodiment, a point-of-sale (POS) system includes an input module configured to receive a transaction description from a mobile client device, an encryption engine configured to generate an encrypted transaction description using the transaction description from the mobile client device, and a communication module configured to transmit the encrypted transaction description for processing.
and displayed on the visual display of the consumer's handheld device and read in by a Vendor or Service Provider's device.
See Dai [0048] “As discussed above in association with FIG. 1A, a POS device can be configured to receive information from a mobile client, and send that mobile client information along with other information provided by the merchant to a mobile transaction processing agent located remotely. As shown in FIG. 3, POS device 300 includes an optical scanner or near field communication (NFC) device 302, an encryption engine 304, and a wireless transceiver 306.”
See also [0054]
Regarding claim 42;
(Claim 42) The system of claim 4, wherein the unique consumer identification of the Consumer is encrypted and encoded within a code generated by a handheld device
See Dai [0039] “In screen 158, a secured transaction description is generated by the mobile client device, which corresponds to the function performed in block 116 of FIG. 1B. The secured transaction description may be read from the mobile client device or be transmitted from the mobile client device in accordance with the function performed in block 118 of FIG. 1B.”
[0055-0061] “DUKPT allows the processing of the encryption to be moved away from the devices that hold the shared secret. The encryption is done with a derived key, which is not re-used after the transaction. DUKPT is used to encrypt electronic commerce transactions. While it can be used to protect information between two companies or banks, it is typically used to encrypt PIN information acquired by Point-Of-Sale (POS) devices.”
[0048] “an encryption engine 304”
See also [0009-0011]
[0008] generating a secured transaction description dynamically using the transaction type and the user pin number, wherein the secured transaction description includes issuer ID, account ID, merchant ID, password, transaction amount, and transaction time stamp, and transmitting the secured transaction description to a mobile transaction processing agent for processing.
[0009] In yet another embodiment, a point-of-sale (POS) system includes an input module configured to receive a transaction description from a mobile client device, an encryption engine configured to generate an encrypted transaction description using the transaction description from the mobile client device, and a communication module configured to transmit the encrypted transaction description for processing.
and displayed on the visual display of the consumer's handheld device and read in by a Vendor or Service Provider's device.
See Dai [0048] “As discussed above in association with FIG. 1A, a POS device can be configured to receive information from a mobile client, and send that mobile client information along with other information provided by the merchant to a mobile transaction processing agent located remotely. As shown in FIG. 3, POS device 300 includes an optical scanner or near field communication (NFC) device 302, an encryption engine 304, and a wireless transceiver 306.”
See also [0054]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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, Bennett M Sigmond can be reached at 303-297-4411. 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.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694